Subject: Re: [PATCH net-next v2 04/10] net: phy: Automatically fill the generic TP, FIBRE and Backplane modes

From: Maxime Chevallier <[email-masked]>
Date: Thu, 7 Feb 2019 15:49:10 +0100

Hello Andrew,

On Thu, 7 Feb 2019 15:09:39 +0100
Andrew Lunn <[email-masked]> wrote:

>On Thu, Feb 07, 2019 at 10:49:33AM +0100, Maxime Chevallier wrote:
>> PHY advertised and supported linkmodes contain both specific modes such
>> as 1000BASET Half/Full and generic ones such as TP that represent a
>> class of modes.
>> 
>> Since some modes such as Fibre, TP or Backplane match a wide range of
>> specific modes, we can automatically set these bits if one of the
>> specific modes it corresponds to is present in the list.
>> 
>> The 'TP' bit is set whenever there's a BaseT linkmode in
>> phydev->supported.
>> 
>> The 'FIBRE' bit is set for BaseL, BaseS and BaseE linkmodes.
>> 
>> Finally, the 'Backplane' is set whenever a BaseK mode is supported.  
>
>Hi Maxime
>
>Interesting idea.
>
>But what exactly are we supposed to be representing here?  That PHY
>can do these modes, or that the port exists on the device? The
>marvell10g can do fibre, but do all boards have an SFP/SFF, or do some
>only have an RJ-45 for TP? Are there boards without TP and just
>SFP/SFF?

My understanding is that this would represent what the PHY is capable
of, at least when set in the supported field, but I agree that this
doesn't reflect what's on the device.

I extrapolated this logic from the ability detection in marvell10g,
that would set these bits according to the abilities reported by the
PHY. This was done based on the PHY register values, instead of the
linkmodes in the 'supported' field.

>Is there documentation in ethtool which gives a clue as to what is
>expected?

Not really, at least to my knowledge. I think this would be used by
"ethtool -s ethX port tp|fibre|aui|etc". Maybe this could be useful if
we decide to implement port selection with ethtool on the MCBin, but I'm
getting a bit ahead of myself.

Thanks,

Maxime