From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 00/18] Introduce a led trigger for CPU activity and consolidate LED driver in ARM
Date: Mon, 29 Aug 2011 16:13:33 +0100 [thread overview]
Message-ID: <20110829151333.GA17887@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <CAK5ve-JM=01vTqSi59R6ASyGU_2fVXzKtjNh42LKeF2HF3NzSA@mail.gmail.com>
On Mon, Aug 29, 2011 at 09:18:29PM +0800, Bryan Wu wrote:
> On Mon, Aug 29, 2011 at 7:00 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> > On Fri, Aug 26, 2011 at 11:03 AM, Bryan Wu <bryan.wu@canonical.com> wrote:
> >
> >> Based on Linus Walleij's ARM LED consolidation work, this patchset introduce a
> >> new generic led trigger for CPU not only for ARM but also for others.
> >
> > I think Russell was pretty clear that he saw problems inside the "new LEDs"
> > subsystem (drivers/leds) that need be fixed before we migrate this support
> > to use the LED class devices.
> >
> > Can you see if you can address his comment on the earlier realview patch,
> > i.e. this:
> > http://marc.info/?l=linux-arm-kernel&m=131237280009775&w=2
> >
>
> Yeah, I replied that email with a patch to select LEDS_CLASS when
> CONFIG_NEW_LEDS=y.
I don't see any point to that:
menuconfig NEW_LEDS
bool "LED Support"
select LEDS_CLASS
if NEW_LEDS
config LEDS_CLASS
bool "LED Class Support"
help
This option enables the led sysfs class in /sys/class/leds. You'll
need this to do anything useful with LEDs. If unsure, say N.
So, with that select there, you either have NEW_LEDS=y LEDS_CLASS=y
or NEW_LEDS=n LEDS_CLASS=n. To put it another way, you can't select
LEDS_CLASS when NEW_LEDS=n, and you can't deselect LEDS_CLASS when
NEW_LEDS=y.
So, either the LEDS_CLASS option is completely pointless, which means
it should be killed off, or LEDS_CLASS needs to be fixed so that it
actually does what it says in its help text and controls whether we
have a LEDS sysfs class _without_ affecting the ability to have
triggers setup by platform code.
What it can't do is stay as-is, because it's clearly broken and the
options help texts don't match reality.
next prev parent reply other threads:[~2011-08-29 15:13 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-26 9:03 [PATCH v4 00/18] Introduce a led trigger for CPU activity and consolidate LED driver in ARM Bryan Wu
2011-08-26 9:03 ` [PATCH 01/18] led-triggers: use atomic kzalloc during led trigger registering Bryan Wu
2011-08-26 9:03 ` [PATCH 02/18] led-triggers: create a trigger for CPU activity Bryan Wu
2011-08-26 9:03 ` [PATCH 03/18] arm: at91: convert old leds drivers to gpio_led and led_trigger drivers Bryan Wu
2011-08-26 9:03 ` [PATCH 04/18] mach-realview and mach-versatile: retire custom LED code Bryan Wu
2011-08-26 9:03 ` [PATCH 05/18] mach-ks8695: remove leds driver, since nobody use it Bryan Wu
2011-08-26 9:03 ` [PATCH 06/18] mach-shark: retire custom LED code Bryan Wu
2011-08-26 9:03 ` [PATCH 07/18] mach-orion5x: convert custom LED code to gpio_led and LED CPU trigger Bryan Wu
2011-08-26 9:03 ` [PATCH 08/18] mach-integrator: move CM_CTRL to header file for accessing by other functions Bryan Wu
2011-08-26 9:03 ` [PATCH 09/18] mach-integrator: retire custom LED code Bryan Wu
2011-08-26 9:03 ` [PATCH 10/18] mach-clps711x: retire custom LED code of P720T machine Bryan Wu
2011-08-26 9:03 ` [PATCH 11/18] mach-ebsa110: retire custom LED code Bryan Wu
2011-08-26 9:03 ` [PATCH 12/18] mach-footbridge: " Bryan Wu
2011-08-26 9:03 ` [PATCH 13/18] mach-pxa: " Bryan Wu
2011-08-26 9:03 ` [PATCH 14/18] plat-samsung: remove including old leds event API header file Bryan Wu
2011-08-26 9:03 ` [PATCH 15/18] mach-pnx4008: " Bryan Wu
2011-08-26 9:03 ` [PATCH 16/18] mach-omap1: retire custom LED code Bryan Wu
2011-08-26 9:03 ` [PATCH 17/18] mach-sa1100: " Bryan Wu
2011-08-26 9:03 ` [PATCH 18/18] ARM: use new LEDS CPU trigger stub to replace old one Bryan Wu
2011-08-29 11:00 ` [PATCH v4 00/18] Introduce a led trigger for CPU activity and consolidate LED driver in ARM Linus Walleij
2011-08-29 13:18 ` Bryan Wu
2011-08-29 15:13 ` Russell King - ARM Linux [this message]
2011-08-29 18:10 ` Bryan Wu
2011-08-29 18:26 ` Nicolas Pitre
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=20110829151333.GA17887@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).