[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aHeEPh9-itz4nGYH@shell.armlinux.org.uk>
Date: Wed, 16 Jul 2025 11:51:42 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Xiaolei Wang <xiaolei.wang@...driver.com>
Cc: andrew@...n.ch, hkallweit1@...il.com, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Phy with reset-gpio fails to read phy id during kexec -e
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!
Powered by blists - more mailing lists