netdev - Re: [net-next,v1] net: phy: phy_device: fix PHY WOL enabled, PM failed to suspend

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: <6124782dffadef83707edc7fd4d87a327d5cba1b.camel@redhat.com>
Date: Tue, 09 Jul 2024 10:34:57 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Youwan Wang <youwan@...china.com>, andrew@...n.ch
Cc: hkallweit1@...il.com, linux@...linux.org.uk, davem@...emloft.net, 
	edumazet@...gle.com, kuba@...nel.org, netdev@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [net-next,v1] net: phy: phy_device: fix PHY WOL enabled, PM
 failed to suspend

Hi,

On Thu, 2024-07-04 at 20:32 +0800, Youwan Wang wrote:
> If the PHY of the mido bus is enabled with Wake-on-LAN (WOL),
> we cannot suspend the PHY. Although the WOL status has been
> checked in phy_suspend(), returning -EBUSY(-16) would cause
> the Power Management (PM) to fail to suspend. Since
> phy_suspend() is an exported symbol (EXPORT_SYMBOL),
> timely error reporting is needed. Therefore, an additional
> check is performed here. If the PHY of the mido bus is enabled
> with WOL, we skip calling phy_suspend() to avoid PM failure.
> 
> Thank you all for your analysis.

Please, use an incremental version number (in this case: 'v2') when
sending a new revision of this patch, it will make easier to track the
previous discussion. Even when the changes affect only the
changelog/commit message.

> I am using the Linux kernel version 6.6, the current system is
> utilizing ACPI firmware. However, in terms of configuration,
> the system only includes MAC layer configuration while lacking
> PHY configuration. Furthermore, it has been observed that the
> phydev->attached_dev is NULL, phydev is "stmmac-0:01", it not
> attached, but it will affect suspend and resume. The actually
> attached "stmmac-0:00" will not dpm_run_callback():
> mdio_bus_phy_suspend().

It looks like the underlying issue is still under investigation.
As noted by Andrew, the NULL attached_dev hints at some other root
cause issue, possibly elsewhere. Please reply to Andrew's questions:

https://lore.kernel.org/netdev/b61cae2b-6b94-465e-b4e4-6c220c6c66d9@lunn.ch/

before posting a new revision. At very least the replies should be
reflected in some additional info in the commit message.

Thanks,

Paolo