From: Russell King <rmk+lkml@arm.linux.org.uk>
To: John Lenz <lenz@cs.wisc.edu>
Cc: Jan-Benedict Glaw <jbglaw@lug-owl.de>,
linux-kernel@vger.kernel.org,
Kalin KOZHUHAROV <kalin@thinrope.net>
Subject: Re: [PATCH 2.6.8.1 0/2] leds: new class for led devices
Date: Fri, 3 Sep 2004 23:25:07 +0100 [thread overview]
Message-ID: <20040903232507.A8810@flint.arm.linux.org.uk> (raw)
In-Reply-To: <1094237243l.7429l.1l@hydra>; from lenz@cs.wisc.edu on Fri, Sep 03, 2004 at 06:47:23PM +0000
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.
I just don't buy the "we must have one sysfs node for every LED"
argument.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
next prev parent reply other threads:[~2004-09-03 22:25 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-02 20:33 [PATCH 2.6.8.1 0/2] leds: new class for led devices John Lenz
2004-09-02 20:34 ` [PATCH 2.6.8.1 1/2] " John Lenz
2004-09-02 20:38 ` [PATCH 2.6.8.1 2/2] " John Lenz
2004-09-03 4:54 ` [PATCH 2.6.8.1 0/2] " Kalin KOZHUHAROV
2004-09-03 11:32 ` Geert Uytterhoeven
2004-09-03 12:06 ` Jan-Benedict Glaw
2004-09-03 18:47 ` John Lenz
2004-09-03 22:25 ` Russell King [this message]
2004-09-03 23:19 ` John Lenz
2004-09-04 11:12 ` Pavel Machek
2004-09-04 20:53 ` Russell King
2004-09-04 21:41 ` Pavel Machek
2004-09-06 7:36 ` John Lenz
2004-09-03 13:17 ` Robert Schwebel
2004-09-03 13:31 ` Robert Schwebel
2004-09-03 8:00 ` Oliver Neukum
2004-09-03 13:51 ` Pavel Machek
2004-09-03 18:38 ` John Lenz
2004-09-03 18:55 ` Russell King
2004-09-03 19:09 ` John Lenz
2004-09-03 19:51 ` Russell King
2004-09-03 20:35 ` John Lenz
2004-09-04 11:09 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040903232507.A8810@flint.arm.linux.org.uk \
--to=rmk+lkml@arm.linux.org.uk \
--cc=jbglaw@lug-owl.de \
--cc=kalin@thinrope.net \
--cc=lenz@cs.wisc.edu \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.