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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 27 Mar 2020 22:26:53 +0100
From:   Daniel Mack <daniel@...que.org>
To:     Andrew Lunn <andrew@...n.ch>
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 27/3/2020 10:18 pm, Andrew Lunn wrote:
> On Fri, Mar 27, 2020 at 09:48:56PM +0100, Daniel Mack wrote:
>> 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.

Yes, I know. In our design all RGMII ports are in use already, so we had
to go for a transformer-less link on a regular copper port, and connect
a phy on the other side.

> And i guess you are stuck with this design?

Yes.

>> 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 tried this as well with v5.5, but that leads to the external phy not
seeing a link at all. Will check again though.

Could you think of a way to make this behavior conditional? Could we
introduce a DT property or something?

Worst case is to keep that one-liner as a downstream patch, but I could
well imagine other people facing the same issue.


Thanks,
Daniel