| Message ID | 20220504114703.1229615-1-festevam@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | net: phy: micrel: Do not use kszphy_suspend/resume for KSZ8061 | expand |
On Wed, May 04, 2022 at 08:47:03AM -0300, Fabio Estevam wrote: > From: Fabio Estevam <festevam@denx.de> > > Since commit f1131b9c23fb ("net: phy: micrel: use > kszphy_suspend()/kszphy_resume for irq aware devices") the following > NULL pointer dereference is observed on a board with KSZ8061: > > # udhcpc -i eth0 > udhcpc: started, v1.35.0 > 8<--- cut here --- > Unable to handle kernel NULL pointer dereference at virtual address 00000008 > pgd = f73cef4e > [00000008] *pgd=00000000 > Internal error: Oops: 5 [#1] SMP ARM > Modules linked in: > CPU: 0 PID: 196 Comm: ifconfig Not tainted 5.15.37-dirty #94 > Hardware name: Freescale i.MX6 SoloX (Device Tree) > PC is at kszphy_config_reset+0x10/0x114 > LR is at kszphy_resume+0x24/0x64 > ... > > The KSZ8061 phy_driver structure does not have the .probe/..driver_data > fields, which means that priv is not allocated. > > This causes the NULL pointer dereference inside kszphy_config_reset(). > > Fix the problem by using the generic suspend/resume functions as before. Hi Fabio 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 ksphy_driver structure, this seems to affect PHY_ID_KS8737 and PHY_ID_KSZ8061 Thanks Andrew
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
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c index 685a0ab5453c..11cd073630e5 100644 --- a/drivers/net/phy/micrel.c +++ b/drivers/net/phy/micrel.c @@ -3021,8 +3021,8 @@ static struct phy_driver ksphy_driver[] = { .config_init = ksz8061_config_init, .config_intr = kszphy_config_intr, .handle_interrupt = kszphy_handle_interrupt, - .suspend = kszphy_suspend, - .resume = kszphy_resume, + .suspend = genphy_suspend, + .resume = genphy_resume, }, { .phy_id = PHY_ID_KSZ9021, .phy_id_mask = 0x000ffffe,