aboutsummaryrefslogtreecommitdiff
path: root/drivers/leds
AgeCommit message (Collapse)Author
2013-09-12Merge branch 'for-next' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds Pull led updates from Bryan Wu: "Sorry for the late pull request, since I'm just back from vacation. LED subsystem updates for 3.12: - pca9633 driver DT supporting and pca9634 chip supporting - restore legacy device attributes for lp5521 - other fixing and updates" * 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds: (28 commits) leds: wm831x-status: Request a REG resource leds: trigger: ledtrig-backlight: Fix invalid memory access in fb_event notification callback leds-pca963x: Fix device tree parsing leds-pca9633: Rename to leds-pca963x leds-pca9633: Add mutex to the ledout register leds-pca9633: Unique naming of the LEDs leds-pca9633: Add support for PCA9634 leds: lp5562: use LP55xx common macros for device attributes Documentation: leds-lp5521,lp5523: update device attribute information leds: lp5523: remove unnecessary writing commands leds: lp5523: restore legacy device attributes leds: lp5523: LED MUX configuration on initializing leds: lp5523: make separate API for loading engine leds: lp5521: remove unnecessary writing commands leds: lp5521: restore legacy device attributes leds: lp55xx: add common macros for device attributes leds: lp55xx: add common data structure for program Documentation: leds: Fix a typo leds: ss4200: Fix incorrect placement of __initdata leds: clevo-mail: Fix incorrect placement of __initdata ...
2013-09-06Merge tag 'boards-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC board updates from Olof Johansson: "Board updates for 3.12. Again, a bit of domain overlap with SoC and DT branches, but most of this is around legacy code and board support. We've found that platform maintainers have a hard time separating all of these out and might move towards fewer branches for next release. - Removal of a number of Marvell Kirkwood board files, since contents is now common and mostly configured via DT. - Device-tree updates for Marvell Dove, including irqchip and clocksource setup. - Defconfig updates. Gotta go somewhere. One new one for Renesas Lager. - New backlight drivers for backlights used on Renesas shmobile platforms. - Removal of Renesas leds driver. - Shuffling of some of the new Broadcom platforms to give room for others in the same mach directory. More in 3.13" * tag 'boards-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (67 commits) mmc: sdhci-bcm-kona: Staticize sdhci_bcm_kona_card_event mmc: sdhci-bcm-kona: Remove unneeded version.h inclusion ARM: bcm: Make secure API call optional ARM: DT: binding fixup to align with vendor-prefixes.txt (drivers) ARM: mmc: fix NONREMOVABLE test in sdhci-bcm-kona ARM: bcm: Rename board_bcm mmc: sdhci-bcm-kona: make linker-section warning go away ARM: tegra: defconfig updates ARM: dove: add initial DT file for Globalscale D2Plug ARM: dove: add GPIO IR receiver node to SolidRun CuBox ARM: dove: add common pinmux functions to DT ARM: dove: add cpu device tree node ARM: dove: update dove_defconfig with SI5351, PCI, and xHCI arch/arm/mach-kirkwood: Avoid using ARRAY_AND_SIZE(e) as a function argument ARM: kirkwood: fix DT building and update defconfig ARM: kirkwood: Remove all remaining trace of DNS-320/325 platform code ARM: configs: disable DEBUG_LL in bcm_defconfig ARM: bcm281xx: Board specific reboot code ARM bcm281xx: Turn on socket & network support. ARM: bcm281xx: Turn on L2 cache. ...
2013-08-30leds: wm831x-status: Request a REG resourceMark Brown
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> Cc: stable@vger.kernel.org # v3.7+ Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-08-26leds: trigger: ledtrig-backlight: Fix invalid memory access in fb_event ↵Manfred Schlaegl
notification callback fb_notifier_callback is called on any event fired by fb_notifier_call_chain. Events may, or may not contain some data (fb_event.data). In case of FB_EVENT_BLANK fb_event.data contains a pointer to an integer holdingthe blank state. The Problem is, that in ledtrig-backlight.c - fb_notifier_callback the pointer to blank state is dereferenced BEFORE the event-type is checked. Obviously this leads to problems with other events than FB_EVENT_BLANK, where fb_event.data is undefined or NULL. It seems, that this problem existed ever since the driver was added. Like in drivers/video/backlight/backlight.c line 43 I would suggest to return immediately on events other than FB_EVENT_BLANK. Signed-off-by: Manfred Schlaegl <manfred.schlaegl@gmx.at> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-08-26leds-pca963x: Fix device tree parsingRicardo Ribalda Delgado
A malformed device tree could lead into a segmentation fault if the reg value of a led is bigger than the number of leds. A valid device tree could have only information about the last led of the chip. Fix the device tree parsing to handle those cases. Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-08-26leds-pca9633: Rename to leds-pca963xRicardo Ribalda Delgado
The driver now supports the chips pca9633 and pca9634, therefore we rename the files to more generic and meaningul names Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-08-26leds-pca9633: Add mutex to the ledout registerRicardo Ribalda Delgado
To update an LED a register has to be read, updated and writen. If another LED whas been updated at the same time, this could lead into wrong updates. This patch adds a common mutex to all the leds of the same chip to protect the ledout register. Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-08-26leds-pca9633: Unique naming of the LEDsRicardo Ribalda Delgado
If there is more than one pca963x chips on the system and there are some LEDs without platform_data names, the driver wont be able to provide unique naming to them. This will cause led_class_dev_register to fail, unregistering all the LEDs of the chip. This patch adds the i2c address to the name of the unnamed LEDs, making them unique. [ 555.346827] ------------[ cut here ]------------ [ 555.346844] WARNING: at /build/linux-voe0Su/linux-3.9.8/fs/sysfs/dir.c:536 sysfs_add_one+0x8b/0x9d() [ 555.346847] Hardware name: QT5022 [ 555.346850] sysfs: cannot create duplicate filename '/class/leds/pca9633:6' [ 555.346853] Modules linked in: qt5038_platform(O+) leds_pca9633(O) hid_generic ledtrig_default_on rfcomm bnep bluetooth binfmt_misc nfsd auth_rpcgss nfs_acl nfs lockd dns_resolver fscache sunrpc nls_utf8 nls_cp437 vfat fat loop fuse joydev hid_multitouch usbhid hid acpi_cpufreq mperf kvm_amd kvm evdev pn533 nfc arc4 microcode pcspkr efivars k10temp ath9k ath9k_common ath9k_hw ath fglrx(PO) mac80211 cfg80211 video rfkill processor thermal_sys sp5100_tco button i2c_piix4 ext4 crc16 jbd2 mbcache sg sd_mod crc_t10dif ahci libahci igb i2c_algo_bit i2c_core dca ptp pps_core ehci_pci ohci_hcd ehci_hcd libata usbcore usb_common scsi_mod [last unloaded: leds_pca963x] [ 555.346940] Pid: 4766, comm: insmod Tainted: P W O 3.9-1-amd64 #1 Debian 3.9.8-1 [ 555.346943] Call Trace: [ 555.346956] [<ffffffff8103d153>] ? warn_slowpath_common+0x76/0x8c [ 555.346962] [<ffffffff8103d202>] ? warn_slowpath_fmt+0x47/0x49 [ 555.346968] [<ffffffff8116005d>] ? sysfs_pathname+0x3b/0x41 [ 555.346973] [<ffffffff81160767>] ? sysfs_add_one+0x8b/0x9d [ 555.346978] [<ffffffff811610a4>] ? sysfs_do_create_link_sd+0xe8/0x174 [ 555.346985] [<ffffffff81279250>] ? device_add+0x243/0x5ab [ 555.346991] [<ffffffff81060a16>] ? complete_all+0x31/0x40 [ 555.346998] [<ffffffff8104991a>] ? init_timer_key+0xc/0x56 [ 555.347004] [<ffffffff8127964c>] ? device_create_vargs+0x82/0xb6 [ 555.347009] [<ffffffff812796af>] ? device_create+0x2f/0x31 [ 555.347014] [<ffffffff81060add>] ? should_resched+0x5/0x23 [ 555.347021] [<ffffffff812a3a92>] ? led_classdev_register+0x24/0x103 [ 555.347028] [<ffffffffa09d01c0>] ? pca9633_probe+0x173/0x239 [leds_pca9633] [ 555.347035] [<ffffffff8127b504>] ? __driver_attach+0x73/0x73 [ 555.347049] [<ffffffffa009dfc9>] ? i2c_device_probe+0x63/0x88 [i2c_core] [ 555.347057] [<ffffffff8127b373>] ? driver_probe_device+0x92/0x1b0 [ 555.347064] [<ffffffff81279c5c>] ? bus_for_each_drv+0x43/0x7d [ 555.347070] [<ffffffff8127b2af>] ? device_attach+0x68/0x83 [ 555.347078] [<ffffffff8127a990>] ? bus_probe_device+0x25/0x8d [ 555.347083] [<ffffffff812793f7>] ? device_add+0x3ea/0x5ab [ 555.347088] [<ffffffff81060a16>] ? complete_all+0x31/0x40 [ 555.347094] [<ffffffff8104991a>] ? init_timer_key+0xc/0x56 [ 555.347104] [<ffffffffa009d3a1>] ? i2c_new_device+0x10d/0x179 [i2c_core] [ 555.347112] [<ffffffffa008f036>] ? qt5038_init+0x36/0x1000 [qt5038_platform] [ 555.347119] [<ffffffffa008f000>] ? 0xffffffffa008efff [ 555.347125] [<ffffffff8100209e>] ? do_one_initcall+0x74/0x128 [ 555.347131] [<ffffffffa008f000>] ? 0xffffffffa008efff [ 555.347137] [<ffffffff810836f5>] ? load_module+0x1af7/0x1dfc [ 555.347144] [<ffffffff810801c5>] ? free_notes_attrs+0x3c/0x3c [ 555.347150] [<ffffffff81083a98>] ? sys_init_module+0x9e/0xab [ 555.347157] [<ffffffff8138be29>] ? system_call_fastpath+0x16/0x1b [ 555.347161] ---[ end trace ad00b85794e0de4d ]--- [ 555.347448] leds-pca9633: probe of 0-006b failed with error -17 Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-08-26leds-pca9633: Add support for PCA9634Ricardo Ribalda Delgado
Add support for PCA9634 chip, which belongs to the same family as the 9633 but with support for 8 outputs instead of 4. Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-08-26leds: lp5562: use LP55xx common macros for device attributesMilo Kim
Signed-off-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-08-26leds: lp5523: remove unnecessary writing commandsMilo Kim
This patch reduces the number of programming commands. (Count of sending commands) Old code: 32 + program size (32 counts for clearing program memory) New code: 32 Pattern buffer is initialized to 0 in this function. Just update new program data and remaining buffers are filled with 0. So it's needless to clear whole area. Signed-off-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-08-26leds: lp5523: restore legacy device attributesMilo Kim
git commit db6eaf8388a413a5ee1b4547ce78506b9c6456b0 (leds-lp5523: use generic firmware interface) causes an application conflict. This interface should be maintained for compatibility. Restored device attributes are 'engineN_mode', 'engineN_load' and 'engineN_leds'. (N = 1, 2 or 3) A 'selftest' attribute macro is replaced with LP55xx common macro. Those are accessed when a LED pattern is run by an application. Use a mutex in lp5523_update_program_memory() : This function is called when an user-application writes a 'engineN_load' file or pattern data is loaded from generic firmware interface. So, writing program memory should be protected. If an error occurs on accessing this area, just it returns as -EINVAL quickly. This error code is exact same as old driver function, lp5523_do_store_load() because it should be kept for an user-application compatibility. Even the driver is changed, we can use the application without re-compiling sources. Reported-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-08-26leds: lp5523: LED MUX configuration on initializingMilo Kim
LED MUX start and stop address should be updated in the program memory on LP5523 initialization. LED pattern doesn't work without additional MUX address configuration. This handling is done by new function, lp5523_init_program_engine(). Eventually, it's called during device initialization, lp5523_post_init_device(). This is a conflict after git commit 632418bf65503405df3f9a6a1616f5a95f91db85 (leds-lp5523: clean up lp5523_configure()). So it should be fixed. Cc: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-08-26leds: lp5523: make separate API for loading engineMilo Kim
lp5523_load_engine() It is called whenever the operation mode is changed to 'load'. It is used for simple operation mode change. It will be used when engine mode and LED selection is updated in later patch. lp5523_load_engine_and_select_page() Change the operation mode to 'load' and select program page number. This is used for programming a LED pattern at a time. So load_engine() is replaced with new API, load_engine_and_select_page() in lp5523_firmware_loaded(). Signed-off-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-08-26leds: lp5521: remove unnecessary writing commandsMilo Kim
This patch reduces the number of programming commands. (Count of sending commands) Old code: 32 + program size (32 counts for clearing program memory) New code: 32 Pattern buffer is initialized to 0 in this function. Just update new program data and remaining buffers are filled with 0. So it's needless to clear whole area. Signed-off-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-08-26leds: lp5521: restore legacy device attributesMilo Kim
git commit 9ce7cb170f97f83a78dc948bf7d25690f15e1328 may cause an application confict, engineN_mode and engineN_load. This interface should be maintained for compatibility. Restored device attributes are 'engineN_mode' and 'engineN_load'. A 'selftest' attribute macro is replaced with LP55xx common macro. Use a mutex in lp5521_update_program_memory() : This function is called when an user-application writes a 'engineN_load' file or pattern data is loaded from generic firmware interface. So, writing program memory should be protected. If an error occurs on accessing this area, just it returns as -EINVAL quickly. This error code is exact same as old driver function, lp5521_do_store_load() because it should be kept for an user-application compatibility. Even the driver is changed, we can use the application without re-compiling sources. 'led_pattern' attribute is not included : engineN_mode and _load were created for custom user-application. 'led_pattern' is an exception. I added this attribute not for custom application but for simple test. Now it is used only in LP5562 driver, not LP5521. Signed-off-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-08-26leds: lp55xx: add common macros for device attributesMilo Kim
This patch provides common macros for LP5521 and LP5523 device attributes and functions. (Device attributes) LP5521: 'mode', 'load' and 'selftest' LP5523: 'mode', 'load', 'leds' and 'selftest' (Permissions) mode: R/W load: Write-only leds: R/W selftest: Read-only Couple of lines are duplicate, so use these macros for adding device attributes in LP5521 and LP5523 drivers. Signed-off-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-08-26leds: lp55xx: add common data structure for programMilo Kim
LP55xx family devices have internal three program engines which are used for loading LED patterns. To maintain legacy device attributes, specific data structure is used, 'mode' and 'led_mux'. The mode is used for showing/storing current engine mode such like disabled, load and run. Then led_mux is used for showing/storing current output LED selection. This is only for LP5523/55231. Signed-off-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-08-26leds: ss4200: Fix incorrect placement of __initdataSachin Kamat
__initdata should be placed between the variable name and equal sign for the variable to be placed in the intended section. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Cc: Dave Hansen <dave@sr71.net> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-08-26leds: clevo-mail: Fix incorrect placement of __initdataSachin Kamat
__initdata should be placed between the variable name and equal sign for the variable to be placed in the intended section. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Cc: Márton Németh <nm127@freemail.hu> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-08-26leds: leds-netxbig: depends on ARCH_KIRKWOODSimon Guinot
With the DT conversion, the board Kconfig symbols MACH_ are going to be removed. In order to prepare this removal, this patch replaces alls the machines dependencies for leds-netxbig by ARCH_KIRKWOOD. Signed-off-by: Simon Guinot <simon.guinot@sequanux.org> Acked-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-08-26leds: leds-ns2: depends on ARCH_KIRKWOODSimon Guinot
With the DT conversion, the board Kconfig symbols MACH_ are going to be removed. In order to prepare this removal, this patch replaces alls the machines dependencies for leds-ns2 by ARCH_KIRKWOOD. Signed-off-by: Simon Guinot <simon.guinot@sequanux.org> Acked-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-08-26leds: leds-lp3944, fix "sparse" warning "mixing different enum types"Antonio Ospite
Fix a warning from "sparse": drivers/leds/leds-lp3944.c:292:23: warning: mixing different enum types drivers/leds/leds-lp3944.c:292:23: int enum led_brightness versus drivers/leds/leds-lp3944.c:292:23: int enum lp3944_status Keeping track of LP3944_LED_STATUS_OFF and LP3944_LED_STATUS_ON only in lp3944_led_set_brightness() is OK, as the handling of DIM (blinking) mode[s] is in lp3944_led_set_blink(). Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Reviewed-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-08-26leds: leds-ss4200: Staticize nasgpio_led_get_attr()Jingoo Han
nasgpio_led_get_attr() is used only in this file. Fix the following sparse warning: drivers/leds/leds-ss4200.c:200:5: warning: symbol 'nasgpio_led_get_attr' was not declared. Should it be static? Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-08-26leds: use dev_get_platdata()Jingoo Han
Use the wrapper function for retrieving the platform data instead of accessing dev->platform_data directly. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-08-26leds: pca9633: Add hardware blink supportMark A. Greer
Add hardware blinking support to the pca9633 driver. NOTE: Hardware blinking violates the leds infrastructure driver interface since the hardware only supports blinking all LEDs with the same delay_on/delay_off rates. That is, only the LEDs that are set to blink will actually blink but all LEDs that are set to blink will blink in identical fashion. The delay_on/delay_off values of the last LED that is set to blink will be used for all of the blinking LEDs. If the hardware doesn't support the requested blinking pattern, a default of 500ms on and off will be used. Hardware blinking is disabled by default but can be enabled by setting the 'blink_type' member in the platform_data struct to 'PCA9633_HW_BLINK' or by adding the 'nxp,hw-blink' property to the DTS. (fengguang.wu@intel.com: Removes unneeded semicolon.) Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Reported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-08-26leds: support new LP8501 device - another LP55xx commonKim, Milo
LP8501 can drive up to 9 channels like LP5523. LEDs can be controlled directly via the I2C and programmable engines are supported. LP55xx common driver LP8501 is one of LP55xx family device, so LP55xx common code are used. Chip specific data is defined in the structure, 'lp55xx_device_config'. Differences between LP8501 and LP5523 Different register layout for LED output control and others. LP8501 specific feature for separate output power selection. LP8501 doesn't support external clock detection. Different programming engine data. LP8501 specific feature - output power selection Output channels are selected by power selection - Vout or Vdd. Separate power for VDD1-6 and VDD7-9 are available. It is configurable in the platform data. To support this feature, LP55xx DT structure and header are changed. Device tree binding is updated as well. LED pattern data Example pattern data is updated in the driver documentation. Signed-off-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-08-26leds: Add device tree binding for pca9633Tony Lindgren
Similar to tca6507, we can just parse the standard LED properties for pca9633. Tested on a pca9632, which is compatible with pca9633. Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-07-26leds: convert class code to use dev_groupsGreg Kroah-Hartman
The dev_attrs field of struct class is going away soon, dev_groups should be used instead. This converts the led class code to use the correct field. Acked-by: Bryan Wu <cooloney@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-22leds: Remove leds-renesas-tpu driverLaurent Pinchart
The driver is superseded by the generic pwm-renesas-tpu driver used with leds-pwm. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Bryan Wu <cooloney@gmail.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2013-07-02leds: mc13783: Fix "uninitialized variable" warningAlexander Shiyan
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 <shc_work@mail.ru> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-06-20leds: Convert led class driver from legacy pm ops to dev_pm_opsShuah Khan
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 <shuah.kh@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-06-20leds: leds-mc13783: Add MC13892 LED supportAlexander Shiyan
Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Tested-by: Philippe Retornaz <philippe.retornaz@epfl.ch> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-06-20leds: leds-mc13783: Prepare driver to support MC13892 LEDsAlexander Shiyan
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 <shc_work@mail.ru> Tested-by: Philippe Retornaz <philippe.retornaz@epfl.ch> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-06-20leds: renesas-tpu: cleanup a small type issueDan Carpenter
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 <dan.carpenter@oracle.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-06-20leds: use platform_{get,set}_drvdata()Jingoo Han
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 <jg1.han@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-06-20leds: leds-gpio: Let device core handle pinctrlFabio Estevam
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 <warren@wwwdotorg.org> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-06-20leds: lp5562: Properly setup of_device_id tableAxel Lin
Don't mix of_device_id entry in i2c_device_id table. Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-06-20leds: lp5523: Properly setup of_device_id tableAxel Lin
Don't mix of_device_id entry in i2c_device_id table. Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-06-20leds: lp5521: Properly setup of_device_id tableAxel Lin
Don't mix of_device_id entry in i2c_device_id table. Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-06-20leds: lp5562: support the device tree featureKim, Milo
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 <gabriel.fernandez@stericsson.com> Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-06-20leds: lp55xx: support dynamic channel settings in the device tree structureKim, Milo
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 <gabriel.fernandez@stericsson.com> Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-06-20leds: leds-ns2: remove unnecessary platform_set_drvdata()Jingoo Han
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 <jg1.han@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-06-20leds: leds-mc13783: remove unnecessary platform_set_drvdata()Jingoo Han
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 <jg1.han@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-06-20leds: leds-gpio: remove unnecessary platform_set_drvdata()Jingoo Han
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 <jg1.han@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-06-20leds: atmel-pwm: remove unnecessary platform_set_drvdata()Jingoo Han
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 <jg1.han@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-06-20leds: lp55xx: add support for Device Tree bindingsLinus Walleij
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 <gabriel.fernandez@stericsson.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-05-24drivers/leds/leds-ot200.c: fix error caused by shifted maskChristian Gmeiner
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>
2013-05-21leds: leds-gpio: reserve gpio before using itTimo Teräs
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>
2013-05-09Merge tag 'gpio-for-linus' of git://git.secretlab.ca/git/linuxLinus Torvalds
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