linux-toradex.git/drivers/leds, branch v3.10.78 Linux kernel for Apalis and Colibri modules leds: leds-pwm: properly clean up after probe failure 2014-06-07T20:25:34+00:00 Russell King rmk+kernel@arm.linux.org.uk 2014-04-06T22:20:03+00:00 5d33fff5ca9aab5ae7d28fc06179a91eb529758e commit 392369019eb96e914234ea21eda806cb51a1073e upstream. When probing with DT, we add each LED one at a time. If we find a LED without a PWM device (because it is not available yet) we fail the initialisation, unregister previous LEDs, and then by way of managed resources, we free the structure. The problem with this is we may have a scheduled and active work_struct in this structure, and this results in a nasty kernel oops. We need to cancel this work_struct properly upon cleanup - and the cleanup we require is the same cleanup as we do when the LED platform device is removed. Rather than writing this same code three times, move it into a separate function and use it in all three places. Fixes: c971ff185f64 ("leds: leds-pwm: Defer led_pwm_set() if PWM can sleep") Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Bryan Wu <cooloney@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 392369019eb96e914234ea21eda806cb51a1073e upstream.

When probing with DT, we add each LED one at a time.  If we find a LED
without a PWM device (because it is not available yet) we fail the
initialisation, unregister previous LEDs, and then by way of managed
resources, we free the structure.

The problem with this is we may have a scheduled and active work_struct
in this structure, and this results in a nasty kernel oops.

We need to cancel this work_struct properly upon cleanup - and the
cleanup we require is the same cleanup as we do when the LED platform
device is removed.  Rather than writing this same code three times,
move it into a separate function and use it in all three places.

Fixes: c971ff185f64 ("leds: leds-pwm: Defer led_pwm_set() if PWM can sleep")
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
leds: wm831x-status: Request a REG resource 2013-09-27T00:18:27+00:00 Mark Brown broonie@linaro.org 2013-08-29T14:18:14+00:00 d041e861d49f1f558e9e18f2075345f8a37427dc commit 61abeba5222895d6900b13115f5d8eba7988d7d6 upstream. The wm831x-status driver was not converted to use a REG resource when they were introduced and the rest of the wm831x drivers converted, causing it to fail to probe due to requesting the wrong resource type. Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Bryan Wu <cooloney@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 61abeba5222895d6900b13115f5d8eba7988d7d6 upstream.

The wm831x-status driver was not converted to use a REG resource when they
were introduced and the rest of the wm831x drivers converted, causing it
to fail to probe due to requesting the wrong resource type.

Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/leds/leds-ot200.c: fix error caused by shifted mask 2013-05-24T23:22:51+00:00 Christian Gmeiner christian.gmeiner@gmail.com 2013-05-24T22:55:22+00:00 4b949b8af12e24b8a48fa5bb775a13b558d9f4da During the development of this driver an in-house register documentation was used. The last week some integration tests were done and this problem was found. It turned out that the released register documentation is wrong. The fix is very simple: shift all masks by one. Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: Bryan Wu <cooloney@gmail.com> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
During the development of this driver an in-house register documentation
was used.  The last week some integration tests were done and this
problem was found.  It turned out that the released register
documentation is wrong.

The fix is very simple: shift all masks by one.

Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Cc: Bryan Wu <cooloney@gmail.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
leds: leds-gpio: reserve gpio before using it 2013-05-21T18:26:53+00:00 Timo Teräs timo.teras@iki.fi 2013-05-17T07:48:39+00:00 803d19d57a042e86e9e9b685bbc3f4a0a751040f This reverts commit a99d76f (leds: leds-gpio: use gpio_request_one) and commit 2d7c22f (leds: leds-gpio: set devm_gpio_request_one() flags param correctly) which was a fix of the first one. The conversion to devm_gpio_request in commit e3b1d44c (leds: leds-gpio: use devm_gpio_request_one) is not reverted. The problem is that gpio_cansleep() and gpio_get_value_cansleep() calls can crash if the gpio is not first reserved. Incidentally this same bug existed earlier and was fixed similarly in commit d95cbe61 (leds: Fix potential leds-gpio oops). But the OOPS is real. It happens when GPIOs are provided by module which is not yet loaded. So this fixes the following BUG during my ALIX boot (3.9.2-vanilla): BUG: unable to handle kernel NULL pointer dereference at 0000004c IP: [<c11287d6>] __gpio_cansleep+0xe/0x1a *pde = 00000000 Oops: 0000 [#1] SMP Modules linked in: leds_gpio(+) via_rhine mii cs5535_mfd mfd_core geode_rng rng_core geode_aes isofs nls_utf8 nls_cp437 vfat fat ata_generic pata_amd pata_cs5536 pata_acpi libata ehci_pci ehci_hcd ohci_hcd usb_storage usbcore usb_common sd_mod scsi_mod squashfs loop Pid: 881, comm: modprobe Not tainted 3.9.2 #1-Alpine EIP: 0060:[<c11287d6>] EFLAGS: 00010282 CPU: 0 EIP is at __gpio_cansleep+0xe/0x1a EAX: 00000000 EBX: cf364018 ECX: c132b8b9 EDX: 00000000 ESI: c13993a4 EDI: c1399370 EBP: cded9dbc ESP: cded9dbc DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 CR0: 8005003b CR2: 0000004c CR3: 0f0c4000 CR4: 00000090 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 DR6: ffff0ff0 DR7: 00000400 Process modprobe (pid: 881, ti=cded8000 task=cf094aa0 task.ti=cded8000) Stack: cded9de0 d09471cb 00000000 c1399260 cf364014 00000000 c1399260 c1399254 d0949014 cded9df4 c118cd59 c1399260 d0949014 d0949014 cded9e08 c118ba47 c1399260 d0949014 c1399294 cded9e1c c118bb75 cded9e24 d0949014 00000000 Call Trace: [<d09471cb>] gpio_led_probe+0xba/0x203 [leds_gpio] [<c118cd59>] platform_drv_probe+0x26/0x48 [<c118ba47>] driver_probe_device+0x75/0x15c [<c118bb75>] __driver_attach+0x47/0x63 [<c118a727>] bus_for_each_dev+0x3c/0x66 [<c118b6f9>] driver_attach+0x14/0x16 [<c118bb2e>] ? driver_probe_device+0x15c/0x15c [<c118b3d5>] bus_add_driver+0xbd/0x1bc [<d08b4000>] ? 0xd08b3fff [<d08b4000>] ? 0xd08b3fff [<c118bffc>] driver_register+0x74/0xec [<d08b4000>] ? 0xd08b3fff [<c118c8e8>] platform_driver_register+0x38/0x3a [<d08b400d>] gpio_led_driver_init+0xd/0x1000 [leds_gpio] [<c100116c>] do_one_initcall+0x6b/0x10f [<d08b4000>] ? 0xd08b3fff [<c105e918>] load_module+0x1631/0x1907 [<c10975d6>] ? insert_vmalloc_vmlist+0x14/0x43 [<c1098d5b>] ? __vmalloc_node_range+0x13e/0x15f [<c105ec50>] sys_init_module+0x62/0x77 [<c1257888>] syscall_call+0x7/0xb EIP: [<c11287d6>] __gpio_cansleep+0xe/0x1a SS:ESP 0068:cded9dbc CR2: 000000000000004c ---[ end trace 5308fb20d2514822 ]--- Signed-off-by: Timo Teräs <timo.teras@iki.f> Cc: Sachin Kamat <sachin.kamat@linaro.org> Cc: Raphael Assenat <raph@8d.com> Cc: Trent Piepho <tpiepho@freescale.com> Cc: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Cc: Arnaud Patard <arnaud.patard@rtp-net.org> Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Acked-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com> 
This reverts commit a99d76f (leds: leds-gpio: use gpio_request_one)
and commit 2d7c22f (leds: leds-gpio: set devm_gpio_request_one()
flags param correctly) which was a fix of the first one.

The conversion to devm_gpio_request in commit e3b1d44c (leds:
leds-gpio: use devm_gpio_request_one) is not reverted.

The problem is that gpio_cansleep() and gpio_get_value_cansleep()
calls can crash if the gpio is not first reserved. Incidentally this
same bug existed earlier and was fixed similarly in commit d95cbe61
(leds: Fix potential leds-gpio oops). But the OOPS is real. It happens
when GPIOs are provided by module which is not yet loaded.

So this fixes the following BUG during my ALIX boot (3.9.2-vanilla):

BUG: unable to handle kernel NULL pointer dereference at 0000004c
IP: [<c11287d6>] __gpio_cansleep+0xe/0x1a
*pde = 00000000
Oops: 0000 [#1] SMP
Modules linked in: leds_gpio(+) via_rhine mii cs5535_mfd mfd_core
geode_rng rng_core geode_aes isofs nls_utf8 nls_cp437 vfat fat
ata_generic pata_amd pata_cs5536 pata_acpi libata ehci_pci ehci_hcd
ohci_hcd usb_storage usbcore usb_common sd_mod scsi_mod squashfs loop
Pid: 881, comm: modprobe Not tainted 3.9.2 #1-Alpine
EIP: 0060:[<c11287d6>] EFLAGS: 00010282 CPU: 0
EIP is at __gpio_cansleep+0xe/0x1a
EAX: 00000000 EBX: cf364018 ECX: c132b8b9 EDX: 00000000
ESI: c13993a4 EDI: c1399370 EBP: cded9dbc ESP: cded9dbc
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
CR0: 8005003b CR2: 0000004c CR3: 0f0c4000 CR4: 00000090
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
Process modprobe (pid: 881, ti=cded8000 task=cf094aa0 task.ti=cded8000)
Stack:
 cded9de0 d09471cb 00000000 c1399260 cf364014 00000000 c1399260 c1399254
 d0949014 cded9df4 c118cd59 c1399260 d0949014 d0949014 cded9e08 c118ba47
 c1399260 d0949014 c1399294 cded9e1c c118bb75 cded9e24 d0949014 00000000
Call Trace:
 [<d09471cb>] gpio_led_probe+0xba/0x203 [leds_gpio]
 [<c118cd59>] platform_drv_probe+0x26/0x48
 [<c118ba47>] driver_probe_device+0x75/0x15c
 [<c118bb75>] __driver_attach+0x47/0x63
 [<c118a727>] bus_for_each_dev+0x3c/0x66
 [<c118b6f9>] driver_attach+0x14/0x16
 [<c118bb2e>] ? driver_probe_device+0x15c/0x15c
 [<c118b3d5>] bus_add_driver+0xbd/0x1bc
 [<d08b4000>] ? 0xd08b3fff
 [<d08b4000>] ? 0xd08b3fff
 [<c118bffc>] driver_register+0x74/0xec
 [<d08b4000>] ? 0xd08b3fff
 [<c118c8e8>] platform_driver_register+0x38/0x3a
 [<d08b400d>] gpio_led_driver_init+0xd/0x1000 [leds_gpio]
 [<c100116c>] do_one_initcall+0x6b/0x10f
 [<d08b4000>] ? 0xd08b3fff
 [<c105e918>] load_module+0x1631/0x1907
 [<c10975d6>] ? insert_vmalloc_vmlist+0x14/0x43
 [<c1098d5b>] ? __vmalloc_node_range+0x13e/0x15f
 [<c105ec50>] sys_init_module+0x62/0x77
 [<c1257888>] syscall_call+0x7/0xb
EIP: [<c11287d6>] __gpio_cansleep+0xe/0x1a SS:ESP 0068:cded9dbc
CR2: 000000000000004c
 ---[ end trace 5308fb20d2514822 ]---

Signed-off-by: Timo Teräs <timo.teras@iki.f>
Cc: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Raphael Assenat <raph@8d.com>
Cc: Trent Piepho <tpiepho@freescale.com>
Cc: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Cc: Arnaud Patard <arnaud.patard@rtp-net.org>
Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Merge tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux 2013-05-09T16:59:16+00:00 Linus Torvalds torvalds@linux-foundation.org 2013-05-09T16:59:16+00:00 5647ac0ad4f355817b788372a01cb293ed63bde4 Pull removal of GENERIC_GPIO from Grant Likely: "GENERIC_GPIO now synonymous with GPIOLIB. There are no longer any valid cases for enableing GENERIC_GPIO without GPIOLIB, even though it is possible to do so which has been causing confusion and breakage. This branch does the work to completely eliminate GENERIC_GPIO." * tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux: gpio: update gpio Chinese documentation Remove GENERIC_GPIO config option Convert selectors of GENERIC_GPIO to GPIOLIB blackfin: force use of gpiolib m68k: coldfire: use gpiolib mips: pnx833x: remove requirement for GENERIC_GPIO openrisc: default GENERIC_GPIO to false avr32: default GENERIC_GPIO to false xtensa: remove explicit selection of GENERIC_GPIO sh: replace CONFIG_GENERIC_GPIO by CONFIG_GPIOLIB powerpc: remove redundant GENERIC_GPIO selection unicore32: default GENERIC_GPIO to false unicore32: remove unneeded select GENERIC_GPIO arm: plat-orion: use GPIO driver on CONFIG_GPIOLIB arm: remove redundant GENERIC_GPIO selection mips: alchemy: require gpiolib mips: txx9: change GENERIC_GPIO to GPIOLIB mips: loongson: use GPIO driver on CONFIG_GPIOLIB mips: remove redundant GENERIC_GPIO select 
Pull removal of GENERIC_GPIO from Grant Likely:
 "GENERIC_GPIO now synonymous with GPIOLIB.  There are no longer any
  valid cases for enableing GENERIC_GPIO without GPIOLIB, even though it
  is possible to do so which has been causing confusion and breakage.
  This branch does the work to completely eliminate GENERIC_GPIO."

* tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux:
  gpio: update gpio Chinese documentation
  Remove GENERIC_GPIO config option
  Convert selectors of GENERIC_GPIO to GPIOLIB
  blackfin: force use of gpiolib
  m68k: coldfire: use gpiolib
  mips: pnx833x: remove requirement for GENERIC_GPIO
  openrisc: default GENERIC_GPIO to false
  avr32: default GENERIC_GPIO to false
  xtensa: remove explicit selection of GENERIC_GPIO
  sh: replace CONFIG_GENERIC_GPIO by CONFIG_GPIOLIB
  powerpc: remove redundant GENERIC_GPIO selection
  unicore32: default GENERIC_GPIO to false
  unicore32: remove unneeded select GENERIC_GPIO
  arm: plat-orion: use GPIO driver on CONFIG_GPIOLIB
  arm: remove redundant GENERIC_GPIO selection
  mips: alchemy: require gpiolib
  mips: txx9: change GENERIC_GPIO to GPIOLIB
  mips: loongson: use GPIO driver on CONFIG_GPIOLIB
  mips: remove redundant GENERIC_GPIO select
Convert selectors of GENERIC_GPIO to GPIOLIB 2013-04-16T09:47:14+00:00 Alexandre Courbot acourbot@nvidia.com 2013-03-28T11:34:56+00:00 76ec9d18b8972f1b228f819f6126c9f022b3e642 GENERIC_GPIO is now equivalent to GPIOLIB and features that depended on GENERIC_GPIO can now depend on GPIOLIB to allow removal of this option. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Grant Likely <grant.likely@secretlab.ca> 
GENERIC_GPIO is now equivalent to GPIOLIB and features that depended on
GENERIC_GPIO can now depend on GPIOLIB to allow removal of this option.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
leds: leds-asic3: switch to using SIMPLE_DEV_PM_OPS 2013-04-01T18:04:54+00:00 Jingoo Han jg1.han@samsung.com 2013-03-26T06:47:19+00:00 df92d5ff5e70999274f53884cc2c40ae620a109a Switch to using SIMPLE_DEV_PM_OPS macro to declare the driver's pm_ops. It reduces code size. Also, CONFIG_PM_SLEEP is added to suspend/ resume functions to prevent build warnings when CONFIG_PM_SLEEP is not selected. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com> 
Switch to using SIMPLE_DEV_PM_OPS  macro to declare the driver's
pm_ops. It reduces code size. Also, CONFIG_PM_SLEEP is added to
suspend/ resume functions to prevent build warnings when
CONFIG_PM_SLEEP is not selected.

Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
leds: leds-bd2802: add CONFIG_PM_SLEEP to suspend/resume functions 2013-04-01T18:04:53+00:00 Jingoo Han jg1.han@samsung.com 2013-03-22T02:09:01+00:00 cceba0e4b8f41a495dc7a5ab2795dcab0ddb64c1 Add CONFIG_PM_SLEEP to suspend/resume functions to fix the following build warning when CONFIG_PM_SLEEP is not selected. This is because sleep PM callbacks defined by SIMPLE_DEV_PM_OPS are only used when the CONFIG_PM_SLEEP is enabled. drivers/leds/leds-bd2802.c:766:12: warning: 'bd2802_suspend' defined but not used [-Wunused-function] drivers/leds/leds-bd2802.c:776:12: warning: 'bd2802_resume' defined but not used [-Wunused-function] Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com> 
Add CONFIG_PM_SLEEP to suspend/resume functions to fix the following
build warning when CONFIG_PM_SLEEP is not selected. This is because
sleep PM callbacks defined by SIMPLE_DEV_PM_OPS are only used when
the CONFIG_PM_SLEEP is enabled.

drivers/leds/leds-bd2802.c:766:12: warning: 'bd2802_suspend' defined but not used [-Wunused-function]
drivers/leds/leds-bd2802.c:776:12: warning: 'bd2802_resume' defined but not used [-Wunused-function]

Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
leds: lp55xx: configure the clock detection 2013-04-01T18:04:53+00:00 Kim, Milo Milo.Kim@ti.com 2013-03-21T00:37:04+00:00 81f2a5b4a0570a662efd629c176fc1d67e56f7e3 Now LP55xx provides automatic clock detection API, lp55xx_is_extclk_used(). The clock configuration can be done by the driver itself. (a) Concept The default value is set by each driver with clock selection. The internal clock selection bit is updated in case that the external clock is not detected or clock rate is not 32KHz. (b) Change on LP55xx platform data The clock configuration is done automatically, so no need to define 'update_config' in the platform side. Correlated information are removed in the documentations and header. (c) Definitions moved from header to driver files CONFIG register values are moved each driver, LP5521 and LP5562. Not necessary definitions are removed also. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com> 
Now LP55xx provides automatic clock detection API, lp55xx_is_extclk_used().
The clock configuration can be done by the driver itself.

(a) Concept
The default value is set by each driver with clock selection.
The internal clock selection bit is updated in case that the external clock
is not detected or clock rate is not 32KHz.

(b) Change on LP55xx platform data
The clock configuration is done automatically, so no need to define
'update_config' in the platform side.
Correlated information are removed in the documentations and header.

(c) Definitions moved from header to driver files
CONFIG register values are moved each driver, LP5521 and LP5562.
Not necessary definitions are removed also.

Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
leds: lp55xx: use common clock framework when external clock is used 2013-04-01T18:04:53+00:00 Kim, Milo Milo.Kim@ti.com 2013-03-21T00:37:00+00:00 53b4192266436e75dea96c8ef495eadd6f3df981 Program execution is timed with 32768Hz clock in the LP55xx family devices. To run LED functionalities, LP55xx devices provide two options. One is using internal clock. The other is using external clock. This patch enables external clock detection automatically. If external clock is not detected, then the internal clock will be used in the LP55xx driver. Valid clock rate is 32768Hz in LP55xx devices. This new API is used in each LP55xx driver like LP5521 and LP5562. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com> 
Program execution is timed with 32768Hz clock in the LP55xx family devices.
To run LED functionalities, LP55xx devices provide two options.
One is using internal clock. The other is using external clock.
This patch enables external clock detection automatically.
If external clock is not detected, then the internal clock will be used in the
LP55xx driver.

Valid clock rate is 32768Hz in LP55xx devices.

This new API is used in each LP55xx driver like LP5521 and LP5562.

Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>