Message-ID: <755130b4-2fab-2b53-456f-e2304b1922f2@gmail.com>
Date:   Wed, 24 Mar 2021 16:16:41 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Marek Behún <kabel@...nel.org>
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 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'?

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.

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

> 
> But otherwise it does not matter where this property is. Rob Herring
> says that maybe we don't need a new property at all. We can reuse
> phy-mode property of the MAC, and enumerate all supported modes there.
> 
>>
>>>
>>> When this property is present for a PHY node, only the phy-modes
>>> listed in this property should be considered to be functional on
>>> the board.  
>>
>> Can you post the code that is going to utilize these properties so we
>> have a clearer picture of how and what you need to solve?
> 
> I am still working on this, so the repo may change, but look at
> https://git.kernel.org/pub/scm/linux/kernel/git/kabel/linux.git/log/?h=phy-supported-interfaces
> at the last three patches.
> 

-- 
Florian

Powered by blists - more mailing lists