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]
Date: Tue, 15 Aug 2023 11:13:07 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Andrew Lunn <andrew@...n.ch>
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

On Mon, Aug 14, 2023 at 11:03:00PM +0100, Russell King (Oracle) wrote:
> Then we have the DSA side:
> 
>    DSA <------------------------------> Fixed-PHY
>     v					    v
> dt-dsa-node {				No DT node
>   phy-mode = "rgmii-foo";
>   fixed-link {
>    ...
>   };
> };
> 
> parses phy mode
> configures for RGMII mode
> configures RGMII delays associated
>  with phy-mode
> calls phy_attach(..., mode);
> phylib sets phy_dev->interface
> 					Generic PHY driver ignores
> 					phy_dev->interface

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?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ