02 Jul, 2013
1 commit
-
drivers/leds/leds-mc13783.c: In function 'mc13xxx_led_probe':
drivers/leds/leds-mc13783.c:195:2: warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized]Signed-off-by: Alexander Shiyan
Signed-off-by: Bryan Wu
21 Jun, 2013
16 commits
-
Convert drivers/leds/led-class to use dev_pm_ops for power management and
remove Legacy PM ops hooks. With this change, led class registers
suspend/resume callbacks via class->pm (dev_pm_ops) instead of Legacy
class->suspend/resume. When __device_suspend() runs call-backs, it will
find class->pm ops for the led class.Signed-off-by: Shuah Khan
Signed-off-by: Bryan Wu -
Signed-off-by: Alexander Shiyan
Tested-by: Philippe Retornaz
Signed-off-by: Bryan Wu -
This patch rewrite driver code to be ready to add support for
MC13892 LEDs and probe from devicetree.(cooloney@gmail.com: fix one coding style issue when apply this patch)
Signed-off-by: Alexander Shiyan
Tested-by: Philippe Retornaz
Signed-off-by: Bryan Wu -
Static checkers complain that, although this is declared as an
unsigned long, we can only use the lower 32 bits. For anything
higher, we hit bugs widening then bitwise negate or wrapping bugs
doing the left shift.From looking at the context, this is not a problem because we only
use 16 bits. I've changed some types to make it more clear.Signed-off-by: Dan Carpenter
Signed-off-by: Bryan Wu -
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
so we can directly pass a struct platform_device.Signed-off-by: Jingoo Han
Signed-off-by: Bryan Wu -
Since commit ab78029 (drivers/pinctrl: grab default handles from device core)
we can rely on device core for handling pinctrl, so remove
devm_pinctrl_get_select_default() from the driver.Reported-by: Stephen Warren
Signed-off-by: Fabio Estevam
Signed-off-by: Bryan Wu -
Don't mix of_device_id entry in i2c_device_id table.
Signed-off-by: Axel Lin
Reviewed-by: Linus Walleij
Signed-off-by: Bryan Wu -
Don't mix of_device_id entry in i2c_device_id table.
Signed-off-by: Axel Lin
Reviewed-by: Linus Walleij
Signed-off-by: Bryan Wu -
Don't mix of_device_id entry in i2c_device_id table.
Signed-off-by: Axel Lin
Reviewed-by: Linus Walleij
Signed-off-by: Bryan Wu -
The LP55xx DT structure is applicable to the LP5562 device.
The driver and documentation are updated.Compatible property of the DT
: LP5521 and LP5223 were manufactured by National Semiconductor.
LP5562 is a new device from Texas Instruments.Cc: Gabriel Fernandez
Signed-off-by: Milo(Woogyom) Kim
Acked-by: Linus Walleij
Signed-off-by: Bryan Wu -
Currently, the LP55xx DT structure supports max 3 channels.
However, LP5523 has max 9 channels and LP5562 has 4 channels.
To enhance this constraint, the DT structure has been changed.(a) Use the child node for various channel settings instead of fixed array
(b) Remove 'num_channel' property.
This value can be retrieved by counting the children node.
(c) 'chan-name' property supported
(d) Documentation updates for LP5521 and LP5523(cooloney@gmail.com: fix a coding style issue in leds-lp55xx.txt)
Cc: Gabriel Fernandez
Signed-off-by: Milo(Woogyom) Kim
Reviewed-by: Linus Walleij
Signed-off-by: Bryan Wu -
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.Signed-off-by: Jingoo Han
Signed-off-by: Bryan Wu -
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.Signed-off-by: Jingoo Han
Signed-off-by: Bryan Wu -
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.Signed-off-by: Jingoo Han
Signed-off-by: Bryan Wu -
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.Signed-off-by: Jingoo Han
Signed-off-by: Bryan Wu -
This patch allows the lp5521 driver to be successfully probed and
initialised when Device Tree support is enabled.Based on a patch by Gabriel Fernandez, rewritten in accordance
with review feedback.Cc: Gabriel Fernandez
Signed-off-by: Linus Walleij
Acked-by: Milo Kim
Signed-off-by: Bryan Wu
25 May, 2013
1 commit
-
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
Cc: Bryan Wu
Cc: Sebastian Andrzej Siewior
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
22 May, 2013
1 commit
-
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: [] __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:[] 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:
[] gpio_led_probe+0xba/0x203 [leds_gpio]
[] platform_drv_probe+0x26/0x48
[] driver_probe_device+0x75/0x15c
[] __driver_attach+0x47/0x63
[] bus_for_each_dev+0x3c/0x66
[] driver_attach+0x14/0x16
[] ? driver_probe_device+0x15c/0x15c
[] bus_add_driver+0xbd/0x1bc
[] ? 0xd08b3fff
[] ? 0xd08b3fff
[] driver_register+0x74/0xec
[] ? 0xd08b3fff
[] platform_driver_register+0x38/0x3a
[] gpio_led_driver_init+0xd/0x1000 [leds_gpio]
[] do_one_initcall+0x6b/0x10f
[] ? 0xd08b3fff
[] load_module+0x1631/0x1907
[] ? insert_vmalloc_vmlist+0x14/0x43
[] ? __vmalloc_node_range+0x13e/0x15f
[] sys_init_module+0x62/0x77
[] syscall_call+0x7/0xb
EIP: [] __gpio_cansleep+0xe/0x1a SS:ESP 0068:cded9dbc
CR2: 000000000000004c
---[ end trace 5308fb20d2514822 ]---Signed-off-by: Timo Teräs
Cc: Sachin Kamat
Cc: Raphael Assenat
Cc: Trent Piepho
Cc: Javier Martinez Canillas
Cc: Arnaud Patard
Cc: Ezequiel Garcia
Acked-by: Jingoo Han
Signed-off-by: Bryan Wu
10 May, 2013
1 commit
-
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
16 Apr, 2013
1 commit
-
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
Acked-by: Linus Walleij
Acked-by: Grant Likely
02 Apr, 2013
18 commits
-
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
Signed-off-by: Bryan Wu -
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
Signed-off-by: Bryan Wu -
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
Signed-off-by: Bryan Wu -
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
Signed-off-by: Bryan Wu -
This patch fixes a regression introduced by commit 72052fcc10
("leds: leds-ns2: add device tree binding").When the driver is initialized with device tree data, platform_data
pointer is NULL. This causes a kernel oops at removal.To fix this bug, num_leds is moved into driver_data and platform_data
is not longer used from ns2_led_remove().Signed-off-by: Simon Guinot
Signed-off-by: Bryan Wu -
Call to led_pwm_set() can happen inside atomic context, like triggers.
If the PWM call can sleep, defer using a worker.Signed-off-by: Florian Vaussard
Reviewed-by: Peter Ujfalusi
Acked-by: Thierry Reding
Signed-off-by: Bryan Wu -
According to a sysfs documentation(Documentation/filesystem/sysfs.txt),
scnprintf() should be used in a read operation method.
It guarantees safe buffer size(PAGE_SIZE) which is allocated by the sysfs.Signed-off-by: Milo(Woogyom) Kim
Signed-off-by: Bryan Wu -
LM355x and LM3642 support flash and torch functionality.
(Camera driver) (LED trigger for camera) (LED driver)
Turn on the flash ...> ledtrig_flash_ctrl(true) ...> LM355x or LM3642
brightness ctrl
Flash/torch LEDs are controlled by other driver using LED camera trigger
APIs, ledtrig_flash_ctrl()/ledtrig_torch_ctrl().
Then, actual device control is activated by each LED driver such like
LM355x or LM3642.Signed-off-by: Milo(Woogyom) Kim
Signed-off-by: Bryan Wu -
Some LED devices support flash/torch functionality through the LED subsystem.
This patch enables direct LED trigger controls by the driver.
Flash on/off and torch on/off can be done simply by other driver space.
Two trigger APIs are added, ledtrig_flash_ctrl() and ledtrig_torch_ctrl().Signed-off-by: Milo(Woogyom) Kim
Signed-off-by: Bryan Wu -
This eliminates having an #ifdef returning NULL for the case
when OF is disabled.Signed-off-by: Sachin Kamat
Signed-off-by: Bryan Wu -
Provide some trace, though the hardware is most likely non-functional if
this happens.Signed-off-by: Mark Brown
Signed-off-by: Bryan Wu -
The gpio_request_one() flags parameter was set to:
GPIOF_DIR_OUT | !!brightness
GPIOF_DIR_OUT and GPIOF_DIR_IN are defined as below:
GPIOF_DIR_OUT (0 << 0)
GPIOF_DIR_IN (1 << 0)So, when '!!brightness' is 1, the gpio pin can be set as input,
instead of output.To prevent this problem, GPIOF_OUT_INIT flags should be used when
using gpio_request_one().Signed-off-by: Jingoo Han
Signed-off-by: Bryan Wu -
The devm_gpio_request_one() flags parameter was set to:
GPIOF_DIR_OUT | gpio_get_value(template->cmd)
GPIOF_DIR_OUT and GPIOF_DIR_IN are defined as below:
GPIOF_DIR_OUT (0 << 0)
GPIOF_DIR_IN (1 << 0)So, when 'gpio_get_value(template->cmd)' is 1, the gpio pin can
be set as input, instead of output.To prevent this problem, GPIOF_OUT_INIT flags should be used when
using devm_gpio_request_one().Same goes for 'gpio_get_value(template->slow)' case.
Signed-off-by: Jingoo Han
Signed-off-by: Bryan Wu -
The devm_gpio_request_one() flags parameter was set to:
GPIOF_DIR_OUT | state
GPIOF_DIR_OUT and GPIOF_DIR_IN are defined as below:
GPIOF_DIR_OUT (0 << 0)
GPIOF_DIR_IN (1 << 0)So, when 'state' is 1, the gpio pin can be set as input, instead
of output.To prevent this problem, GPIOF_OUT_INIT flags should be used when
using devm_gpio_request_one().Signed-off-by: Jingoo Han
Signed-off-by: Bryan Wu -
CONFIG_HOTPLUG was removed, so __devexit or __exit of remove()
should not be used.Signed-off-by: Jingoo Han
Signed-off-by: Bryan Wu -
CONFIG_HOTPLUG was removed, so __devexit or __exit of remove()
should not be used.Signed-off-by: Jingoo Han
Signed-off-by: Bryan Wu -
For better driver management, new subdirectory, 'trigger' is created.
All LED trigger drivers are moved into this directory.Internal header, 'leds.h' is included in each LED trigger drivers.
Fix the location of header file, "leds.h" -> "../leds.h" in driver files.
One exception is here, 'ledtrig-timer.c'.
There is no need to include 'leds.h'. so '#include "leds.h"' line was removed.Signed-off-by: Milo(Woogyom) Kim
Signed-off-by: Bryan Wu -
LP5562 can drive up to 4 channels, RGB and White.
LEDs can be controlled directly via the led class control interface.LP55xx common driver
LP5562 is one of LP55xx family device, so LP55xx common code are used.
On the other hand, chip specific configuration is defined in the structure
'lp55xx_device_config'LED pattern data
LP5562 has also internal program memory which is used for running various LED
patterns. LP5562 driver supports the firmware interface and the predefined
pattern data as well.LP5562 device attributes: 'led_pattern' and 'engine_mux'
A 'led_pattern' is an index code which runs the predefined pattern data.
And 'engine_mux' is updated with the firmware interface is activated.
Detailed description has been updated in the documentation files,
'leds-lp55xx.txt' and 'leds-lp5562.txt'.Changes on the header file
LP5562 configurable definitions are added.
Pattern RGB data is fixed as constant value.
(No side effect on other devices, LP5521 or LP5523.)(cooloney@gmail.com: remove redundant mutex_unlock(). Reported by Dan
Carpenter )Signed-off-by: Milo(Woogyom) Kim
Signed-off-by: Bryan Wu
27 Feb, 2013
1 commit
-
Pull LED subsystem update from Bryan Wu.
* 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds: (61 commits)
leds: leds-sunfire: use dev_err()/pr_err() instead of printk()
leds: 88pm860x: Add missing of_node_put()
leds: tca6507: Use of_get_child_count()
leds: leds-pwm: make it depend on PWM and not HAVE_PWM
Documentation: leds: update LP55xx family devices
leds-lp55xx: fix problem on removing LED attributes
leds-lp5521/5523: add author and copyright description
leds-lp5521/5523: use new lp55xx common header
leds-lp55xx: clean up headers
leds-lp55xx: clean up definitions
leds-lp55xx: clean up unused data and functions
leds-lp55xx: clean up _remove()
leds-lp55xx: add new function for removing device attribtues
leds-lp55xx: code refactoring on selftest function
leds-lp55xx: use common device attribute driver function
leds-lp55xx: support device specific attributes
leds-lp5523: use generic firmware interface
leds-lp5521: use generic firmware interface
leds-lp55xx: support firmware interface
leds-lp55xx: add new lp55xx_register_sysfs() for the firmware interface
...