On 19.07.2021 02:40, Andrew Lunn wrote: >> In general I'm not sure using the LED API provides a benefit here. >> The brightness attribute is simply misused. Maybe better add >> a sysfs attribute like led_mode under the netdev sysfs entry? > > I _think_ you can put LED sys files other places than > /sys/class/led. It should be possible to put them into netdev sysfs > directory. However you need to consider what affect network name > spaces have on this and what happens when an interface changes > namespace. > I checked the LED subsystem and didn't find a way to place the LED sysfs files in a place other than /sys/class/leds. Maybe Pavel can comment on whether I just missed something. To avoid the network namespace issues we could use the PCI device name in the LED name, but this would be quite unfriendly to the user. For r8169 I'm facing a similar challenge like Kurt. Most family members support three LED's: - Per LED a mode 0 .. 15 can be set that defines which link speed(s) and/or activity is indicated. - Period and duty cycle for blinking can be controlled, but this setting applies to all three LED's. For testing purposes I created sysfs attributes led0, led1, led2, period, duty and assigned the attribute group to netdev->sysfs_groups[0]. This works fine and all attributes are under /sys/class/net/<ifname>. Only drawback is that you need to know which trigger mode is set by values 0..15. However this can be documented in sysfs attribute documentation under Documentation/ABI/testing. For using the LED subsystem and triggers two things would have to be solved: - How to deal with network device name changes so that the user still can identify that a LED belongs to a certain network device. - How to properly deal with attributes that are shared by a group of LED's? > Andrew > . > Heiner
