On 27.07.2021 18:32, Marek Behún wrote: > Hi, > > On Tue, 27 Jul 2021 17:53:58 +0200 > Michael Walle <michael@xxxxxxxx> wrote: > >>> If we used the devicename as you are suggesting, then for the two LEDs >>> the devicename part would be the same: >>> ledA -> macA -> ethernet0 >>> ledB -> phyB -> ethernet0 >>> although they are clearly on different MACs. >> >> Why is that the case? Why can't both the MAC and the PHY request a >> unique name from the same namespace? > > So all the network related devices should request a unique network > relate device ID? Should also wireless PHY devices do this? WWAN modems? > And all these should have the same template for devicename part withing > /sys/class/leds? What should be the template for the devicename, if > wireless PHYs and WWAN modems could also be part of this? It cannot be > "ethernet" anymore. > > It seems a better idea to me to just some nice identifier for the LED > controller. > >> As Andrew pointed out, the names in >> /sys/class/leds don't really matter. Ok, it will still depend on the >> probe order which might not be the case if you split it between ethmac >> and ethphy. > > Yes, the LED name does not matter. But the LED subsystem requires names > in a specific format, this is already decided and documented, we are > not going to be changing this. The only reasonable thing we can do now > is to choose a sane devicename. > >> Sorry, if I may ask stupid questions here. I don't want to cause much >> trouble, here. I was just wondering why we have to make up two different >> (totally unrelated names to the network interface names) instead of just >> one (again totally unrelated to the interface name and index). > > It seems more logical to me from kernel's point of view. > >> But I was actually referring to your "you see the leds in /sys/ of all >> the network adapters". That problem still persists, right? > > Yes, this still persists. But we really do not want to start > introducing namespaces to the LED subsystem. > > Marek > Did we come to any conclusion? My preliminary r8169 implementation now creates the following LED names: lrwxrwxrwx 1 root root 0 Jul 26 22:50 r8169-led0-0300 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/r8169-led0-0300 lrwxrwxrwx 1 root root 0 Jul 26 22:50 r8169-led1-0300 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/r8169-led1-0300 lrwxrwxrwx 1 root root 0 Jul 26 22:50 r8169-led2-0300 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/r8169-led2-0300 I understood that LEDs should at least be renamed to r8169-0300::link-0 to link-2 Is this correct? Or do we have to wait with any network LED support for a name discussion outcome? For the different LED modes I defined private hw triggers (using trigger_type to make the triggers usable with r8169 LEDs only). The trigger attribute now looks like this: [none] link_10_100 link_1000 link_10_100_1000 link_ACT link_10_100_ACT link_1000_ACT link_10_100_1000_ACT Nice, or? Issue is just that these trigger names really should be made a standard for all network LEDs. I don't care about the exact naming, important is just that trigger names are the same, no matter whether it's about a r8169- or igc- or whatever network chip controlled LEDs. And I don't have a good solution for initialization yet. LED mode is whatever BIOS sets, but initial trigger value is "none". I would have to read the initial LED control register values, iterate over the triggers to find the matching one, and call led_trigger_set() to properly set this trigger as current trigger. Most likely this would need some LED core extensions: - enable iterating over all triggers with a particular trigger_type - enable triggers to have private data Quite some hassle for a small functionality.
