On Wed 2021-07-21 16:35:27, 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. > > If we could drop those, we can relax the naming requirements so that > the names is unique to a parent device, not globally unique. Well, I believe we already negotiated acceptable naming with Marek... Is it unsuitable for some reason? -- http://www.livejournal.com/~pavelmachek
Attachment:
signature.asc
Description: PGP signature
