> However, this won't work for PHY devices created _before_ the kernel > has mounted the rootfs, whether or not they end up being used. So, > every PHY mentioned in DT will be created before the rootfs is mounted, > and none of these PHYs will have their modules loaded. Hi Russell I think what you are saying here is, if the MAC or MDIO bus driver is built in, the PHY driver also needs to be built in? If the MAC or MDIO bus driver is a module, it means the rootfs has already been mounted in order to get these modules. And so the PHY driver as a module will also work. > I believe this is the root cause of Yinbo Zhu's issue. You are speculating that in Yinbo Zhu case, the MAC driver is built in, the PHY is a module. The initial request for the firmware fails. Yinbo Zhu would like udev to try again later when the modules are available. > What we _could_ do is review all device trees and PHY drivers to see > whether DT modaliases are ever used for module loading. If they aren't, > then we _could_ make the modalias published by the kernel conditional > on the type of mdio device - continue with the DT approach for non-PHY > devices, and switch to the mdio: scheme for PHY devices. I repeat, this > can only happen if no PHY drivers match using the DT scheme, otherwise > making this change _will_ cause a regression. Take a look at drivers/net/mdio/of_mdio.c:whitelist_phys[] and the comment above it. So there are some DT blobs out there with compatible strings for PHYs. I've no idea if they actually load that way, or the standard PHY mechanism is used. Andrew
