From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753260AbcHXUBM (ORCPT ); Wed, 24 Aug 2016 16:01:12 -0400 Received: from down.free-electrons.com ([37.187.137.238]:48733 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751011AbcHXUAX (ORCPT ); Wed, 24 Aug 2016 16:00:23 -0400 Date: Wed, 24 Aug 2016 21:52:00 +0200 From: Thomas Petazzoni To: lsorense@csclub.uwaterloo.ca (Lennart Sorensen) Cc: Ralph Sennhauser , "linux-kernel@vger.kernel.org" , Gregory CLEMENT Subject: Re: [Regression?] Commit cb4f71c429 deliberately changes order of network interfaces Message-ID: <20160824215200.22de30d1@free-electrons.com> In-Reply-To: <20160824182758.GF14311@csclub.uwaterloo.ca> References: <20160821151158.78da01e6@gmail.com> <20160824165011.6c811913@free-electrons.com> <20160824191004.3b4ff2cb@gmail.com> <20160824180727.GE14311@csclub.uwaterloo.ca> <20160824201444.487022de@free-electrons.com> <20160824182758.GF14311@csclub.uwaterloo.ca> Organization: Free Electrons X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Wed, 24 Aug 2016 14:27:58 -0400, Lennart Sorensen wrote: > On Wed, Aug 24, 2016 at 08:14:44PM +0200, Thomas Petazzoni wrote: > > Depends on the network driver I believe. But with an e1000e NIC plugged > > in a PCIe slot, it indeed gets assigned as eth0, and the internal > > mvneta devices get eth1, eth2, etc. > > Which of course means the change does not actually ensure the port > ordering matches the marvell documentation or u-boot. It only handles > the relative order of the ports. For now. Correct. > So since it doesn't actually work, maybe reverting it so it no longer > violates the dtb ordeting rule makes sense. I'll let the platform maintainers decide what's the least intrusive/problematic option. Both solutions have drawbacks, so it's really a "political" decision to make here. > Doesn't mean openwrt/lede/etc don't have to deal with the ordering in > the future if async probing takes off. Not only async probing, but also PCIe devices, as you mentioned earlier :-) Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com