Date: Fri, 03 Sep 2004 23:19:46 +0000
From: John Lenz <lenz@cs.wisc.edu>
Subject: Re: [PATCH 2.6.8.1 0/2] leds: new class for led devices
In-reply-to: <20040903232507.A8810@flint.arm.linux.org.uk>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: John Lenz <lenz@cs.wisc.edu>, Jan-Benedict Glaw <jbglaw@lug-owl.de>,
       linux-kernel@vger.kernel.org, Kalin KOZHUHAROV <kalin@thinrope.net>
Message-id: <1094253586l.7429l.4l@hydra>
MIME-version: 1.0
Content-type: text/plain; Format=Flowed; DelSp=Yes; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <1094157190l.4235l.2l@hydra> <ch8tdd$1uf$1@sea.gmane.org>
 <20040903120634.GK6985@lug-owl.de> <1094237243l.7429l.1l@hydra>
 <20040903232507.A8810@flint.arm.linux.org.uk>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2942
Lines: 69

On 09/03/04 17:25:07, Russell King wrote:
> On Fri, Sep 03, 2004 at 06:47:23PM +0000, John Lenz wrote:
> > On 09/03/04 07:06:34, Jan-Benedict Glaw wrote:
> > > Is idle/timer/power hardware-controlled (eg. by a secondary  
> processor,
> > > direct chipset implementation) or is switching on/off controlled by
> > > kernel (eg. heartbeat, IO and ethernet for the LEDs you can find on
> some
> > > PA-RISC machines)?
> >
> > Right now the kernel is in sole control.  The device I am testing this
> on
> > is a Sharp Zaurus SL5500, which has two leds that by default are used  
> to
> 
> > light when new mail arrives and if the power is plugged in.
> 
> The kernel is NOT in sole control today on ARM platforms:
> 
> echo claim > /sys/devices/system/leds/leds0/event
> echo red on > /sys/devices/system/leds/leds0/event
> echo green on > /sys/devices/system/leds/leds0/event
> echo red off > /sys/devices/system/leds/leds0/event
> echo release > /sys/devices/system/leds/leds0/event
> 
> etc
> 
> Sure, we have a weird naming scheme (red, green, amber, blue) but
> that came around because that's what people were dealing with.
> There's nothing really stopping us from having any name for a LED
> in the existing scheme.

1) This is arm specific.  Do any other arches want to provide access to  
leds?  Why should they implement some different api?

2) What happens when you have more than four leds?  or 3 dual color leds?

3) no way to read the current status of the led. (could be added to read  
from /sys/devices/system/leds/leds0 or something)

4) really wierd in-kernel api...  The led is associated with a machine,  
when that sometimes doesn't make sense; code duplication for the same  
harware drivers.  As an example, the led device on the Sharp Zauruses are  
all the same... exact same code to control the led.  Except one model is  
sa1100 and two are pxa based, so leds-collie.c and leds-poodle.c are  
exactly the same, except to be registered in the associated leds.c for that  
mach.  This model, instead of associating leds with a specific machine make  
it a device/driver concept like every other device in the kernel.

We can easily provide backwards compatibility with the arm led code.  I  
have a semi-working driver to register with ledsbase.c and call the  
leds_event function.  As well, the old /sys/devices/system/leds/leds0/event  
thing can also be emulated.

> I just don't buy the "we must have one sysfs node for every LED"
> argument.

well, we could just create one attribute per led in /sys/devices/system/ 
leds/leds0/, but that breaks conceptally what sysfs is trying to provide...  
one device per attribute?  4 devices controlled by ONE attribute?

John


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/