From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 506B7C3F6B0 for ; Wed, 10 Aug 2022 15:18:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233041AbiHJPSQ (ORCPT ); Wed, 10 Aug 2022 11:18:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32898 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233044AbiHJPSP (ORCPT ); Wed, 10 Aug 2022 11:18:15 -0400 Received: from vps0.lunn.ch (vps0.lunn.ch [185.16.172.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BAD577822A; Wed, 10 Aug 2022 08:18:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=vU64N8DAFoU6IdwvHRJh/4vbxbob+2V1zkE7ziRWxUw=; b=2PMpDtz5ERp83GMxo38pVEkg+B M7WEl+BcdKtJLSfmynMY+g+4CGa/lt0APxc/UnPF/UAOBokPmVNbdkoPhWwZYtopSqUiBeHpzbTn9 JQOn1zxMX5d0mTi1UwmPDA9I6nPJNYjx7dWcaDeLI0qR7SF8JmBDtEDj4mVTYUAQN+FQ=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1oLnT2-00CwWr-9i; Wed, 10 Aug 2022 17:17:56 +0200 Date: Wed, 10 Aug 2022 17:17:56 +0200 From: Andrew Lunn To: Michal =?iso-8859-1?Q?Such=E1nek?= Cc: Tim Harvey , Pali =?iso-8859-1?Q?Roh=E1r?= , Sean Anderson , Stephen Hemminger , netdev , u-boot , Device Tree Mailing List Subject: Re: ethernet dt aliases implications in U-Boot and Linux Message-ID: References: <20220808214522.GQ17705@kitsune.suse.cz> <53f91ad4-a0d1-e223-a173-d2f59524e286@seco.com> <20220809213146.m6a3kfex673pjtgq@pali> <20220809214207.bd4o7yzloi4npzf7@pali> <2083d6d6-eecf-d651-6f4f-87769cd3d60d@seco.com> <20220809224535.ymzzt6a4v756liwj@pali> <20220810071603.GR17705@kitsune.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220810071603.GR17705@kitsune.suse.cz> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > > I guess you are new to the netdev list :-) > > > > This is one of those FAQ sort of things, discussed every > > year. Anything like this is always NACKed. I don't see why this time > > should be any different. > > > > DSA is somewhat special because it is very old. It comes from before > > the times of DT. Its DT binding was proposed relatively earl in DT > > times, and would be rejected in modern days. But the rules of ABI mean > > the label property will be valid forever. But i very much doubt it > > will spread to interfaces in general. > > And if this is a FAQ maybe you can point to a summary (perhaps in > previous mail discusssion) that explains how to provide stable interface > names for Ethernet devices on a DT based platform? As far so the kernel is concerned, interface names are unstable. They have never been truly stable, but they have got more unstable in the past decade with multiple busses being probed in parallel, which did not happen before so much. > On x86 there is a name derived from the device location in the bus > topology This is nothing to do with x86. That is userspace, e.g. systemd, renaming the interfaces. This applies for any architecture for which systemd runs on. > which may be somewhat stable but it is not clear that it > cannot change, and there is an optional BIOS provided table that can > asssign meaningful names to the interfaces. I doubt the kernel is looking at ACPI tables. It is user space which does that. The kernel provides udev with a bunch of information about the interface, its bus location, MAC address, etc. Userspace can then decide what it wants to call it, and what its alternative names are, etc. Also, this is not just a network interface name problem. Any device with a number/letter in it is unstable. I2C bus devices: i2c0, i2c1... SPI bus deviceS: spi0, spi1..., Block devices, sda, sdb, sdc, TPM device, tpm0, tpm1. Nothing is stable in the kernel. Andrew