Re: [PATCH net-next 0/2] dt-bindings: define property describing supported ethernet PHY modes

On Wed, 24 Mar 2021 17:11:25 -0700
Florian Fainelli [off-list ref] wrote:

On 3/24/2021 4:45 PM, Marek Behún wrote:

quoted

On Wed, 24 Mar 2021 16:16:41 -0700
Florian Fainelli [off-list ref] wrote:
  

quoted

On 3/24/2021 4:00 PM, Marek Behún wrote:  

quoted

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

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.  

OK, so whenever there is a link change you are presumably reading the
mode in which the PHY has been reconfigured to, asking the MAC to
configured itself appropriately based on that, and if there is no
intersection, error out?

No. At initialization I tell the PHY to change between
  10gbase-r / 5gbase-r / 2500base-x / sgmii
according to the copper side. The PHY will do this alone on change on
copper side. I don't need to do this.

(This already works with current version of marvell10g driver - but
 kernel is not configuring this, it has to be configure via strapping
 pins.)

But I can tell the PHY at initialization to change instead between
  xaui / 5gbase-r / 2500base-x / sgmii
Again the PHY will do this on its own whenever speed on the copper side
changes.

But I need to know which of this settings I should use.

Marek