netdev - Re: No traffic with Marvell switch and latest linux-next

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: <20190224194147.u3huzvd3czutd7ec@shell.armlinux.org.uk>
Date:   Sun, 24 Feb 2019 19:41:47 +0000
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Heiner Kallweit <hkallweit1@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: No traffic with Marvell switch and latest linux-next

On Sun, Feb 24, 2019 at 06:28:48PM +0100, Andrew Lunn wrote:
> On Sun, Feb 24, 2019 at 03:31:26PM +0000, Russell King - ARM Linux admin wrote:
> > On Sun, Feb 24, 2019 at 12:42:35AM +0100, Andrew Lunn wrote:
> > > Looking forward, at some point we are going to have to make fixed-link
> > > support higher speeds. That probably means we need a swphy-c45 which
> > > emulates the standard registers for 2.5G, 5G and 10G. At that point
> > > genphy will not work...
> > 
> > Do we _need_ to emulate Clause 45 PHYs?
> 
> Hi Russell
> 
> One use case would be a mv88e6390X port 9 or 10 connected to a SoC
> which can only do 2.5G.
> 
> We have defined that DSA drivers should configure CPU and DSA ports to
> their maximum speed. So if port 9 or 10 is used, it should be
> configured to 10G.
> 
> We then need some way to reconfigure the MAC to a slower speed.
> 
> We need to do this with ZII boards. We do this with:
> 
>                                         port@0 {
>                                                 reg = <0>;
>                                                 label = "cpu";
>                                                 ethernet = <&fec1>;
> 
>                                                 fixed-link {
>                                                         speed = <100>;
>                                                         full-duplex;
>                                                 };
>                                         };
> 
> The FEC can only do 100Mbs, but the switch defaults to 1G. So the
> fixed link it used to tell the switch MAC to use 100/Full.
> 
> In the example of the 6390X, we would want to set the link speed to
> 2500, which we cannot do at the moment. Either we need fixed-link to
> support higher speeds, or we need a different mechanism.
> 
> We also have a similar issue on the SoC side. The FEC has no PHY
> connected to it. It needs to be told what speed to do:
> 
> &fec1 {
>         phy-mode = "rmii";
>         pinctrl-names = "default";
>         pinctrl-0 = <&pinctrl_fec1>;
>         status = "okay";
> 
>         fixed-link {
>                    speed = <100>;
>                    full-duplex;
>         };
> 
> In the case of a SoC with an interface which can do 2.5G, you need to
> tell it to do 2.5G. Ideally we want a mechanism that allows a MAC to
> 'see' a PHY operating at 2.5G using the standard phylib/phylink API.
> 
> In the past this has been achieved with an emulated PHY. But so long
> as the phydev/phylink structure has the correct values, it does not
> matter how they get those values.

You'll get a mac_config() with the mode set to MLO_AN_FIXED.

state->speed set to whatever was set in the "speed =" and state->duplex
set according to the duplex property.  If pause modes are also defined,
you'll get those through state->pause MLO_PAUSE_SYM and MLO_PAUSE_ASYM,
but there won't be any resolution of those modes since a fixed link
doesn't know the other ends properties, and of course AN is disabled.

Apart from the pause modes, the information passed to the MAC for a
fixed link is exactly the same as if it came from a PHY in phylib,
which basically means the MAC side doesn't actually need to care
whether it has a PHY or fixed-link - but without the complication of
needing phylib to provide an emulated PHY to the network driver.

phylink does provide an emulated PHY for the mii ioctls since that is
an established interface for speeds <= 1G.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up