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 [off-list ref] wrote:

quoted

quoted

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.

quoted

quoted

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.

quoted

quoted

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