LED devices

[Richard Purdie]

On Fri, 2007-06-01 at 16:20 +0200, Johannes Berg wrote:
> What I'd also like to see is have an LED be associated with some other
> device, as a parent. So instead of being pure "class devs" they could
> live in say /sys/devices/pci0002:24/0002:24:0f.0/led/ like we now
> have /sys/devices/pci0002:24/0002:24:0f.0/net/.

For reference, a conversation away from the class device structure is
planned so this will happen (or at least something similar).

> And then there's one more thing, I'd like to have triggers associated
> with devices as well, but those are currently not entities in sysfs at
> all, unfortunately.
> 
> The reason I'm saying this is that we'd love to export things like
> "ieee80211:phy1:rx" as an LED trigger for the RX led on wireless phy1,
> and have hardware drivers also export LEDs when say the PCMCIA card you
> inserted has an LED. Then if both were sysfs entities userspace could
> easily detect this and hook up the right LED to the right trigger by
> default. Or, the kernel could, but right now you need to specify a name
> for the trigger, in my example above I'd like to actually specify
> "ieee80211:%s:rx" as the trigger name and have that %s filled in with
> the parent device name.

Its probably quite feasible now without too many changes. There is
already the notion of a "default_trigger", all you'd need is to add some
kind of optional function pointer to a 'trigger_matches' function and
find a way to deal with any conflicts which replaced/complimented that.

Triggers are fundamentally a kernel entity and the matching should
probably happen in the kernel at least by default although its obviously
totally configurable in userspace too through the existing sysfs
entries.

For contrast, another possibility is we expose the default_trigger
string, e.g. "ieee80211:%s:rx" and then have userspace set the trigger
accordingly but that somehow seems more clunky, especially when the
kernel can handle things itself at the moment with next to no code.

Regards,

Richard