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

[Florian Fainelli <f.fainelli@gmail.com>]

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