Message-ID: <CAJ+vNU3qCKzsK2XFj6Gj0vr4JfE=URYadWsr3xvxOO__MVNsPw@mail.gmail.com>
Date: Mon, 7 Oct 2024 11:18:56 -0700
From: Tim Harvey <tharvey@...eworks.com>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: netdev <netdev@...r.kernel.org>
Subject: Re: Linux network PHY initial configuration for ports not 'up'

On Mon, Oct 7, 2024 at 10:28 AM Florian Fainelli <f.fainelli@...il.com> wrote:
>
> 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.

Hi Florian,

Can you point me to an example of a driver that does 'not' do this? I
can not find an example where the PHY isn't UP regardless of the MAC
state (maybe I'm biased due to the boards I've been working with most
in the last couple of years) but then again its not because the MAC
driver brought the PHY up, its because it doesn't take it down and it
was up on power-up.

Some examples that I just looked at where if your OS does not bring up
the MAC the PHY is still UP
- imx8m FEC with DP83867 PHY
- KSZ9897S (ksz9447) switch/phy

>
> 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.

agreed... it seems wrong from a power perspective to have those PHY's
up. I recall not to many years ago when a Gbit PHY link cost 1W... and
I think we are currently way worse than that for a 10Gbps PHY link.

Then again think of the case where you have a switch with ports
unconfigured yet connected to a partner and all the LED's are lit up
(giving the impression visually that the ports are up).

>
> 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.

I agree that boot firmware can and perhaps should do this but often
the PHY config that is done in the boot loader gets undone in the
Linux PHY driver if the reset pin is exposed to the Linux or in some
cases by soft reset done in the Linux PHY driver, or in other cases
blatant re-configuration of LED's in the Linux PHY driver without
using DT properties (intel-xway.c does this).

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

one would think that makes sense as well but the case I just ran into
was where a KSZ9897S switch had a network cable to a link partner and
the link partner would 'flap' with its link giong up and down due to
EEE errata until the KSZ9897S port was brought up which disabled EEE.
In this specific case EEE could have been disabled in U-Boot but that
would also require some changes as U-Boot does the same thing as Linux
currently - it only configures PHY's that are active.

Best Regards,

Tim

Powered by blists - more mailing lists