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 21:48:56 +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

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?

> 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.

> 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.

Not sure what else can be done to make such setups work instead of
lifting that particular constraint on the MAC side. Could you explain
why the settings are forced at all?


Thanks,
Daniel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ