I have feeling it is a workaround of some other problem. Shouldn't we have fully operational scheduler at that point when EARLY_AP_STARTUP is enabled? This change may open the races this code intended to handle.

Have you tried to investigate whether keeping only VREF_ENABLE_MASK would be enough? I could have some more sense in general, since the driver has no way to know what VREF is needed in specific case. Same time other bits there are pretty logical.

I have no specific objections. Looks good to me. It just looks slightly odd, that MTU is handled different from other properties -- set before interface addition to LAGG, while multicast filters set after just before protocol initialization, and capabilities are set after the protocol initialization. As one of downsides this different order required addition of duplicate checks for LAGG nesting.

Unfortunately I haven't touched this area for several years and don't know details of modern transfer modes.

I have no particular objections, just quietly sighing that this area remains so tangled. I haven't investigated the area much recently, but it seems like WDAT-based attach could be cleaner, if it is a widespread standard and does not conflict too badly with existing drivers. Having watchdog drivers enabled in FreeNAS for years we had huge number of complains, caused by random platform specifics, and obtaining some valid configuration directly from platform in face of this table could be priceless.

Dropping locks inside the function is a mess, but I don't see specific problems.

Looks good to me, but VFS and ZPL are not my favorite areas to know all details.