mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Kyle Hsieh <kylehsieh1995@gmail.com>
Cc: Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next] net: ftgmac100: assign interface name from device tree alias
Date: Wed, 27 May 2026 18:56:13 +0200	[thread overview]
Message-ID: <bcb13356-9ae1-40e7-914f-7a65e31ca9ba@lunn.ch> (raw)
In-Reply-To: <20260527-addethalias-v1-1-24f5bd2d03cd@gmail.com>

On Wed, May 27, 2026 at 02:31:51PM +0800, Kyle Hsieh wrote:
> Currently, the ftgmac100 driver relies on the probe order to assign network
> interface names (e.g., eth0, eth1).
> 
> This patch allows the driver to fetch the "ethernet" alias ID from the
> device tree via of_alias_get_id() and assign it to netdev->name before
> registering the netdev.

Such functionally has generally been NACKed in the past.

> 
> This provides a standard and robust way to achieve deterministic interface
> naming (e.g., ethernet0 -> eth0) directly from the device tree, preventing
> potential userspace race conditions during network setup.

You need to explain the race conditions here, in the main part of the
commit message. And you need to include how you tried to solve the
race conditions, failed, and decided on this workaround, rather than
fix the real problem.

> Currently, ftgmac100 assigns interface names strictly based on probe order. 
> On platforms like the ASPEED AST2600, this often leads to naming collisions 
> (e.g., mac2 and mac3 defaulting to eth0 and eth1). 

That is intended behaviour. They have always been
non-deterministic. Which is why systemd renames them.

> While userspace tools like systemd-udevd are typically responsible for 
> renaming, we encounter a severe race condition on BMC systems: the NCSI 
> driver frequently brings the management interface UP before udev can rename 
> it, resulting in the kernel locking the name and rejecting the rename 
> request.

So i would say this is actually an NCSI issue. And it is not
specifically a ftgmac100 issue, it will apply to other BMC SoCs, there
appear to be some RISC-V devices in the pipeline, etc.

What exactly is blocking the rename? 

# ip link show eth16
10: eth16: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:26:55:d2:32:56 brd ff:ff:ff:ff:ff:ff
    altname enx002655d23256
    altname enp10s0f1

# ip link set name eth42 dev eth16

# ip link show eth42
10: eth42: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:26:55:d2:32:56 brd ff:ff:ff:ff:ff:ff
    altname enx002655d23256
    altname enp10s0f1

So it should not be the fact the interface is up.

   Andrew

      reply	other threads:[~2026-05-27 16:56 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-27  6:31 Kyle Hsieh
2026-05-27 16:56 ` Andrew Lunn [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bcb13356-9ae1-40e7-914f-7a65e31ca9ba@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=kylehsieh1995@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®