netdev - Re: [PATCH net-next] net: dsa: mark parsed interface mode for legacy switch drivers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8687110a-5ce8-474c-8c20-ca682a98a94c@lunn.ch>
Date: Mon, 14 Aug 2023 19:05:19 +0200
From: Andrew Lunn <andrew@...n.ch>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Vladimir Oltean <olteanv@...il.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	netdev@...r.kernel.org
Subject: Re: [PATCH net-next] net: dsa: mark parsed interface mode for legacy
 switch drivers

> > RGMII on both ends is unlikely to work, so probably one is
> > wrong. Probably the switch has strapping to set it to rgmii-id, but we
> > don't actually know that. And i guess we have no ability to find out
> > the truth?
> 
> "rgmii" on both ends _can_ work - from our own documentation:
> 
> * PHY_INTERFACE_MODE_RGMII: the PHY is not responsible for inserting any
>   internal delay by itself, it assumes that either the Ethernet MAC (if capable)
>   or the PCB traces insert the correct 1.5-2ns delay
>      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> So, if the board is correctly laid out to include this delay, then RGMII
> on both ends can work.

Yes, which is why is said 'unlikely', not 'will not'. I've not come
across many boards which do have extra long clock tracks, so it is
unlikely this board has them. It is much more likely to be strapped to
do rgmii-id.

> Next, we have no ability to find anything out - we have no hardware.
> LinusW does, but I have no idea whether Linus can read the state of the
> pin strapping. I can see from the RTL8366 info I found that there is
> a register that the delay settings can be read from, but this is not
> the RTL8366, it's RTL8366RB, which Linus already pointed out is
> revision B and is different. So, I would defer to Linus for anything on
> this, and without input from Linus, all we have to go on is what we
> have in the kernel sources.
> 
> > So a narrow definition seems reasonable at the moment, to raise a red
> > warning flag if somebody does try to use rgmii-id which is not
> > actually implemented in the driver. And that user then gets to sort
> > out the problem.
> 
> I think Vladimir will be having a party, because that's now two of us
> who've made the mistake of infering that "phy-mode" changes the
> configuration at the end that has that specified (I can hear the
> baloons being inflated!)
> 
> Of course it shouldn't, as per our documentation on RGMII delays in
> Documentation/networking/phy.rst that was added by Florian back in
> November 2016.

It might not be documented, but there are a couple of DSA drivers
which do react on this property and set their RGMII delays based on
this for their CPU port. mv88e6xxx is one of them, and it also does so
for DSA ports. 

> This brings up the obvious question: does anyone deal with the RGMII
> delays with DSA switches in software, or is it all done by hardware
> pin strapping, hardware defaults, and/or a correctly laid out PCB?

arch/arm/boot/dts/nxp/vf/vf610-zii-dev-rev-b.dts:
                                       switch0port5: port@5 {
                                                reg = <5>;
                                                label = "dsa";
                                                phy-mode = "rgmii-txid";
                                                link = <&switch1port6
                                                        &switch2port9>;
                                                fixed-link {
                                                        speed = <1000>;
                                                        full-duplex;
                                                };
                                        };

and the other end of this link:

                                        switch1port6: port@6 {
                                                reg = <6>;
                                                label = "dsa";
                                                phy-mode = "rgmii-txid";
                                                link = <&switch0port5>;
                                                fixed-link {
                                                        speed = <1000>;
                                                        full-duplex;
                                                };
                                        };

imx7d-zii-rpu2.dts:
                                port@5 {
                                        reg = <5>;
                                        label = "cpu";
                                        ethernet = <&fec1>;
                                        phy-mode = "rgmii-id";

                                        fixed-link {
                                                speed = <1000>;
                                                full-duplex;
                                        };
                                };

With the 'cpu' case, it is clearly acting like a PHY to the SoCs MAC,
so it does not seem too unreasonable for it to act upon it. For a DSA
link there is not a clear MAC-PHY relationship, but we do somehow need
to specify delays.

	Andrew