[PATCH] net: phy: micrel: Do not use kszphy_suspend/resume for KSZ8061

[PATCH] net: phy: micrel: Do not use kszphy_suspend/resume for KSZ8061

[Fabio Estevam]

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.

Cc: stable@vger.kernel.org
Fixes: f1131b9c23fb ("net: phy: micrel: use kszphy_suspend()/kszphy_resume for irq aware devices")
Signed-off-by: Fabio Estevam <festevam@denx.de>
---
 drivers/net/phy/micrel.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

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,
-- 
2.25.1

Re: [PATCH] net: phy: micrel: Do not use kszphy_suspend/resume for KSZ8061

[Andrew Lunn]

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

Re: [PATCH] net: phy: micrel: Do not use kszphy_suspend/resume for KSZ8061

[Fabio Estevam]

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