netdev - Re: [PATCH] net: dsa: mv88e6xxx: don't force settings on CPU port

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: <20200327211821.GT3819@lunn.ch>
Date:   Fri, 27 Mar 2020 22:18:21 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Daniel Mack <daniel@...que.org>
Cc:     vivien.didelot@...il.com, f.fainelli@...il.com,
        davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: [PATCH] net: dsa: mv88e6xxx: don't force settings on CPU port

On Fri, Mar 27, 2020 at 09:48:56PM +0100, Daniel Mack wrote:
> Hi Andrew,
> 
> On 27/3/2020 9:01 pm, Andrew Lunn wrote:
> > On Fri, Mar 27, 2020 at 08:51:56PM +0100, Daniel Mack wrote:
> >> On hardware with a speed-reduced link to the CPU port, forcing the MAC
> >> settings won't allow any packets to pass. The PHY will negotiate the
> >> maximum possible speed, so let's allow the MAC to work with whatever
> >> is available.
> > 
> > This will break board which rely on the CPU being forced to the
> > maximum speed, which has been the default since forever.
> 
> Will it? Wouldn't the PHY negotiate the maximum speed, and the MAC would
> follow?

Most boards just connect the SoC MAC to the switch MAC. No PHY.

There is no need to have PHYs here, unless your switch is a long way
away from the SoC. It is just added extra expense for no reason.

> > It sounds like you have the unusual situation of back to back PHYs?
> > And i assume the SoC PHY is limited to Fast Ethernet?
> 
> Yes, exactly.

And i guess you are stuck with this design?

> > What i think you can do is have a phy-handle in the cpu node which
> > points to the PHY. That should then cause the PHY to be driven as a
> > normal PHY, and the result of auto neg passed to the MAC.
> 
> Yes, this is what I have. The maximum speed the is negotiable on that
> link is 100M, and the PHYs see each other just fine (according to the
> status registers of the external PHY). The problem is that the MAC
> inside the switch is forced to 1G, which doesn't match what the PHY
> negotiated.

So try a fixed link in the CPU node.

                                       port@6 {
                                                reg = <6>;
                                                label = "cpu";
                                                ethernet = <&fec1>;

                                                fixed-link {
                                                        speed = <100>;
                                                        full-duplex;
                                                };

This won't work with current net-next, which is broken at the
moment. But it might work with older kernels. I've not tried this when
there actually is a PHY. It is normally used when you need to slow the
port down from its default highest speed in the usual MAC-MAC
setting. In this case, the FEC is Fast Ethernet only, so we need the
Switch MAC to run at 100Mbps.

     Andrew