[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d101df30-5a9e-eac1-94b0-f171dbcd5b88@zonque.org>
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