Hi Andrew, On Wed, May 4, 2022 at 9:19 AM Andrew Lunn <andrew@xxxxxxx> wrote: > Thanks for the fix. What you fail to mention is why not call > kszphy_probe() to populate priv? What makes this PHY special that it > does not need the probe call? Looking at the driver history, it has been like this since the beginning. Adding kszphy_probe() only causes another NULL pointer dereference. I would need to add both kszphy_probe() and driver_data. Both can be added, but I don't think this would be material for stable. I would not like to add a wrong driver_data and cause other problems. IMHO, I would prefer to restore the Ethernet functionality first, then if someone is certain on the proper driver data, this could be added to net-next. > Looking at the ksphy_driver structure, this seems to affect > PHY_ID_KS8737 and PHY_ID_KSZ8061 Good catch, thanks. ksz8737 has a .driver_data field, so I can add .driver_probe there. For v2 I plan: - Send two patch as a series: patch 1/2 would be same as this one patch 2/2 would pass driver_probe to ksz8737 Do you agree? Thanks
