[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b4ba27e5-a1cc-4477-a254-a318e586ef2a@mailbox.org>
Date: Mon, 17 Nov 2025 12:18:31 +0100
From: Marek Vasut <marek.vasut@...lbox.org>
To: Andrew Lunn <andrew@...n.ch>
Cc: linux-leds@...r.kernel.org,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Christian Marangi <ansuelsmth@...il.com>,
Christophe Roullier <christophe.roullier@...s.st.com>,
Daniel Golle <daniel@...rotopia.org>, Heiner Kallweit
<hkallweit1@...il.com>, Lee Jones <lee@...nel.org>,
Pavel Machek <pavel@....cz>, kernel@...electronics.com,
linux-stm32@...md-mailman.stormreply.com, netdev@...r.kernel.org
Subject: Re: [PATCH] leds: trigger: netdev: Check offload ability on interface
up
On 10/3/24 2:47 AM, Marek Vasut wrote:
Hello again,
>>> On STM32MP13xx with RTL8211F, it is enough to have the following udev
>>> rule
>>> in place, boot the machine with cable plugged in, and the LEDs won't
>>> work
>>> without this patch once the interface is brought up, even if they
>>> should:
>>> "
>>> ACTION=="add", SUBSYSTEM=="leds", KERNEL=="stmmac-0:01:green:wan",
>>> ATTR{trigger}="netdev", ATTR{link_10}="1", ATTR{link_100}="1",
>>> ATTR{link_1000}="1", ATTR{device_name}="end0"
>>> ACTION=="add", SUBSYSTEM=="leds", KERNEL=="stmmac-0:01:yellow:wan",
>>> ATTR{trigger}="netdev", ATTR{rx}="1", ATTR{tx}="1", ATTR{device_name}
>>> ="end0"
>>> "
>>
>> Nice use of udev. I had not thought about using it for this.
I might have been a bit too hasty with this. The following is only a
quick preliminary FYI, I am still investigating the details.
I observe on 6.18-rc6 (ST STM32MP13xx , so STM32 DWMAC ethernet, and
RTL8211F PHY), that if I use the these udev rules (SoC has two MACs,
there are two rules for each MAC, and 2 rules for each of two LEDs on
each MAC PHY , therefore four rules in total ; the rules for both MACs
are identical):
"
ACTION=="add|change", SUBSYSTEM=="leds",
KERNEL=="stmmac-0:01:green:wan", ATTR{trigger}="netdev",
ATTR{link_10}="1", ATTR{link_100}="1", ATTR{link_1000}="1",
ATTR{device_name}="ethsom0"
ACTION=="add|change", SUBSYSTEM=="leds",
KERNEL=="stmmac-0:01:yellow:wan", ATTR{trigger}="netdev", ATTR{rx}="1",
ATTR{tx}="1", ATTR{device_name}="ethsom0"
ACTION=="add|change", SUBSYSTEM=="leds",
KERNEL=="stmmac-1:01:green:lan", ATTR{trigger}="netdev",
ATTR{link_10}="1", ATTR{link_100}="1", ATTR{link_1000}="1",
ATTR{device_name}="ethsom1"
ACTION=="add|change", SUBSYSTEM=="leds",
KERNEL=="stmmac-1:01:yellow:lan", ATTR{trigger}="netdev", ATTR{rx}="1",
ATTR{tx}="1", ATTR{device_name}="ethsom1"
"
I get this backtrace. Notice the "sysfs: cannot create duplicate
filename ..." part , I suspect there is some subtle race condition ?
"
sysfs: cannot create duplicate filename
'/devices/platform/soc/5c007000.bus/5800e000.ethernet/mdio_bus/stmmac-1/stmmac-1:01/leds/stmmac-1:01:green:lan/link_10'
CPU: 0 UID: 0 PID: 153 Comm: (udev-worker) Not tainted 6.18.0-rc6 #1
PREEMPT
Hardware name: STM32 (Device Tree Support)
Call trace:
unwind_backtrace from show_stack+0x18/0x1c
show_stack from dump_stack_lvl+0x54/0x68
dump_stack_lvl from sysfs_warn_dup+0x58/0x6c
sysfs_warn_dup from sysfs_add_file_mode_ns+0xf0/0x130
sysfs_add_file_mode_ns from internal_create_group+0x344/0x480
internal_create_group from internal_create_groups+0x48/0x6c
internal_create_groups from led_trigger_set+0x1e4/0x278
led_trigger_set from led_trigger_write+0xe0/0x118
led_trigger_write from sysfs_kf_bin_write+0x98/0xa0
sysfs_kf_bin_write from kernfs_fop_write_iter+0x14c/0x198
kernfs_fop_write_iter from vfs_write+0x170/0x1d4
vfs_write from ksys_write+0x7c/0xd0
ksys_write from ret_fast_syscall+0x0/0x54
Exception stack(0xedbf1fa8 to 0xedbf1ff0)
1fa0: 00000006 bec4476c 00000015 bec4476c 00000006
00000001
1fc0: 00000006 bec4476c 000e7698 00000004 00000006 fffffff7 00000000
000d1710
1fe0: 00000004 bec44578 b6c34397 b6bb15e6
leds stmmac-1:01:green:lan: Failed to add trigger attributes
"
If I find out more, I will get back to this thread.
Powered by blists - more mailing lists