[PATCH] ARM: dts: armada388-clearfog: number LAN ports properly

Russell King - ARM Linux linux at armlinux.org.uk
Wed Jul 27 03:42:06 PDT 2016


On Wed, Jul 27, 2016 at 12:26:41PM +0200, Gregory CLEMENT wrote:
> Hi Russell King,
>  
>  On mer., juil. 27 2016, Russell King - ARM Linux <linux at armlinux.org.uk> wrote:
> 
> > On Wed, Jul 27, 2016 at 12:19:01PM +0200, Gregory CLEMENT wrote:
> >> Hi,
> >>  
> >>  On ven., juil. 08 2016, Andrew Lunn <andrew at lunn.ch> wrote:
> >> 
> >> > On Fri, Jul 08, 2016 at 02:58:39PM +0100, Russell King wrote:
> >> >> Currently, the ports as seen from the rear number as:
> >> >> 
> >> >> 	eth0 sfp lan5 lan4 lan3 lan2 lan1 lan6
> >> >> 
> >> >> which is illogical - this came about because the rev 2.0 boards have the
> >> >> LEDs on the front for the DSA switch (lan5-1) reversed.  Rev 2.1 boards
> >> >> fixed the LED issue, and the Clearfog case numbers the lan ports
> >> >> increasing from left to right.
> >> >> 
> >> >> Maintaining this illogical numbering causes confusion, with reports that
> >> >> "my link isn't coming up" and "my connection negotiates 10base-Half"
> >> >> both of which are due to people thinking that the port next to the SFP
> >> >> is lan1.
> >> >> 
> >> >> Fix this by renumbering the ports to match people's expectations.
> >> >> 
> >> >> Signed-off-by: Russell King <rmk+kernel at armlinux.org.uk>
> >> >
> >> > Reviewed-by: Andrew Lunn <andrew at lunn.ch>
> >> 
> >> I missed this patch, but I now applied it on mvebu/dt-4.9
> >
> > It would be much better to get it into 4.8-rc so that we don't spread
> > the port renumbering over a large range of kernels, as well as forcing
> > vendors to carry patches like this to fix problems.
> 
> I can move it to the mvebu/fixes branch, it is not too late. Also what
> about to apply it on the stable kernel?

That'd probably be best.

As far as stable goes, I can't convince myself that it is really stable
kernel material.  I'm not aware what happened to the eth* renumber patch,
was that applied to stable trees?  My view would be that the lan*
renumbering should be applied to the same trees which include the eth*
renumbering and no further, iff the eth* renumber was even backported.

Talking to Jon Nettleton @ SR, he's in favour of it being applied to
stable kernels.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.



More information about the linux-arm-kernel mailing list