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: <20230817180129.krlht3anaa752w46@skbuf> Date: Thu, 17 Aug 2023 21:01:29 +0300 From: Vladimir Oltean <olteanv@...il.com> To: "Russell King (Oracle)" <linux@...linux.org.uk> Cc: Andrew Lunn <andrew@...n.ch>, 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 Hi Russell, On Tue, Aug 15, 2023 at 11:13:07AM +0100, Russell King (Oracle) wrote: > There is one case that I have missed, and it's totally screwed by > this behaviour where a Marvell DSA switch is connected to a Marvell > PHY via a RGMII connection: > > DSA <---------------------------------> PHY > v v > dt-dsa-node { phy: dt-phy-node { > phy-handle = <&phy>; ... > phy-mode = "rgmii-foo"; }; > }; > > parses phy mode > configures for RGMII mode > configures RGMII delays associated > with phy-mode > calls phy_attach(..., mode); > phylib sets phy_dev->interface > PHY driver looks at > phydev->interface and > configures delays > > In this case, we have *both* ends configuring the RGMII delays and it > will not work - because having the DSA MAC end configure the delays > breaks the phylib model where the MAC *shouldn't* be configuring the > delays. > > So, should mv88e6xxx_mac_config() also be forcing all RGMII modes > in state->interface to be PHY_INTERFACE_MODE_RGMII when passing > that into mv88e6xxx_port_config_interface() if, and only if the > port is a user port? Or maybe if and only if the port is actually > connected to a real PHY? I'd tend to believe that you're right, this would be broken (and not just with Marvell RGMII PHYs). I was under the impression that mv88e6xxx_mac_config() will only configure the RGMII delays associated with phy-mode if the port is in fixed-link mode. But looking at the actual condition upon which mv88e6xxx_mac_config() decides to call mv88e6xxx_port_config_interface(), that is: if (mode != MLO_AN_PHY || !mv88e6xxx_phy_is_internal(chip, port)) mv88e6xxx_port_config_interface() and thus, an external PHY would return false for the first term of the OR operation, but true for the second, and it would proceed to configure the MAC-side RGMII delays, resulting in a double delay. However, I am not fully confident in my analysis, since I don't have mv88e6xxx hardware with an RGMII port to confirm. It's interesting that we haven't seen reports?
Powered by blists - more mailing lists