[PATCH net-next 3/6] net: dsa: add support for retrieving the interface mode

Andrew Lunn andrew at lunn.ch
Fri Jul 22 14:53:48 PDT 2022


> I still don't understand your point - because you seem to be conflating
> two different things (at least as I understand it.)
> 
> We have this:
> 
> 		port at N {
> 			reg = <N>;
> 			label = "cpu";
> 			ethernet = <&ethX>;
> 		};
> 
> This specifies that the port operates at whatever interface mode and
> settings gives the maximum speed. There is no mention of a "managed"
> property, and therefore (Andrew, correct me if I'm wrong) in-band
> negotiation is not expected to be used.

I would actually say it is undefined if in-band is expected or
not. Pretty much everything is undefined, expect 'maximum speed'.

If you can choose between SGMII and 1000BaseX, GMII or RGMII, it is
not defined which you should pick. However generally, *MII and a
SERDES are mutually exclusive in hardware, except for the 6352 which
have some ports with both. The switches do have strapping pins which
can configure most ports into specific modes, which is probably want
most boards do, and the "maximum speed" probably does not in fact
adjust the port mode unless really required. It does however configure
the MAC to fixed speed. There is a degree of separation between the
MAC and the internal PHY/PCS. So the MAC could be fixed, and the PCS
is probably using its power up defaults which could be to perform
in-band signalling. And it is very likely the results from that in
band signalling is ignored by the MAC.

So this is all pretty fragile, but that is the way this has all
evolved over time for the mv88e6xxx driver. And so far, boards
continue to work, or at least, we are not going reports they are
broken. That however does not mean it will not all implode sometime in
the future, and we probably should be asking new submissions to always
use a fixed-link and a phy-mode, even if it is not strictly needed.

	Andrew



More information about the linux-arm-kernel mailing list