Messages in this thread | | | Date | Thu, 22 Nov 2018 19:57:05 +0100 | From | Andrew Lunn <> | Subject | Re: Issue with RTL8111 NIC after upgrade to kernel 4.19 |
| |
> Thanks a lot for testing. Could you please test also the following > as an alternative to the delay? > > diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c > index 55202a0ac..aeccb2323 100644 > --- a/drivers/net/phy/phy_device.c > +++ b/drivers/net/phy/phy_device.c > @@ -2254,6 +2254,7 @@ int phy_driver_register(struct phy_driver *new_driver, struct module *owner) > new_driver->mdiodrv.driver.probe = phy_probe; > new_driver->mdiodrv.driver.remove = phy_remove; > new_driver->mdiodrv.driver.owner = owner; > + new_driver->mdiodrv.driver.probe_type = PROBE_FORCE_SYNCHRONOUS; > > retval = driver_register(&new_driver->mdiodrv.driver); > if (retval) {
Humm, maybe i don't understand the issue correctly.
When the MDIO bus is registered, we scan the bus looking for PHYs. When we find a PHY, we call phy_device_create(). That will then trigger the loading of the kernel module which should driver this phy.
Sometime later, the PHY driver module gets loaded and calls phy_drivers_register() to register the list of IDs it supports. The driver core will then call phy_bus_match() to see if the newly loaded driver matches to a device we have created. If so, the driver will be associated to the device.
Sometime later, the MAC tries to attach to the phy using phy_attach_direct(). If there is no driver associated to the device, we use the generic PHY driver.
I thought the issue was the race condition between loading the module and the MAC attaching to it? We are getting the generic driver because the specific driver is still loading?
If that really is the issue, i think phy_attach_direct() should try loading the module again, doing it synchronously. Only when it fails should the generic driver be associated to the device.
Andrew
| |