netdev - Re: Cutting the link on ndo_stop - phy_stop or 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3a408f0f-418a-918d-bc9a-29085cdf1636@gmail.com>
Date:   Tue, 4 Jun 2019 13:25:47 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vladimir Oltean <olteanv@...il.com>,
        "linux@...linux.org.uk" <linux@...linux.org.uk>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "andrew@...n.ch" <andrew@...n.ch>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Cc:     Ioana Ciornei <ioana.ciornei@....com>
Subject: Re: Cutting the link on ndo_stop - phy_stop or phy_disconnect?



On 6/4/2019 12:58 PM, Vladimir Oltean wrote:
> Hi,
> 
> I've been wondering what is the correct approach to cut the Ethernet
> link when the user requests it to be administratively down (aka ip link
> set dev eth0 down).
> Most of the Ethernet drivers simply call phy_stop or the phylink
> equivalent. This leaves an Ethernet link between the PHY and its link
> partner.
> The Freescale gianfar driver (authored by Andy Fleming who also authored
> the phylib) does a phy_disconnect here. It may seem a bit overkill, but
> of the extra things it does, it calls phy_suspend where most PHY drivers
> set the BMCR_PDOWN bit. Only this achieves the intended purpose of also
> cutting the link partner's link on 'ip link set dev eth0 down'.
> What is the general consensus here?
> I see the ability to be able to put the PHY link administratively down a
> desirable feat. If it's left to negotiate/receive traffic etc while the
> MAC driver isn't completely set up and ready, in theory a lot of
> processing can happen outside of the operating system's control.

What would seem sensible from my perspective is the following: upon
ndo_stop() the PHY is brought into the lowest power mode available,
unless the device is used for Wake-on-LAN, in which case, an appropriate
low power mode (e.g.: 10Mbps/half receive only) allowing WoL to function
can be selected.
-- 
Florian