Re: [PATCH net-next v5 2/8] net: mdio: realtek-rtl9300: Add polling documentation

[Andrew Lunn <andrew@lunn.ch>]

> Appreciate your feedback. I will sum up the situation and my point of 
> View about the C22 PHYs in this single answer.
> 
> Regarding speed detection: I ran a quick test and MAC side 100Mbit 
> detection works fine. So we have no issues there.

Just to be sure. You have a broken cable, so could trigger downshift?

Maybe some background is needed here. An ethernet cable has 4 twisted
pairs. All four are needed for > 100MBs operation. However, autoneg
can work with a broken cable where some pairs are O.K, and some are
broken. The PHYs negotiate a link, and then tries to actually use
it. They then find the broken pair. A downshift then occurs, they swap
to 100MBs, which only require two working pairs, not four. The phy
driver knows that the BMSR and STAT1000 don't give the true status of
the PHY, so it reads the vendor register 0x1a which is correct. phylib
should notice the difference and print the warning:

phy-core.c:	phydev_warn(phydev, "Downshift occurred from negotiated speed %s to actual speed %s, check cabling!\n",

and the MAC is told the true link speed via the adjust_link callback,
or the phylink equivalent.

I wounder what else the hardware polling is getting wrong. One obvious
thing to test is pause. Pause can be negotiated, or it can be
forced. I assume forced pause is broken, since that is configured
directly in the MAC. But it would be good to test negotiated pause as
well. EEE is very similar, negotiated, or forced. At least these you
can work around in the MAC driver, by just reporting EOPNOTSUPP in
ksettings_set. But downshift configuration does not come through the
MAC, the PHY driver defaults to enabled, as far as i remember. So you
are going to have to somehow special case the PHYs in these switches.

> Regarding hardware designs and page handling: I do not know where 
> your information about non-Realteak C22 PHY is from.

It was a comment from Chris Packham, to one of the versions of this
patchset.

This hardware polling might be good for a dumb unmanaged switch, where
there is an embedded Z80 or other similar MCU doing the minimum amount
of configuration, and no PHY drivers, just power on reset
defaults. But when Linux is used with proper drivers allowing full use
of the hardware, HW polling makes no sense, it is a broken
design. Yes, you can make the main use cases work, but i expect you
are going to find lots of broken corner cases.

	Andrew