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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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@xxxxxxxxxxxxxxx> wrote:
> 
> > On Wed, Jul 27, 2016 at 12:19:01PM +0200, Gregory CLEMENT wrote:
> >> Hi,
> >>  
> >>  On ven., juil. 08 2016, Andrew Lunn <andrew@xxxxxxx> 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@xxxxxxxxxxxxxxx>
> >> >
> >> > Reviewed-by: Andrew Lunn <andrew@xxxxxxx>
> >> 
> >> 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.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux