linux-stable.git/drivers/leds, branch linux-2.6.33.y

leds: fix bug with reading NAS SS4200 dmi code

2011-03-21T19:44:10+00:00

commit 50d431e8a15701b599c98afe2b464eb33c952477 upstream.

While running randconfg with ktest.pl I stumbled upon this bug:

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000003
  IP: [] strstr+0x39/0x86
  PGD 0
  Oops: 0000 [#1] SMP
  last sysfs file:
  CPU 0
  Modules linked in:

  Pid: 1, comm: swapper Not tainted 2.6.37-rc1-test+ #6 DG965MQ/
  RIP: 0010:[]  [] strstr+0x39/0x86
  RSP: 0018:ffff8800797cbd80  EFLAGS: 00010213
  RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffffffffffff
  RDX: 0000000000000000 RSI: ffffffff82eb7ac9 RDI: 0000000000000003
  RBP: ffff8800797cbda0 R08: ffff880000000003 R09: 0000000000030725
  R10: ffff88007d294c00 R11: 0000000000014c00 R12: 0000000000000020
  R13: ffffffff82eb7ac9 R14: ffffffffffffffff R15: ffffffff82eb7b08
  FS:  0000000000000000(0000) GS:ffff88007d200000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
  CR2: 0000000000000003 CR3: 0000000002a1d000 CR4: 00000000000006f0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
  Process swapper (pid: 1, threadinfo ffff8800797ca000, task ffff8800797d0000)
  Stack:
   00000000000000ba ffffffff82eb7ac9 ffffffff82eb7ab8 00000000000000ba
   ffff8800797cbdf0 ffffffff81e2050f ffff8800797cbdc0 00000000815f913b
   ffff8800797cbe00 ffffffff82eb7ab8 0000000000000000 0000000000000000
  Call Trace:
   [] dmi_matches+0x117/0x154
   [] dmi_check_system+0x3d/0x8d
   [] ? nas_gpio_init+0x0/0x2c8
   [] nas_gpio_init+0x24/0x2c8
   [] ? wm8350_led_init+0x0/0x20
   [] ? nas_gpio_init+0x0/0x2c8
   [] do_one_initcall+0xab/0x1b2
   [] kernel_init+0x248/0x331
   [] kernel_thread_helper+0x4/0x10
   [] ? kernel_init+0x0/0x331

Found that the nas_led_whitelist dmi_system_id structure array had no
NULL end delimiter, causing the dmi_check_system() loop to read an
undefined entry.

Signed-off-by: Steven Rostedt 
Acked-by: Dave Hansen 
Acked-by: Richard Purdie 
Acked-by: Arjan van de Ven 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

leds-gpio: fix default state handling on OF platforms

2010-04-01T23:01:58+00:00

commit 0493a4ff10959ff4c8e0d65efee25b7ffd4fa5db upstream.

The driver wrongly sets default state for LEDs that don't specify
default-state property.

Currently the driver handles default state this way:

memset(&led, 0, sizeof(led));
for_each_child_of_node(np, child) {
	state = of_get_property(child, "default-state", NULL);
	if (state) {
		if (!strcmp(state, "keep"))
			led.default_state = LEDS_GPIO_DEFSTATE_KEEP;
		...
	}
	ret = create_gpio_led(&led, ...);
}

Which means that all LEDs that do not specify default-state will inherit
the last value of the default-state property, which is wrong.

This patch fixes the issue by moving LED's template initialization into
the loop body.

Signed-off-by: Anton Vorontsov 
Signed-off-by: Andrew Morton 
Signed-off-by: Richard Purdie 
Signed-off-by: Greg Kroah-Hartman

leds: leds-pwm: Set led_classdev max_brightness

2009-12-17T11:42:34+00:00

Currently the driver leds-pwm doesn't set max_brightness for the led device
although it's platform data proides a maximum brightness. Instead it stores its
own private driver struct. The max_brightness defaults to 255 for led device if
it has not been set.
As a result any leds-pwm device with a different maximum brightness will show
incorrect behavior, as it is posible to either set a longer then period duty
time or not be able to switch the led to full brightness.

Signed-off-by: Lars-Peter Clausen 
Signed-off-by: Richard Purdie

leds: use default-on trigger for Cobalt Qube

2009-12-17T11:38:31+00:00

This patch changes the default trigger from "ide-disk"
to "default-on". Users updating from kernels not having this
LED driver will prefer having the same LED behavior as they
used to.

Signed-off-by: Florian Fainelli 
Signed-off-by: Richard Purdie

leds: drivers/leds/leds-ss4200.c: fix return statement

2009-12-17T11:36:40+00:00

drivers/leds/leds-ss4200.c: In function 'ich7_lpc_probe':
drivers/leds/leds-ss4200.c:353: warning: 'return' with no value, in function returning non-void

Signed-off-by: Andrew Morton 
Signed-off-by: Richard Purdie

leds: Add LED class driver for regulator driven LEDs.

2009-12-17T11:27:09+00:00

This driver provides an interface for controlling LEDs (or vibrators)
connected to PMICs for which there is a regulator framework driver.

This driver can be used, for instance, to control vibrator on all Motorola EZX
phones using the pcap-regulator driver services.

Signed-off-by: Antonio Ospite 
Reviewed-by: Mark Brown 
Signed-off-by: Richard Purdie

leds: leds-cobalt-qube.c: use resource_size()

2009-12-17T11:18:15+00:00

Use resource_size() for ioremap.

Signed-off-by: H Hartley Sweeten 
Signed-off-by: Richard Purdie

leds: leds-cobalt-raq.c - use resource_size()

2009-12-17T11:16:23+00:00

Use resource_size() for ioremap.

Signed-off-by: H Hartley Sweeten 
Signed-off-by: Richard Purdie

leds: Add driver for ADP5520/ADP5501 MFD PMICs

2009-12-16T11:30:10+00:00

Signed-off-by: Michael Hennerich 
Signed-off-by: Bryan Wu 
Signed-off-by: Mike Frysinger 
Signed-off-by: Richard Purdie

leds: Add driver for LT3593 controlled LEDs

2009-12-16T11:30:09+00:00

The LT3593 is a step-up DC/DC converter designed to drive up to ten
white LEDs in series. The current flow can be set with a control pin.

This driver controls any number of such devices connected on generic
GPIOs and exports the function as as platform_driver.

The gpio_led platform data struct definition is reused for this purpose.

Successfully tested on a PXA embedded board.

Signed-off-by: Daniel Mack 
Signed-off-by: Richard Purdie