From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 03/17] mach-realview and mach-versatile: retire custom LED code
Date: Wed, 3 Aug 2011 12:59:18 +0100 [thread overview]
Message-ID: <20110803115918.GA23953@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <1312364089-32380-4-git-send-email-bryan.wu@canonical.com>
On Wed, Aug 03, 2011 at 05:34:35PM +0800, Bryan Wu wrote:
> From: Linus Walleij <linus.walleij@linaro.org>
>
> This replaces the custom LED trigger code in mach-realview with
> some overarching platform code for the plat-versatile family that
> will lock down LEDs 2 thru 5 for CPU activity indication. The
> day we have 8 core ARM systems the plat-versatile code will have
> to become more elaborate.
>
> Tested on RealView PB11MPCore by invoking four different CPU
> hogs (yes > /dev/null&) and see the LEDs go on one at a time.
> They all go off as the hogs are killed. Tested on the PB1176
> as well - just one activity led (led 2) goes on and off with
> CPU activity.
>
> (bryan.wu at canonical.com: use ledtrig-cpu instead of ledtrig-arm-cpu)
This is broken. More than that, this LEDS stuff is broken.
With CONFIG_NEW_LEDS=y and CONFIG_LEDS_CLASS=n,
CC arch/arm/plat-versatile/leds.o
arch/arm/plat-versatile/leds.c: In function 'versatile_leds_init':
arch/arm/plat-versatile/leds.c:91: error: 'struct led_classdev' has no member named 'trigger_data'
I wasn't offered LEDS_TRIGGERS to select. It looks like this leds
stuff really is broken:
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.
Okay, this says its for sysfs support. But then:
config LEDS_TRIGGERS
bool "LED Trigger support"
depends on LEDS_CLASS
help
This option enables trigger support for the leds class.
These triggers allow kernel events to drive the LEDs and can
be configured via sysfs. If unsure, say Y.
you can only have LED triggers if you have LED class support. So what's
the point of NEW_LEDS=y and LEDS_CLASS=n? From those descriptions,
LEDS_CLASS should control the sysfs interfaces, and LEDS_TRIGGERS should
control the kernel internal interfaces _independently_.
As things stand, this looks completely crazy. So no, I'm not acking these
patches until the LEDs layer gets a modicum of sanity.
next prev parent reply other threads:[~2011-08-03 11:59 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-03 9:34 [PATCH v2 00/17] Introduce a led trigger for CPU activity and consolidate LED driver in ARM Bryan Wu
2011-08-03 9:34 ` [PATCH 01/17] leds: create a trigger for CPU activity Bryan Wu
2011-08-03 10:23 ` Michał Mirosław
2011-08-04 9:18 ` Bryan Wu
2011-08-03 10:28 ` Jamie Iles
2011-08-03 15:22 ` Linus Walleij
2011-08-03 15:30 ` Jamie Iles
2011-08-03 16:02 ` Jochen Friedrich
2011-08-03 16:12 ` Linus Walleij
2011-08-05 9:48 ` Bryan Wu
2011-08-03 9:34 ` [PATCH 02/17] arm: at91: convert old leds drivers to gpio_led and led_trigger drivers Bryan Wu
2011-08-03 9:34 ` [PATCH 03/17] mach-realview and mach-versatile: retire custom LED code Bryan Wu
2011-08-03 11:59 ` Russell King - ARM Linux [this message]
2011-08-17 11:06 ` Bryan Wu
2011-08-03 9:34 ` [PATCH 04/17] mach-ks8695: remove leds driver, since nobody use it Bryan Wu
2011-08-03 9:34 ` [PATCH 05/17] mach-shark: retire custom LED code Bryan Wu
2011-08-03 9:34 ` [PATCH 06/17] mach-orion5x: convert custom LED code to gpio_led and LED CPU trigger Bryan Wu
2011-08-03 9:34 ` [PATCH 07/17] mach-integrator: introduce cm_read function helper to read CM_CTRL register Bryan Wu
2011-08-03 11:29 ` Sergei Shtylyov
2011-08-04 8:54 ` Bryan Wu
2011-08-03 11:30 ` Sergei Shtylyov
2011-08-03 9:34 ` [PATCH 08/17] mach-integrator: retire custom LED code Bryan Wu
2011-08-03 9:34 ` [PATCH 09/17] mach-clps711x: retire custom LED code of P720T machine Bryan Wu
2011-08-03 9:34 ` [PATCH 10/17] mach-ebsa110: retire custom LED code Bryan Wu
2011-08-03 9:34 ` [PATCH 11/17] mach-footbridge: " Bryan Wu
2011-08-03 9:34 ` [PATCH 12/17] mach-pxa: " Bryan Wu
2011-08-03 9:34 ` [PATCH 13/17] plat-samsung: remove including old leds event API header file Bryan Wu
2011-08-03 9:34 ` [PATCH 14/17] mach-pnx4008: " Bryan Wu
2011-08-03 9:34 ` [PATCH 15/17] mach-omap1: retire custom LED code Bryan Wu
2011-08-03 9:34 ` [PATCH 16/17] mach-sa1100: " Bryan Wu
2011-08-03 9:34 ` [PATCH 17/17] ARM: use new LEDS CPU trigger stub to replace old one Bryan Wu
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=20110803115918.GA23953@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).