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
| ||
|
Message-ID: <20230817182729.q6rf327t7dfzxiow@skbuf> Date: Thu, 17 Aug 2023 21:27:29 +0300 From: Vladimir Oltean <olteanv@...il.com> To: Andrew Lunn <andrew@...n.ch>, "Russell King (Oracle)" <linux@...linux.org.uk> Cc: 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 On Mon, Aug 14, 2023 at 07:05:19PM +0200, Andrew Lunn wrote: > 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, I'd argue that the MAC-PHY relationship between the DSA master and the CPU port is equally clear as between 2 arbitrary cascade ports. Which is: not clear at all. The RGMII standard does not talk about the existence of a MAC role and a PHY role, to my knowledge. These are 2 MACs back to back, in both cases. With rx-internal-delay-ps and tx-internal-delay-ps in each MAC node, you get the freedom of specifying RGMII delays in whichever way is needed, without baking in any assumption that the port plays the role of a PHY or not.
Powered by blists - more mailing lists