netdev - Re: [RFC] net: phy: add shutdown hook to struct phy

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

Date:   Wed, 30 Sep 2020 21:09:11 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Jisheng Zhang <Jisheng.Zhang@...aptics.com>
Cc:     Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC] net: phy: add shutdown hook to struct phy_driver

On Wed, Sep 30, 2020 at 05:47:43PM +0800, Jisheng Zhang wrote:
> Hi,
> 
> A GE phy supports pad isolation which can save power in WOL mode. But once the
> isolation is enabled, the MAC can't send/receive pkts to/from the phy because
> the phy is "isolated". To make the PHY work normally, I need to move the
> enabling isolation to suspend hook, so far so good. But the isolation isn't
> enabled in system shutdown case, to support this, I want to add shutdown hook
> to net phy_driver, then also enable the isolation in the shutdown hook. Is
> there any elegant solution?

> Or we can break the assumption: ethernet can still send/receive pkts after
> enabling WoL, no?

That is not an easy assumption to break. The MAC might be doing WOL,
so it needs to be able to receive packets.

What you might be able to assume is, if this PHY device has had WOL
enabled, it can assume the MAC does not need to send/receive after
suspend. The problem is, phy_suspend() will not call into the driver
is WOL is enabled, so you have no idea when you can isolate the MAC
from the PHY.

So adding a shutdown in mdio_driver_register() seems reasonable.  But
you need to watch out for ordering. Is the MDIO bus driver still
running?

   Andrew