On 3/24/2021 4:00 PM, Marek Behún wrote:
> On Wed, 24 Mar 2021 14:19:28 -0700
> Florian Fainelli <f.faine...@gmail.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
