Hi!

> > >>> In fact the function should not be "wlan" (nor "wlan2g" or "wlan5g", but
> > >>> "activity".  
> > 
> > I disagree. Activity should be reserved for the activity trigger.
> > I've had a patch [0] documenting standard LED functions, but it
> > eventually didn't make to the mainline, I'll try to send an update.
> 
> Hmm. The thing is that activity is sometimes interpreted as the union
> of rx and tx, or read and write. I think the pair (device,function)
> could be used better to infer the actual trigger and its settings, than
> just (function,). For example:
> 	device	function		trigger
> 	system	activity		cpu activity
> 	(empty)	activity		cpu activity
> 	eth0	activity		netdev rx/tx
> 	sda	activity		disk read/write on sda
> 	wlan0	activity		phy rx/tx

I believe that makes sense.

> (This is another thing that is wrong: there should be only phy, or
> wireless-phy trigger, and the mode (rx/tx/assoc/radio) and device
> (phy0, phy1, ...) should be set via device_name file, as in netdev
> trigger. Can we reimplement it and leave this ABI under configuration
> option _LEAGACY?).
> 
> > IMO if LED is not physically integrated with any device, then it should
> > not be named after the device that is to be initially associated with
> > via trigger. This association can be later changed in userspace, which
> > will render the name invalid. And current associated device can be read
> > by reading triggers sysfs file, provided that the trigger conveys
> > that information like in case of presented above phy* triggers.
> 
> There are devices which have LEDs connected via a LED controller for
> example via I2C bus, but the individual LEDs are dedicated (in the way
> that there is an icon or text written on the device's case next to each
> LED). In this case the trigger-source should be defined in device tree
> in such a way that it aligns with the manufacturer's intended function
> of the LED. And in this case I think the devicename part of the LED
> should be derived from this trigger source.

I agree here.

In ideal world, we would have same interface for

1) capslock LED is integrated on USB keyboard

2) casplock LED on i2c and keyboard on GPIO lines

We are not there, yet, but I believe it makes sense as a goal.

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html