On Tue, Mar 05, 2024 at 09:19:41AM +0100, Eric Woudstra wrote: > The main reason I have it in config_init() is that by then the > rootfs is available. The EN8811H does not depend on the firmware > to respond to get_features(). It is therefore possible to not > have the firmware in initramfs or included in the kernel image. > I could not get this result using EPROBE_DEFER, I think this is > not an option in phylink. I think you're slightly confused there. It's not specific to phylink. It's also not an option when using phy_connect()/phy_connect_direct() from .ndo_open as well, or looking up the PHY to then use phy_attach()/ phy_attach_direct(). One can structure the code using phylink just the same way one would structure the code using phylib in this respect. .ndo_open can't handle EPROBE_DEFER. EPROBE_DEFER is so named because it defers _driver_ _probing_ and thus is only appropriate to be returned from a device driver .probe method. .ndo_open is not a device driver probe method and thus EPROBE_DEFER must not be returned from it. The only option in .ndo_open is to fail the attempt to open the network device, at which point userspace will report an error and give up opening that network device - it won't retry. In summary, this isn't something which is specific to phylink. The only way I can see around this problem would be to look up the PHY in order to get a pointer to the struct phy_device in the network device's probe function, and attach the PHY there _before_ you register the network device. You can then return EPROBE_DEFER and, because you are returning it in a .probe function, the probe will be retried once other probes in the system (such as your PHY driver) have finished. This also means that userspace doesn't see the appearance of the non-functional network device until it's ready, and thus can use normal hotplug mechanisms to notice the network device. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
