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.

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.

Signed-off-by: Kyle Hsieh <kylehsieh1995@gmail.com>
---
Hi all,

This patch series introduces deterministic interface naming for the 
ftgmac100 driver by utilizing device tree aliases.

Background:
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). 

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.

Solution:
By parsing the "ethernet" alias from the device tree during probe, the 
driver can now assign the correct name out-of-the-box, completely 
bypassing the userspace race condition.

Testing:
- Tested on ASPEED AST2600 BMC.
- Verified that device tree aliases (ethernet0 = &mac3, ethernet1 = &mac2) 
  are correctly applied at probe time.

Please review and consider for inclusion.

Thanks,
Kyle Hsieh
---
 drivers/net/ethernet/faraday/ftgmac100.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/ethernet/faraday/ftgmac100.c b/drivers/net/ethernet/faraday/ftgmac100.c
index 6d2fe5c2f390..e058a10500ee 100644
--- a/drivers/net/ethernet/faraday/ftgmac100.c
+++ b/drivers/net/ethernet/faraday/ftgmac100.c
@@ -1949,6 +1949,7 @@ static int ftgmac100_probe(struct platform_device *pdev)
 	struct ftgmac100 *priv;
 	struct device_node *np;
 	int err = 0;
+	int alias_id;
 
 	np = pdev->dev.of_node;
 	if (np) {
@@ -1973,6 +1974,11 @@ static int ftgmac100_probe(struct platform_device *pdev)
 	if (!netdev)
 		return -ENOMEM;
 
+	/* Assign interface name based on DTS alias (e.g., ethernet0 -> eth0) */
+	alias_id = of_alias_get_id(pdev->dev.of_node, "ethernet");
+	if (alias_id >= 0)
+		snprintf(netdev->name, IFNAMSIZ, "eth%d", alias_id);
+
 	SET_NETDEV_DEV(netdev, &pdev->dev);
 
 	netdev->ethtool_ops = &ftgmac100_ethtool_ops;

---
base-commit: eb3f4b7426cfd2b79d65b7d37155480b32259a11
change-id: 20260527-addethalias-d25e2f188697

Best regards,
-- 
Kyle Hsieh <kylehsieh1995@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