[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200213160612.GD31084@lunn.ch>
Date: Thu, 13 Feb 2020 17:06:12 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Russell King - ARM Linux admin <linux@...linux.org.uk>,
netdev <netdev@...r.kernel.org>,
Florian Fainelli <f.fainelli@...il.com>,
Sean Wang <sean.wang@...iatek.com>,
John Crispin <john@...ozen.org>,
Mark Lee <Mark-MC.Lee@...iatek.com>,
Giuseppe Cavallaro <peppe.cavallaro@...com>,
Alexandre Torgue <alexandre.torgue@...com>,
Jose Abreu <joabreu@...opsys.com>,
Radhey Shyam Pandey <radhey.shyam.pandey@...inx.com>,
Nicolas Ferre <nicolas.ferre@...rochip.com>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
Ioana Ciornei <ioana.ciornei@....com>
Subject: Re: Heads up: phylink changes for next merge window
> Correct me if I'm wrong, but if the lack of fixed-link specifier for
> CPU and DSA ports was not a problem before, but has suddenly started
> to become a problem with that patch, then simply reverting to the old
> "legacy" logic from dsa_port_link_register_of() should restore the
> behavior for those device tree blobs that don't specify an explicit
> fixed-link?
DSA defines that the DSA driver should initialize CPU ports and DSA
ports to their maximum speed. You only need fixed-link properties when
you need to slow the port down, e.g. the SoC on the other end is
slower. That does not happen very often, so most boards don't have
fixed-link properties.
It just happens that most of the boards i test with, have a Fast
Ethernet SoC port, so do have fixed-link properties, and i missed the
issue for a long time.
Andrew
Powered by blists - more mailing lists