netdev - Re: dsa: phy started on dsa_register

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

Message-ID: <a8c1bd9a16ad146e80e4e575441780f5c556d6be.camel@siemens.com>
Date:   Mon, 23 Jan 2023 21:15:01 +0000
From:   "Sverdlin, Alexander" <alexander.sverdlin@...mens.com>
To:     "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "andrew@...n.ch" <andrew@...n.ch>
CC:     "olteanv@...il.com" <olteanv@...il.com>,
        "Freihofer, Adrian" <adrian.freihofer@...mens.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: dsa: phy started on dsa_register_switch()

Hi Andrew,

On Mon, 2023-01-23 at 20:49 +0100, Andrew Lunn wrote:
> There are a number of MACs which do the connect in the probe. Both
> are
> considered correct, and doing it in probe has advantages, such as
> being able to return -EPROBE_DEFER because the PHY has not appeared
> yet.
> 
> It should also be noted that phylib will not explicitly down a PHY
> during the PHYs probe. So if the PHY is strapped to come up on power
> up, or something else like the bootloader to brought it up, it will
> remain up.
> 
> > I am sensitive to the power management aspect that getting the PHY
> > and
> > Ethernet link negotiated and then (re)negotiated several times
> > through a
> > products' boot cycle is a waste of energy and too many times do we
> > break and
> > make the link. The security aspect, I am less sensitive since the
> > PHY is not
> > how it should be enforced.
> 
> There are also people who as sensitive to the time it takes to
> establish link. Auto-neg takes around 1.5 seconds. In some embedded
> uses cases, that can be a long time, they want to avoid waiting for
> that by strapping the PHY to start autoneg on power on, so it might
> be
> ready to go by the time userspace ifup's the interface.
> 
> In general, PHY LEDs are a wild west in Linux, no well defined
> behaviour. So i expect there are traditional NICs whos LEDs are on
> when the link is admin down.

thank you for the explanation!

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com