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]

Date:   Sun, 24 Feb 2019 18:28:48 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
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 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.

      Andrew