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

["Russell King (Oracle)" <linux@armlinux.org.uk>]

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!