Re: [PATCH 2.6.8.1 0/2] leds: new class for led devices

[John Lenz <lenz@cs.wisc.edu>]

On 09/03/04 08:51:03, Pavel Machek wrote:
> > function : a read/write attribute that sets the current function of
> > this led.  The available options are
> >
> >  timer : the led blinks on and off on a timer
> >  idle : the led turns off when the system is idle and on when not idle
> >  power : the led represents the current power state
> >  user : the led is controlled by user space
> 
> I'm afraid this is really good idea. It seems quite overengineered to
> me (and I'd be afraid that idle part slows machine). Perhaps having
> only "user" mode is better idea?

I was only mimicing the support currently in the arm led code.
After thinking about it from a broader perspective of including GPIOs,
we should probably get rid of this function thing entirely.  Just let user  
space do everything... userspace can monitor sysfs and hotplug and have the  
led represent power or idle or whatever.

> 
> > light : a read/write attribute that allows userspace to see the current
> 
> > status of the led.  If function="user" then writing to this attribute
> > will change the led on or off.  If function != "user" then writing has
> > no effect.
> >  light is an integer, where 0 means off, 1 means on first color, 2
> > means on second color, etc.  (for example, if color="green/blue" then
> > light=1 means turn led on to green and if light=2 means turn led on to
> > blue.
> 
> Is there ways to turn on both?

depends on the hardware...

The led class does not really inforce any policy, it just passes this
number along to the actual driver that is registered.  So say you had
a led that could be red, green, or both red and green at the same time
(not sure how that would work hardware wise, but ok).  The driver could
do something like set color="red/green/red&green" and then use 0,1,2,3.
The kernel is just reflecting the possible states the hardware could be
in.

John