lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ