Message-ID: <20210325004525.734f3040@thinkpad>
Date:   Thu, 25 Mar 2021 00:45:25 +0100
From:   Marek Behún <kabel@...nel.org>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     netdev@...r.kernel.org, Andrew Lunn <andrew@...n.ch>,
        "David S . Miller" <davem@...emloft.net>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <rmk+kernel@...linux.org.uk>,
        Rob Herring <robh@...nel.org>, devicetree@...r.kernel.org,
        pali@...nel.org
Subject: Re: [PATCH net-next 0/2] dt-bindings: define property describing
 supported ethernet PHY modes

On Wed, 24 Mar 2021 16:16:41 -0700
Florian Fainelli <f.fainelli@...il.com> wrote:

> On 3/24/2021 4:00 PM, Marek Behún wrote:
> > On Wed, 24 Mar 2021 14:19:28 -0700
> > Florian Fainelli <f.fainelli@...il.com> wrote:
> >   
> >>> Another problem is that if lower modes are supported, we should
> >>> maybe use them in order to save power.    
> >>
> >> That is an interesting proposal but if you want it to be truly valuable,
> >> does not that mean that an user ought to be able to switch between any
> >> of the supported PHY <=> MAC interfaces at runtime, and then within
> >> those interfaces to the speeds that yield the best power savings?  
> > 
> > If the code determines that there are multiple working configurations,
> > it theoretically could allow the user to switch between them.
> > 
> > My idea was that this should be done by kernel, though.
> > 
> > But power saving is not the main problem I am trying to solve.
> > What I am trying to solve is that if a board does not support all modes
> > supported by the MAC and PHY, because they are not wired or something,
> > we need to know about that so that we can select the correct mode for
> > PHYs that change this mode at runtime.  
> 
> OK so the runtime part comes from plugging in various SFP modules into a
> cage but other than that, for a "fixed" link such as a SFF or a soldered
> down PHY, do we agree that there would be no runtime changing of the
> 'phy-mode'?

No, we do not. The PHY can be configured (by strapping pins or by
sw) to change phy-mode depending on the autonegotiated copper speed.

So if you plug in an ethernet cable where on the otherside is only 1g
capable device, the PHY will change mode to sgmii. But if you then plug
a 5g capable device, the PHY will change mode to 5gbase-r.

This happens if the PHY is configured into one of these changing
configurations. It can also be configured to USXGMII, or 10GBASER with
rate matching.

Not many MACs in kernel support USXGMII currently.

And if you use rate matching mode, and the copper side is
linked in lower speed (2.5g for example), and the MAC will start
sending too many packets, the internal buffer in the PHY is only 16 KB,
so it will fill up quickly. So you need pause frames support. But this
is broken for speeds <= 1g, according to erratum.

So you really want to change modes. The rate matching mode is
basically useless.

> 
> What I am trying to understand is why this needs to be added to the
> Device Tree as opposed to a bitmask within the PHY driver that indicates
> the various interface mode capabilities which, looking at the code you
> shared below, is how you make decisions ultimately.

Because someone can create a board with a SOC where MAC is capable of
all of the following modes: 10gbase-r, xaui, rxaui, 5gbase-r,
2.5gbase-x, sgmii.

And use Marvell 88X3310 PHY to translate to copper.

But only wire the PHY to the MAC with one SerDes lane. So for 10g,
10gbase-r mode must be used, xaui and rxaui cannot.
Or wire the PHY to the MAC with 2 SerDes lanes, but both lanes capable
only of 6 GHz freq. So for 10g, rxaui must be used.

And then make the mistake of wiring the strapping pins to the
rate-matching mode, which is useless.

So we need to know which modes are supported if we want to change the
configuration to a working one.

> >   
> >>>
> >>> But for this we need to know which phy-modes are supported on the
> >>> board.
> >>>
> >>> This series adds documentation for a new ethernet PHY property,
> >>> called `supported-mac-connection-types`.    
> >>
> >> That naming does not quite make sense to me, if we want to describe the
> >> MAC supported connection types, then those would naturally be within the
> >> Ethernet MAC Device Tree node, no? If we are describing what the PHY is
> >> capable, then we should be dropping "mac" from the property name not to
> >> create confusion.  
> > 
> > I put "mac" there to indicate that this is the SerDes to the MAC (i.e.
> > host side in Marvell PHY). 88X3310 has another SerDes side (Fiber Side).
> > I guess I put "mac" there so that if in the future we wanted to specify
> > supported modes for the fiber side, we could add
> > `supported-fiber-connection-types`.  
> 
> You would traditionally find the words "line side" (copper, optical,
> etc.) and "MAC side" being used in datasheets, maybe you can use a
> similar naming here?

So
  supported-connection-types-mac-side
  supported-connection-types-line-side
or maybe media-side?

I am still exploring whether this could be simply defined in the
ethernet controllers `phy-mode` property, as Rob Herring says. It would
be simpler...

Marek

Powered by blists - more mailing lists