Hi!
A nice godfather is required here...
Just use sys:: :-).
laptop:: would work for me, too. (It is always laptop in the cases we are handling now, right?)
When we get a keyboard with mute led, we'll have to decide if it should be input6::mute -- because it is on keyboard, or if it is sys::mute -- because the key is expected to mute whole system.
drivers/input/input-leds.c seems to already support mute LED. It will be exposed as inputN::mute.
Documentation/leds/leds-class.txt defines LED naming pattern to devicename:color:function and "sys" does not look as something resembling device name.
So what is your suggestion?
I guess we should follow documentation. Or update documentation if it does not make sense to follow it.
That's actually in progress. Let me and Jacek deal with it. We don't need great "how to name a LED" discussion here (google: bike shed paiting).
I don't care much as long as it is same in tpacpi and dell case. (Neither are device names, btw :-).
Actually "::mute" would make sense, too.
"::mute" is not a good idea due to name uniqueness.
In case you would have two drivers which both provides "mute" led, then they need to have different name. Reason also why generic name "sys" is not a good idea.
I think that driver name or subsystem name would be usable together with number.
Userspace application would be probably interested to distinguish between "mute led which is part of laptop" and "mute led which is available on external USB keyboard".
If external USB keyboard is identified as "input7" device, then "input7::mute" is a good name for mute key. But "sys::mute" does not say anything to which device or hardware it belongs nor does not solve problem that which device/driver/subsystem should have privilege to take this "sys" name.
Well, "sys" says this is system-wide mute LED. There are not expected to be two of those, and there never will be, with the drivers currently proposed.
Pavel