netdev - Re: [PATCH net-next 5/5] igc: Export LEDs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <88d23db8-d2d2-5816-6ba1-3bd80738c398@gmail.com>
Date:   Tue, 20 Jul 2021 17:00:06 +0200
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Andrew Lunn <andrew@...n.ch>, Pavel Machek <pavel@....cz>
Cc:     Tony Nguyen <anthony.l.nguyen@...el.com>, davem@...emloft.net,
        kuba@...nel.org, Kurt Kanzenbach <kurt@...utronix.de>,
        netdev@...r.kernel.org, sasha.neftin@...el.com,
        vitaly.lifshits@...el.com, vinicius.gomes@...el.com,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Dvora Fuxbrumer <dvorax.fuxbrumer@...ux.intel.com>,
        "linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>
Subject: Re: [PATCH net-next 5/5] igc: Export LEDs

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