netdev - Re: Linux network PHY initial configuration for ports not 'up'

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]

Message-ID: <c572529e-78c4-42d5-a799-1027fd5fca29@gmail.com>
Date: Mon, 7 Oct 2024 10:28:43 -0700
From: Florian Fainelli <f.fainelli@...il.com>
To: Tim Harvey <tharvey@...eworks.com>, netdev <netdev@...r.kernel.org>
Subject: Re: Linux network PHY initial configuration for ports not 'up'

On 10/7/24 09:48, Tim Harvey wrote:
> Greetings,
> 
> What is the policy for configuration of network PHY's for ports that
> are not brought 'up'?
> 
> I work with boards with several PHY's that have invalid link
> configuration which does not get fixed until the port is brought up.
> One could argue that this is fine because the port isn't up but in the
> case of LED misconfiguration people wonder why the LED's are not
> configured properly until the port is brought up (or they wonder why
> LEDs are ilumnated at all for a port that isn't up). Another example
> would be a PHY with EEE errata where EEE should be disabled but this
> doesn't happen utnil the port is brought up yet while the port is
> 'down' a link with EEE is still established at the PHY level with a
> link partner. One could also point out that power is being used to
> link PHY's that should not even be linked.
> 
> In other words, should a MAC driver somehow trigger a PHY to get
> initialized (as in fixups and allowing a physical link) even if the
> MAC port is not up? If so, how is this done currently?

There are drivers that have historically brought up Ethernet PHYs in the 
MAC's probe routine. This is fine in premise, and you get a bit of speed 
up because by the time the network interface is opened by user-space you 
have usually finished auto-negotiation. This does mean that usually the 
PHY is already in the UP state.

The caveat with that approach is that it does not conserve power, and it 
assumes that the network device will end-up being used shortly 
thereafter, which is not a given.

For LEDs, I would argue that if you care about having some sensible 
feedback, the place where this belongs is the boot loader, because you 
can address any kernel short comings there: lack of a kernel driver for 
said PHY/MAC, network never being brought up, etc.

For errata like EEE, it seems fine to address that at link up time.
-- 
Florian