Hi Andrew,
On Wed, May 4, 2022 at 9:19 AM Andrew Lunn andrew@lunn.ch 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