aboutsummaryrefslogtreecommitdiff
path: root/drivers/leds
AgeCommit message (Collapse)Author
2014-01-28Merge branch 'for-next' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds Pull LED subsystem update from Bryan Wu: "Basically this cycle is mostly cleanup for LED subsystem" * 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds: leds: s3c24xx: Remove hardware.h inclusion leds: replace list_for_each with list_for_each_entry leds: kirkwood: Cleanup in header files leds: pwm: Remove a warning on non-DT platforms leds: leds-pwm: fix duty time overflow. leds: leds-mc13783: Remove unneeded mc13xxx_{un}lock leds: leds-mc13783: Remove duplicate field in platform data drivers: leds: leds-tca6507: check CONFIG_GPIOLIB whether defined for 'gpio_base' leds: lp5523: Support LED MUX configuration on running a pattern leds: lp5521/5523: Fix multiple engine usage bug LEDS: tca6507 - fix up some comments. LEDS: tca6507: add device-tree support for GPIO configuration. LEDS: tca6507 - fix bugs in parsing of device-tree configuration.
2014-01-27leds: s3c24xx: Remove hardware.h inclusionSachin Kamat
The contents of this header file is not referenced in the led driver. Remove its inclusion. While at it, re-arrange the headers as per the category. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2014-01-27leds: replace list_for_each with list_for_each_entryZHAO Gang
Use the more convenient macro. Signed-off-by: ZHAO Gang <gamerh2o@gmail.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2014-01-27leds: pwm: Remove a warning on non-DT platformsOlof Johansson
This removes a warning on non-DT-enabled platforms: drivers/leds/leds-pwm.c: In function 'led_pwm_create_of': drivers/leds/leds-pwm.c:88:22: warning: unused variable 'node' Really caused by the local variable that is assigned to and then never used. Just do away with the local var, it's not needed. Technically this code path can never be entered without DT enabled, since there's an earlier check about number of children in the calling function, but the compiler can't see that. Signed-off-by: Olof Johansson <olof@lixom.net> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2014-01-27leds: leds-pwm: fix duty time overflow.Xiubo Li
Overflow maybe occurs when calculates the duty time. For instance, the period time is 990000000ns, and the max_brightness is 127, when setting the brightness to 12, the duty value will be 25906026ns, but it should be 93543307ns. Signed-off-by: Bryan Wu <cooloney@gmail.com>
2014-01-27leds: leds-mc13783: Remove unneeded mc13xxx_{un}lockAlexander Shiyan
LED registers are used only in this driver, so no additional locking is needed. Read-Modify-Write cycle in workqueue is already protected by regmap. Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2014-01-27leds: leds-mc13783: Remove duplicate field in platform dataAlexander Shiyan
LED platform data are overwhelmed by excessive field "max_cur" which just replicates few bits of "led_control" field. This patch removes this field and adds a definition for the current settings in the header. Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2014-01-27drivers: leds: leds-tca6507: check CONFIG_GPIOLIB whether defined for ↵Chen Gang
'gpio_base' Need check CONFIG_GPIOLIB whether defined, just like another area has done within this file. Or can not pass compiling when CONFIG_GPIOLIB disabled. The related error (with allmodconfig for metag): CC [M] drivers/leds/leds-tca6507.o drivers/leds/leds-tca6507.c: In function 'tca6507_led_dt_init': drivers/leds/leds-tca6507.c:731: error: 'struct tca6507_platform_data' has no member named 'gpio_base' Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2014-01-27leds: lp5523: Support LED MUX configuration on running a patternMilo Kim
There are two ways to run a pattern in LP5523. One is using legacy sysfs files such as 'enginex_mode','enginex_load' and 'enginex_leds'. ('x' is from 1 to 3). Among them, 'enginex_leds' are used for selecting specific LED channel MUX. (MUX means which LEDs are used for running a pattern from LED 1 to 9.) The other way is using the firmware interface. In this mode, the default LED MUX strings are used. In other words, LED MUX is not configurable on the fly. This patch enables dynamic LED MUX configuration when the firmware is loaded. By accessing the sysfs file 'enginex_leds', the LED channels can be configured. To synchronize the operation mode, each engine mode should be set to 'LOAD'. The documentation is updated as well. 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>
2014-01-27leds: lp5521/5523: Fix multiple engine usage bugMilo Kim
Whenever the engine is loaded by the user-application, the operation mode is reset first. But it has a problem in case of multiple engine used because previous engine settings are cleared. The driver should update not whole 8bits but each engine bit by masking. On the other hands, whole engines should be reset when the driver is unloaded and on initializing the LP5523 driver. So, new functions are used for this handling - lp5521/5523_stop_all_engines(). 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>
2014-01-27LEDS: tca6507 - fix up some comments.NeilBrown
In particular fix the capitalisation of GPIO and LED and correct TCA6507_MAKE_CPIO, but also rewrite the comment about platform-data to include reference to devicetree. Also re-wrap comments to fit 80 columns. Reported-by: Bryan Wu <cooloney@gmail.com> Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2014-01-27LEDS: tca6507: add device-tree support for GPIO configuration.NeilBrown
The 7 lines driven by the TCA6507 can either drive LEDs or act as output-only GPIOs. To make this distinction in devicetree we use the "compatible" property. If the device attached to a line is "compatible" with "gpio", we treat it like a GPIO. If it is "compatible" with "led" (or if no "compatible" value is set) we treat it like an LED. (cooloney@gmail.com: fix typo in the subject) Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2014-01-27LEDS: tca6507 - fix bugs in parsing of device-tree configuration.NeilBrown
1/ The led_info array must be allocated to allow the full number of LEDs even if not all are present. The array maybe be sparsely filled but it is indexed by device address so we must at least allocate as many slots as the highest address used. It is easiest just to allocate all 7. 2/ range check the 'reg' value properly. 3/ led.flags must be initialised to zero, else all leds could be treated as GPIOs (depending on what happens to be on the stack). Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2014-01-22Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial Pull trivial tree updates from Jiri Kosina: "Usual rocket science stuff from trivial.git" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (39 commits) neighbour.h: fix comment sched: Fix warning on make htmldocs caused by wait.h slab: struct kmem_cache is protected by slab_mutex doc: Fix typo in USB Gadget Documentation of/Kconfig: Spelling s/one/once/ mkregtable: Fix sscanf handling lp5523, lp8501: comment improvements thermal: rcar: comment spelling treewide: fix comments and printk msgs IXP4xx: remove '1 &&' from a condition check in ixp4xx_restart() Documentation: update /proc/uptime field description Documentation: Fix size parameter for snprintf arm: fix comment header and macro name asm-generic: uaccess: Spelling s/a ny/any/ mtd: onenand: fix comment header doc: driver-model/platform.txt: fix a typo drivers: fix typo in DEVTMPFS_MOUNT Kconfig help text doc: Fix typo (acces_process_vm -> access_process_vm) treewide: Fix typos in printk drivers/gpu/drm/qxl/Kconfig: reformat the help text ...
2014-01-21Merge tag 'gpio-v3.14-1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO tree bulk changes from Linus Walleij: "A big set this merge window, as we have much going on in this subsystem. The changes to other subsystems (notably a slew of ARM machines as I am doing away with their custom APIs) have all been ACKed to the extent possible. Major changes this time: - Some core improvements and cleanups to the new GPIO descriptor API. This seems to be working now so we can start the exodus to this API, moving gradually away from the global GPIO numberspace. - Incremental improvements to the ACPI GPIO core, and move the few GPIO ACPI clients we have to the GPIO descriptor API right *now* before we go any further. We actually managed to contain this *before* we started to litter the kernel with yet another hackish global numberspace for the ACPI GPIOs, which is a big win. - The RFkill GPIO driver and all platforms using it have been migrated to use the GPIO descriptors rather than fixed number assignments. Tegra machine has been migrated as part of this. - New drivers for MOXA ART, Xtensa GPIO32 and SMSC SCH311x. Those should be really good examples of how I expect a nice GPIO driver to look these days. - Do away with custom GPIO implementations on a major part of the ARM machines: ks8695, lpc32xx, mv78xx0. Make a first step towards the same in the horribly convoluted Samsung S3C include forest. We expect to continue to clean this up as we move forward. - Flag GPIO lines used for IRQ on adnp, bcm-kona, em, intel-mid and lynxpoint. This makes the GPIOlib core aware that a certain GPIO line is used for IRQs and can then enforce some semantics such as disallowing a GPIO line marked as in use for IRQ to be switched to output mode. - Drop all use of irq_set_chip_and_handler_name(). The name provided in these cases were just unhelpful tags like "mux" or "demux". - Extend the MCP23s08 driver to handle interrupts. - Minor incremental improvements for rcar, lynxpoint, em 74x164 and msm drivers. - Some non-urgent bug fixes here and there, duplicate #includes and that usual kind of cleanups" Fix up broken Kconfig file manually to make this all compile. * tag 'gpio-v3.14-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (71 commits) gpio: mcp23s08: fix casting caused build warning gpio: mcp23s08: depend on OF_GPIO gpio: mcp23s08: Add irq functionality for i2c chips ARM: S5P[v210|c100|64x0]: Fix build error gpio: pxa: clamp gpio get value to [0,1] ARM: s3c24xx: explicit dependency on <plat/gpio-cfg.h> ARM: S3C[24|64]xx: move includes back under <mach/> scope Documentation / ACPI: update to GPIO descriptor API gpio / ACPI: get rid of acpi_gpio.h gpio / ACPI: register to ACPI events automatically mmc: sdhci-acpi: convert to use GPIO descriptor API ARM: s3c24xx: fix build error gpio: f7188x: set can_sleep attribute gpio: samsung: Update documentation gpio: samsung: Remove hardware.h inclusion gpio: xtensa: depend on HAVE_XTENSA_GPIO32 gpio: clps711x: Enable driver compilation with COMPILE_TEST gpio: clps711x: Use of_match_ptr() net: rfkill: gpio: convert to descriptor-based GPIO interface leds: s3c24xx: Fix build failure ...
2014-01-10leds: lp5521/5523: Remove duplicate mutexMilo Kim
It can be a problem when a pattern is loaded via the firmware interface. LP55xx common driver has already locked the mutex in 'lp55xx_firmware_loaded()'. So it should be deleted. On the other hand, locks are required in store_engine_load() on updating program memory. Reported-by: Pali Rohár <pali.rohar@gmail.com> Reported-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com> Cc: <stable@vger.kernel.org>
2014-01-10lp5523, lp8501: comment improvementsPavel Machek
Add some comments that are not obvious from first look at the driver to lp5523, fix typo in lp8501. Signed-off-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-01-07leds: s3c24xx: Fix build failureTushar Behera
Commit c67d0f29262b ("ARM: s3c24xx: get rid of custom <mach/gpio.h>") removed the usage of mach/gpio.h file, but we need to include> plat/gpio-cfg.h to avoid following build error. Fixes following build error. drivers/leds/leds-s3c24xx.c: In function ‘s3c24xx_led_probe’: drivers/leds/leds-s3c24xx.c:100:2: error: implicit declaration of function ‘s3c_gpio_setpull’ [-Werror=implicit-function-declaration] Signed-off-by: Tushar Behera <tushar.behera@linaro.org> Acked-by: Bryan Wu <cooloney@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-12-02leds: pwm: Fix for deferred probe in DT booted modePeter Ujfalusi
We need to make sure that the error code from devm_of_pwm_get() is the one the module returns in case of failure. Restructure the code to make this possible for DT booted case. With this patch the driver can ask for deferred probing when the board is booted with DT. Fixes for example omap4-sdp board's keyboard backlight led. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-10-25leds: lp55xx: handle enable pin in driverSebastian Reichel
This patch moves the handling of the chip's enable pin from the board code into the driver. It also updates all board-code files using the driver to incorporate this change. This is needed for device tree support of the enable pin. Signed-off-by: Sebastian Reichel <sre@debian.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-10-25leds-gpio: of: led should not be created if its status is disabledJosh Wu
now the leds-gpio driver will create every child led node without checking the status is disabled or not. for example, if we have a led node like d3, and its status is disabled: leds { d3 { label = "d3"; gpios = <&pioE 24 0>; status = "disabled"; }; }; we except the d3 should not be created. And the gpios should not be request as well. But current driver will create d3 and request its gpio. This patch fix this by using for_each_available_child_of_node() and of_get_available_child_count() to enumerate all child nodes. So the disabled node will be inavailable. Signed-off-by: Josh Wu <josh.wu@atmel.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-10-22leds: Added driver for the NXP PCA9685 I2C chipMaximilian Güntner
The NXP PCA9685 supports 16 channels/leds using a 12-bit PWM (4095 levels of brightness) This driver supports configuration using platform_data. Signed-off-by: Maximilian Güntner <maximilian.guentner@gmail.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-10-22leds: pwm: Remove redundant of_match_ptrSachin Kamat
The data structure of_match_ptr() protects is always compiled in. Hence of_match_ptr() is not needed. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-10-22leds: Include linux/of.h headerSachin Kamat
'of_match_ptr' is defined in linux/of.h. Include it explicitly. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-10-22leds: dac124s085: Remove redundant spi_set_drvdataSachin Kamat
Driver core sets driver data to NULL upon failure or remove. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Cc: Guennadi Liakhovetski <lg@denx.de> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-10-22leds: lp55xx: enable setting default triggerLinus Walleij
This enables setting a default trigger on an LP55xx channel, either from platform data or device tree. This mechanism is identical to the mechanism for GPIO LEDs and references the common LEDs device tree bindings. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Milo Kim <milo.kim@ti.com> Acked-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-10-22leds: blinkm: Remove redundant breakSachin Kamat
'break' after return is redundant. Remove it. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Acked-by: Jan-Simon Möller <dl9pf@gmx.de> Signed-off-by: Bryan Wu <cooloney@gmail.com>
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>