Phy with reset-gpio fails to read phy id during kexec -e

Phy with reset-gpio fails to read phy id during kexec -e

[Xiaolei Wang]

Hi

During kexec -e, I found that the network card did not work when loading 
the kernel.

I found that some phys used reset-gpios. When kexec -e is running,

the network port will do_ifdown, and phy_detach() will be called at

this time, which will call phy_device_reset(phydev, 1); to keep phy in

reset state.

After loading the kernel, since phy is always in reset state, the mdio

controller fails to access phy id. Therefore, if phy uses reset-gpios

during kexec -e, the network port will not work. However, I have not

found a better solution. Can anyone give some suggestions?


kexec -e:

phy is always in reset state

   pca953x_gpio_set_value+0x8c/0xf8
   gpiochip_set+0x60/0x12c
   gpiod_set_raw_value_commit+0xe8/0x1e4
   gpiod_set_value_nocheck+0x58/0xe4
   gpiod_set_value_cansleep+0x4c/0xa8
   mdio_device_reset+0x48/0x158
   phy_detach+0x144/0x258
   phy_disconnect+0x54/0x74
   fec_enet_close+0x58/0x218

After loading kernel, reading phy id will report an error:

      mdio_bus 42890000.ethernet-1: MDIO device at address 2 is missing

   __of_mdiobus_parse_phys+0x260/0x338
   __of_mdiobus_register+0x118/0x28c
   fec_probe+0x173c/0x199c


thanks

xiaolei

Re: Phy with reset-gpio fails to read phy id during kexec -e

[Russell King (Oracle)]

On Wed, Jul 16, 2025 at 03:55:30PM +0800, Xiaolei Wang wrote:
> Hi
> 
> During kexec -e, I found that the network card did not work when loading the
> kernel.
> 
> I found that some phys used reset-gpios. When kexec -e is running,
> the network port will do_ifdown, and phy_detach() will be called at
> this time, which will call phy_device_reset(phydev, 1); to keep phy in
> reset state.
> 
> After loading the kernel, since phy is always in reset state, the mdio
> controller fails to access phy id. Therefore, if phy uses reset-gpios
> during kexec -e, the network port will not work. However, I have not
> found a better solution. Can anyone give some suggestions?

Honestly, I fail to see why we give the kernel control of the PHY reset
signal. It causes masses of problems, mostly centred around exactly the
situation you're seeing, and we have to put workarounds to encode the
PHY ID in DT. That then leads to situations where, if the PHY is ever
changed during the production run, we need different DT files, or we
need boot firmware modified to update the DT passed to the kernel.

I think we need to scrap the whole idea of placing the PHY in reset.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!