netdev - Re: [PATCH net-next] net: enetc: Support ethernet aliases in dts.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250226171045.kf7dd2zprpcjrnj7@skbuf>
Date: Wed, 26 Feb 2025 19:10:45 +0200
From: Vladimir Oltean <vladimir.oltean@....com>
To: Shenwei Wang <shenwei.wang@....com>
Cc: Claudiu Manoil <claudiu.manoil@....com>, Wei Fang <wei.fang@....com>,
	Clark Wang <xiaoning.wang@....com>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	"imx@...ts.linux.dev" <imx@...ts.linux.dev>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	dl-linux-imx <linux-imx@....com>
Subject: Re: [PATCH net-next] net: enetc: Support ethernet aliases in dts.

On Wed, Feb 26, 2025 at 06:46:54PM +0200, Shenwei Wang wrote:
> > Shenwei, you don't want the kernel to attempt to be very smart about the initial
> > netdev naming. You will inevitably run into the situation where "eth%d" is already
> > the name chosen for the kernel for a different net_device without a predictable
> > name (e.g. e1000e PCIe card) which has been allocated already. Then you'll want
> 
> The driver just provides an option to configure predictable interface naming. IMO, all 
> those kind of naming conflicts should be managed by the DTS itself. 

Good luck adding of_alias_get_id() patches to (and others) PCIe NIC
drivers (with a real PCIe link layer, not Enhanced Allocation).

> > to fix that somehow, and the stream of patches will never stop, because the
> > kernel will never be able to fulfill all requirements. Look at the udev naming rules
> > for dpaa2 and enetc on Layerscape and build something like that. DSA switch
> 
> Even with the udev/systemd solution, you may still need to resolve the naming
> conflict sometimes among multiple cards.

Yet, the rootfs seems to be the only place to keep net device names that
is sufficiently flexible to cover the variability in use cases. Maybe
you're used to your developer position where you can immediately modify
the device tree for a board, but one is supposed to be able to configure
U-Boot to provide a fixed device tree (its own) to Linux. This is for
example used for Arm SystemReady IR compliance with distributions, to my
knowledge.