Thread (123 messages) 123 messages, 7 authors, 2022-07-26

Re: [PATCH net-next v3 08/47] net: phylink: Support differing link speeds and interface speeds

From: Sean Anderson <hidden>
Date: 2022-07-18 15:49:47
Also in: linux-arm-kernel, lkml

On 7/16/22 9:26 PM, Andrew Lunn wrote:
quoted
quoted
This seem error prone when new PHY_INTERFACE_MODES are added. I would
prefer a WARN_ON_ONCE() in the default: so we get to know about such
problems.
Actually, this is the reason I did not add a default: clause to the
switch (and instead listed everything out). If a new interface mode is
added, there will be a warning (as I discovered when preparing this
patch).
Ah, the compiler produces a warning. O.K. that is good. Better than an
WARN_ON_ONCE at runtime.
quoted
quoted
Bike shedding a bit, but would it be better to use host_side_speed and
line_side_speed? When you say link_speed, which link are your
referring to? Since we are talking about the different sides of the
PHY doing different speeds, the naming does need to be clear.
When I say "link" I mean the thing that the PMD speaks. That is, one of
the ethtool link mode bits. I am thinking of a topology like


MAC (+PCS) <-- phy interface mode (MII) --> phy <-- link mode --> far-end phy

The way it has been done up to now, the phy interface mode and the link
mode have the same speed. For some MIIs, (such as MII or GMII) this is
actually the case, since the data clock changes depending on the data
speed. For others (SGMII/USXGMII) the data is repeated, but the clock
rate stays the same. In particular, the MAC doesn't care what the actual
link speed is, just what configuration it has to use (so it selects the
right clock etc).

The exception to the above is when you have no phy (such as for
1000BASE-X):

MAC (+PCS) <-- MDI --> PMD <-- link mode --> far-end PMD

All of the phy interface modes which can be used this way are
"non-adaptive." That is, in the above case they have a fixed speed.

That said, I would like to keep the "phy interface mode speed" named
"speed" so I don't have to write up a semantic patch to rename it in all
the drivers.
So you want phydev->speed to be the host side speed. That leaves the
line side speed as a new variable, so it can be called line_side_speed?

I just find link_speed ambiguous, and line_side_speed less so.
I would rather use something with "link" to match up with
ETHTOOL_LINK_MODE_*. Ideally "speed" would be something like
"interface_speed" to match up with PHY_INTERFACE_MODE_*.
The documentation for phydev->speed needs updating to make it clear it
is the host side speed.
OK

--Sean
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help