linux-kernel - 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-next>] [day] [month] [year] [list]

Message-ID: <b61cae2b-6b94-465e-b4e4-6c220c6c66d9@lunn.ch>
Date: Mon, 1 Jul 2024 18:32:04 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Youwan Wang <youwan@...china.com>
Cc: davem@...emloft.net, edumazet@...gle.com, hkallweit1@...il.com,
	kuba@...nel.org, linux-kernel@...r.kernel.org,
	linux@...linux.org.uk, netdev@...r.kernel.org, pabeni@...hat.com
Subject: Re: [net-next,v1] net: phy: phy_device: fix PHY WOL enabled, PM
 failed to suspend

On Mon, Jul 01, 2024 at 02:21:44PM +0800, Youwan Wang wrote:

Please always start a new thread with a new version of a
patchset. Tools like patchwork require this, and without the patchset
in patchwork, it is not going to be applied.

> 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.
> 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
> 
> Is it possible to add a judgment about netdev is NULL?
> if (!netdev && phydev->wol_enabled &&
>     !(phydrv->flags & PHY_ALWAYS_CALL_SUSPEND))

Comments like this should be placed below the --- so they don't make
it into the commit message.

Why is phydev->attached_dev NULL? Was a MAC never attached to the PHY?
Has the MAC disconnected the PHY as part of the suspend? It would be
odd that a device being used for WoL would disconnect the PHY.

> 
> log:
> [  322.631362] OOM killer disabled.
> [  322.631364] Freezing remaining freezable tasks
> [  322.632536] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
> [  322.632540] printk: Suspending console(s) (use no_console_suspend to debug)
> [  322.633052] YT8521 Gigabit Ethernet stmmac-0:01:
> PM: dpm_run_callback(): mdio_bus_phy_suspend+0x0/0x110 [libphy] returns -16
> [  322.633071] YT8521 Gigabit Ethernet stmmac-0:01:
> PM: failed to suspend: error -16
> [  322.669699] PM: Some devices failed to suspend, or early wake event detected
> [  322.669949] OOM killer enabled.
> [  322.669951] Restarting tasks ... done.
> [  322.671008] random: crng reseeded on system resumption
> [  322.671014] PM: suspend exit
> 
> If the YT8521 driver adds phydrv->flags, ask the YT8521 driver to process
> WOL at suspend and resume time, the phydev->suspended_by_mdio_bus=1
> flag would cause the resume failure.
> 
> log:
> [  260.814763] YT8521 Gigabit Ethernet stmmac-0:01:
> PM: dpm_run_callback():mdio_bus_phy_resume+0x0/0x160 [libphy] returns -95
> [  260.814782] YT8521 Gigabit Ethernet stmmac-0:01:
> PM: failed to resume: error -95

-95 is EOPNOTSUPP. Where is that coming from?

	Andrew