On 21.07.2021 16:35, Andrew Lunn wrote:
>> Thanks for the hint, Andrew. If I make &netdev->dev the parent,
>> then I get:
>>
>> ll /sys/class/leds/
>> total 0
>> lrwxrwxrwx 1 root root 0 Jul 20 21:37 led0 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/led0
>> lrwxrwxrwx 1 root root 0 Jul 20 21:37 led1 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/led1
>> lrwxrwxrwx 1 root root 0 Jul 20 21:37 led2 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/led2
>>
>> Now the (linked) LED devices are under /sys/class/net/<ifname>, but still
>> the primary LED devices are under /sys/class/leds and their names have
>> to be unique therefore. The LED subsystem takes care of unique names,
>> but in case of a second network interface the LED device name suddenly
>> would be led0_1 (IIRC). So the names wouldn't be predictable, and I think
>> that's not what we want.
>
> We need input from the LED maintainers, but do we actually need the
> symbolic links in /sys/class/leds/? For this specific use case, not
> generally. Allow an LED to opt out of the /sys/class/leds symlink.
>
The links are created here:
led_classdev_register_ext()
-> device_create_with_groups()
-> device_add()
-> device_add_class_symlinks()
So it seems we'd need an extension to the device core to support
class link opt-out.
> If we could drop those, we can relax the naming requirements so that
> the names is unique to a parent device, not globally unique.
>
> Andrew
>
Heiner
