summaryrefslogtreecommitdiffstats
path: root/drivers/leds
AgeCommit message (Collapse)AuthorFilesLines
2017-05-22leds: pca955x: Correct I2C FunctionalityTin Huynh1-1/+1
The driver checks an incorrect flag of functionality of adapter. When a driver requires i2c_smbus_read_byte_data and i2c_smbus_write_byte_data, it should check I2C_FUNC_SMBUS_BYTE_DATA instead I2C_FUNC_I2C. This patch fixes the problem. Signed-off-by: Tin Huynh <tnhuynh@apm.com> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-05-08scripts/spelling.txt: add "memory" pattern and fix typosStephen Boyd3-3/+3
Fix typos and add the following to the scripts/spelling.txt: momery||memory Link: http://lkml.kernel.org/r/20170317011131.6881-1-sboyd@codeaurora.org Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-04-19leds: pca9532: Extend pca9532 device tree supportFelix Brack1-1/+26
This patch extends the device tree support for the pca9532 by adding the leds 'default-state' property. Signed-off-by: Felix Brack <fb@ltec.ch> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-03-29leds: cpcap: new driverSebastian Reichel3-0/+249
Motorola CPCAP is a PMIC (power management integrated circuit) found in multiple smartphones. This driver adds support for the chip's LED controllers. This introduces support for all controllers used by the Droid 4. According to Motorola's driver (no datasheets available) there a couple of more LED controllers. I did not add support for them, since I cannot verify that they work with my modifications. Signed-off-by: Sebastian Reichel <sre@kernel.org> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-03-23leds: lp3952: Use 'if (ret)' patternAndy Shevchenko1-3/+4
Instead of unusual "if (!ret)" use "if (ret)" in lp3952_get_label(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-03-23leds: lp3952: Remove ACPI support for lp3952Andy Shevchenko2-12/+0
In ACPI world any ID should be carefully chosen and registered officially. The discussion [1] as I read it gets to wilful assignment an ID for non-existing real DSDT example. Rafael already told [2] how this device would be enumerated using compatible string. To be more precise look at the possible DSDT excerpt below: Device (LDX0) { Name (_HID, "PRP0001") Name (_DDN, "TI LP3952 compatible led driver") ... }) Name (_DSD, Package () { ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () {"compatible", "ti,lp3952"}, ... } }) Based on above, remove non-official ACPI IDs and enumeration from the driver. Note: currently driver has no compatible strings at all, to make above working one should add at least one. [1] https://e2e.ti.com/support/power_management/led_driver/f/192/t/524926 [2] https://www.spinics.net/lists/linux-acpi/msg67125.html Cc: Tony Makkiel <tony.makkiel@daqri.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-03-23leds: mt6323: Fix an off by one bug in probeDan Carpenter1-1/+1
It should be ">= MT6323_MAX_LEDS" instead of ">". Also "reg" is a u32 so it can't be negative and we can remove the test for negative values. Fixes: 216ec6cc4c19 ("leds: Add LED support for MT6323 PMIC") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-03-21leds: Add LED support for MT6323 PMICSean Wang3-0/+511
MT6323 PMIC is a multi-function device that includes LED function. It allows attaching up to 4 LEDs which can either be on, off or dimmed and/or blinked with the controller. Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-03-08leds: gpio: use OF variant of LED registering functionRafał Miłecki1-6/+6
In leds-gpio we support LEDs specified in DT so we should use (devm_)of_led_classdev_register. This allows passing DT node as argument for use by the LED subsystem. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-03-08leds: core: add OF variants of LED registering functionsRafał Miłecki1-10/+16
These new functions allow passing an additional device_node argument that will be internally set for created LED device. Thanks to this LED core code and triggers will be able to access DT node for reading extra info. The easiest solution for achieving this was reworking old functions to more generic ones & adding simple defines for API compatibility. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-03-06dell-led: move driver to drivers/platform/x86/dell-wmi-led.cMichał Kępień3-211/+0
The dell-led driver handles a specific WMI GUID present on some Dell laptops and as such it belongs in the x86 platform driver subsystem. Source code is moved along with the relevant Kconfig and Makefile entries, with some minor modifications: - Kconfig option is renamed from CONFIG_LEDS_DELL_NETBOOKS to CONFIG_DELL_WMI_LED, - the X86 Kconfig dependency is removed as the whole drivers/platform/x86 menu depends on it, so there is no need to duplicate it, - the name of the module's source file is removed from the header comment to avoid the need to update it in the future. Signed-off-by: Michał Kępień <kernel@kempniu.pl> Tested-by: Alex Hung <alex.hung@canonical.com> Reviewed-by: Pali Rohár <pali.rohar@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-03-06dell-led: remove code related to mic mute LEDMichał Kępień2-19/+7
With dell_micmute_led_set() moved to drivers/platform/x86/dell-laptop.c, all remnants of the mic mute LED handling code can be removed from drivers/leds/dell-led.c, restoring it back to the state it was in before commit db6d8cc00773 ("dell-led: add mic mute led interface"). Signed-off-by: Michał Kępień <kernel@kempniu.pl> Tested-by: Alex Hung <alex.hung@canonical.com> Reviewed-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-03-06platform/x86: dell-laptop: import dell_micmute_led_set() from ↵Michał Kępień1-29/+0
drivers/leds/dell-led.c To ensure all users of dell-smbios are in drivers/platform/x86, move the dell_micmute_led_set() method from drivers/leds/dell-led.c to drivers/platform/x86/dell-laptop.c. Signed-off-by: Michał Kępień <kernel@kempniu.pl> Tested-by: Alex Hung <alex.hung@canonical.com> Reviewed-by: Pali Rohár <pali.rohar@gmail.com> Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-03-06ALSA: hda - use dell_micmute_led_set() instead of dell_app_wmi_led_set()Michał Kępień1-18/+2
The dell_app_wmi_led_set() method introduced in commit db6d8cc00773 ("dell-led: add mic mute led interface") was implemented as an easily extensible entry point for other modules to set the state of various LEDs. However, almost three years later it is still only used to control the mic mute LED, so it will be replaced with direct calls to dell_micmute_led_set(). Signed-off-by: Michał Kępień <kernel@kempniu.pl> Tested-by: Alex Hung <alex.hung@canonical.com> Reviewed-by: Pali Rohár <pali.rohar@gmail.com> Acked-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-03-06dell-led: remove GUID check from dell_micmute_led_set()Michał Kępień1-3/+0
As dell_micmute_led_set() no longer uses the dell_wmi_perform_query() method, which was removed in commit 0c41a08e131d ("dell-led: use dell_smbios_send_request() for performing SMBIOS calls"), the DELL_APP_GUID check is redundant and thus can be safely removed. Signed-off-by: Michał Kępień <kernel@kempniu.pl> Tested-by: Alex Hung <alex.hung@canonical.com> Reviewed-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-03-06leds/trigger/cpu: Add LED trigger for all CPUs aggregatedPaulo Costa1-2/+31
Currently there is one CPU led trigger per cpu ('cpu0', 'cpu1', ...) This patch adds a new trigger, 'cpu', with brightness proportional to the number of active CPUs. If multiple brightness levels aren't supported on the LED, it effectively indicates if there is any CPU active. This is particularly useful on tiny linux boards with more CPU cores than LED pins. Signed-off-by: Paulo Costa <me@paulo.costa.nom.br> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-03-02sched/headers: Prepare for new header dependencies before moving code to ↵Ingo Molnar1-0/+1
<linux/sched/loadavg.h> We are going to split <linux/sched/loadavg.h> out of <linux/sched.h>, which will have to be picked up from a couple of .c files. Create a trivial placeholder <linux/sched/topology.h> file that just maps to <linux/sched.h> to make this patch obviously correct and bisectable. Include the new header in the files that are going to need it. Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-03-01Merge tag 'pwm/for-4.11-rc1' of ↵Linus Torvalds1-13/+3
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm Pull pwm updates from Thierry Reding: "This set contains mostly fixes to existing drivers as well as cleanup of code that's not been in active use for a while" * tag 'pwm/for-4.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (27 commits) acpi: lpss: call pwm_add_table() for BSW PWM device pwm: Try to load modules during pwm_get() pwm: Don't hold pwm_lookup_lock longer than necessary pwm: Make the PWM_POLARITY flag in DTB optional pwm: Print error messages with pr_err() instead of pr_debug() pwm: imx: Add polarity inversion support to i.MX's PWMv2 pwm: imx: doc: Update imx-pwm.txt documentation entry pwm: imx: Remove redundant i.MX PWMv2 code pwm: imx: Provide atomic PWM support for i.MX PWMv2 pwm: imx: Move PWMv2 wait for fifo slot code to a separate function pwm: imx: Move PWMv2 software reset code to a separate function pwm: imx: Rewrite v1 code to facilitate switch to atomic PWM pwm: imx: Add separate set of PWM ops for v1 and v2 pwm: imx: Remove ipg clock and enable per clock when required pwm: lpss: Add Intel Gemini Lake PCI ID pwm: lpss: Do not export board infos for different PWM types pwm: lpss: Avoid reconfiguring while UPDATE bit is still enabled pwm: lpss: Switch to new atomic API pwm: lpss: Allow duty cycle to be 0 pwm: lpss: Avoid potential overflow of base_unit ...
2017-02-23Merge tag 'gpio-v4.11-1' of ↵Linus Torvalds1-6/+8
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO updates from Linus Walleij: "This is the bulk of GPIO changes for the v4.11 cycle Core changes: - Augment fwnode_get_named_gpiod() to configure the GPIO pin immediately after requesting it like all other APIs do. This is a treewide change also updating all users. - Pass a GPIO label down to gpiod_request() from fwnode_get_named_gpiod(). This makes debugfs and the userspace ABI correctly reflect the current in-kernel consumer of a pin taken using this abstraction. This is a treewide change also updating all users. - Rename devm_get_gpiod_from_child() to devm_fwnode_get_gpiod_from_child() to reflect the fact that this function is operating on a fwnode object. This is a treewide change also updating all users. - Make it possible to take multiple GPIOs in a single hog of device tree hogs. - The refactorings switching GPIO chips to use the .set_config() callback using standard pin control properties and providing a backend into the pin control subsystem that were also merged into the pin control tree naturally appear here too. Testing instrumentation: - A whole slew of cleanups and improvements to the mockup GPIO driver. We now have an extended userspace test exercising the subsystem, and we can inject interrupts etc from userspace to fully test the core GPIO functionality. New drivers: - New driver for the Cortina Systems Gemini GPIO controller. - New driver for the Exar XR17V352/354/358 chips. - New driver for the ACCES PCI-IDIO-16 PCI GPIO card. Driver changes: - RCAR: set the irqchip parent device, add fine-grained runtime PM support. - pca953x: support optional RESET control line on the chip. - DaVinci: cleanups and simplifications. Add support for multiple instances. - .set_multiple() and naming of lines on more or less all of the ISA/PCI GPIO controllers. - mcp23s08: refactored to use regmap as a first step to further rewrites and modernizations" * tag 'gpio-v4.11-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (61 commits) gpio: reintroduce devm_get_gpiod_from_child() gpio: pci-idio-16: Fix PCI BAR index gpio: pci-idio-16: Fix PCI device ID code gpio: mockup: implement event injecting over debugfs gpio: mockup: add a dummy irqchip gpio: mockup: implement naming the lines gpio: mockup: code shrink gpio: mockup: readability tweaks gpio: Add GPIO support for the ACCES PCI-IDIO-16 gpio: Add the devm_fwnode_get_index_gpiod_from_child() helper gpio: Rename devm_get_gpiod_from_child() gpio: mcp23s08: Select REGMAP/REGMAP_I2C to fix build error gpio: ws16c48: Add support for GPIO names gpio: gpio-mm: Add support for GPIO names gpio: 104-idio-16: Add support for GPIO names gpio: 104-idi-48: Add support for GPIO names gpio: 104-dio-48e: Add support for GPIO names gpio: ws16c48: Remove unnecessary driver_data set gpio: gpio-mm: Remove unnecessary driver_data set gpio: 104-idio-16: Remove unnecessary driver_data set ...
2017-02-14leds: ledtrig-heartbeat: Make top brightness adjustableJacek Anaszewski1-4/+11
LED class heartbeat trigger allowed only for blinking with max_brightness value. This patch adds more flexibility by exploiting part of LED core software blink infrastructure. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Pavel Machek <pavel@ucw.cz> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2017-02-04gpio: Rename devm_get_gpiod_from_child()Boris Brezillon1-2/+3
Rename devm_get_gpiod_from_child() into devm_fwnode_get_gpiod_from_child() to reflect the fact that this function is operating on a fwnode object. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-01-29leds: class: Add new optional brightness_hw_changed attributeHans de Goede2-0/+85
Some LEDs may have their brightness level changed autonomously (outside of kernel control) by hardware / firmware. This commit adds support for an optional brightness_hw_changed attribute to signal such changes to userspace (if a driver can detect them): What: /sys/class/leds/<led>/brightness_hw_changed Date: January 2017 KernelVersion: 4.11 Description: Last hardware set brightness level for this LED. Some LEDs may be changed autonomously by hardware/firmware. Only LEDs where this happens and the driver can detect this, will have this file. This file supports poll() to detect when the hardware changes the brightness. Reading this file will return the last brightness level set by the hardware, this may be different from the current brightness. Drivers which want to support this, simply add LED_BRIGHT_HW_CHANGED to their flags field and call led_classdev_notify_brightness_hw_changed() with the hardware set brightness when they detect a hardware / firmware triggered brightness change. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-01-26leds: ktd2692: avoid harmless maybe-uninitialized warningArnd Bergmann1-4/+4
gcc gets confused about the control flow in ktd2692_parse_dt(), causing it to warn about what seems like a potential bug: drivers/leds/leds-ktd2692.c: In function 'ktd2692_probe': drivers/leds/leds-ktd2692.c:244:15: error: '*((void *)&led_cfg+8)' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/leds/leds-ktd2692.c:225:7: error: 'led_cfg.flash_max_microamp' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/leds/leds-ktd2692.c:232:3: error: 'led_cfg.movie_max_microamp' may be used uninitialized in this function [-Werror=maybe-uninitialized] The code is fine, and slightly reworking it in an equivalent way lets gcc figure that out too, which gets rid of the warning. Fixes: 77e7915b15bb ("leds: ktd2692: Add missing of_node_put") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-01-26gpio: Pass GPIO label down to gpiod_requestAlexander Stein1-6/+7
Currently all users of fwnode_get_named_gpiod() have no way to specify a label for the GPIO. So GPIOs listed in debugfs are shown with label "?". With this change a proper label is used. Also adjust all users so they can pass a label, properly retrieved from device tree properties. Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-01-26gpiolib: Convert fwnode_get_named_gpiod() to configure GPIOAndy Shevchenko1-1/+1
Make fwnode_get_named_gpiod() consistent with the rest of gpiod_get() like API, i.e. configure GPIO pin immediately after request. Besides obvious clean up it will help to configure pins based on firmware provided resources. Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-01-04leds: pwm: Remove atomic code pathsThierry Reding1-13/+3
PWM devices have all been marked as "might sleep" since v4.5. It no longer makes sense to keep the alternative code paths around because it is effectively dead code. Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-12-25cpu/hotplug: Cleanup state namesThomas Gleixner1-1/+1
When the state names got added a script was used to add the extra argument to the calls. The script basically converted the state constant to a string, but the cleanup to convert these strings into meaningful ones did not happen. Replace all the useless strings with 'subsys/xxx/yyy:state' strings which are used in all the other places already. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sebastian Siewior <bigeasy@linutronix.de> Link: http://lkml.kernel.org/r/20161221192112.085444152@linutronix.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2016-12-02leds: pca955x: Add ACPI supportTin Huynh1-2/+22
This patch enables ACPI support for leds-pca955x driver. Signed-off-by: Tin Huynh <tnhuynh@apm.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-11-30leds: netxbig: fix module autoload for OF registrationJavier Martinez Canillas1-0/+1
If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo drivers/leds//leds-netxbig.ko | grep alias alias: platform:leds-netxbig After this patch: $ modinfo drivers/leds//leds-netxbig.ko | grep alias alias: platform:leds-netxbig alias: of:N*T*Clacie,netxbig-ledsC* alias: of:N*T*Clacie,netxbig-leds Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-11-30leds: pca963x: Add ACPI supportTin Huynh1-1/+21
This patch enables ACPI support for leds-pca963x driver. Signed-off-by: Tin Huynh <tnhuynh@apm.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-11-23leds: leds-cobalt-raq: use builtin_platform_driverGeliang Tang1-5/+1
Use builtin_platform_driver() helper to simplify the code. Signed-off-by: Geliang Tang <geliangtang@gmail.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-11-22Merge tag 'ib-mfd-arm-leds-v4.10' of ↵Jacek Anaszewski1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd into linux-leds/for-next Pull PM8XXX namespace cleanup from Lee Jones. * tag 'ib-mfd-arm-leds-v4.10' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: mfd: qcom-pm8xxx: Clean up PM8XXX namespace
2016-11-22led: core: Fix blink_brightness setting raceHans de Goede1-7/+7
All 3 of led_timer_func, led_set_brightness and led_set_software_blink set blink_brightness. If led_timer_func or led_set_software_blink race with led_set_brightness they may end up overwriting the new blink_brightness. The new atomic work_flags does not protect against this as it just protects the flags and not blink_brightness. This commit introduces a new new_blink_brightness value which gets set by led_set_brightness and read by led_timer_func on LED on, fixing this. Dealing with the new brightness at LED on time, makes the new brightness apply sooner, which also fixes a led_set_brightness which happens while a oneshot blink which ends in LED on is running not getting applied. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-11-22led: core: Use atomic bit-field for the blink-flagsHans de Goede2-25/+28
All the LED_BLINK* flags are accessed read-modify-write from e.g. led_set_brightness and led_blink_set_oneshot while both set_brightness_work and the blink_timer may be running. If these race then the modify step done by one of them may be lost, switch the LED_BLINK* flags to a new atomic work_flags bit-field to avoid this race. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-11-22leds: Add user LED driver for NIC78bx deviceHui Chun Ong3-0/+221
Add the driver to support User LEDs on PXI Embedded Controller. Signed-off-by: Hui Chun Ong <hui.chun.ong@ni.com> Signed-off-by: Brad Mouring <brad.mouring@ni.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-11-22leds: verify vendor and change license in mlxcpld driverVadim Pasternak1-1/+4
Verify that vendor is Mellanox as the first step of initialization. If it is not - return ENODEV. Change module license from "GPL v2" to "Dual BSD/GPL". Signed-off-by: Vadim Pasternak <vadimp@mellanox.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-11-22leds: pca963x: enable low-power stateMatt Ranostay1-7/+33
Allow chip to enter low power state when no LEDs are being lit or in blink mode. Cc: Peter Meerwald <p.meerwald@bct-electronic.com>, Cc: Ricardo Ribalda <ricardo.ribalda@gmail.com> Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Matt Ranostay <matt@ranostay.consulting> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-11-22leds: pca9532: Use default trigger value from platform dataFelix Brack1-1/+1
The value for a led's default_trigger should come from platform data instead of data (which is always 0). Signed-off-by: Felix Brack <fb@ltec.ch> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-11-22leds: pca963x: workaround group blink scaling issueMatt Ranostay1-3/+15
PCA9632TK part seems to incorrectly blink at ~1.3x of the programmed rate. This patchset add a nxp,period-scale devicetree property to adjust for this misconfiguration. Signed-off-by: Matt Ranostay <matt@ranostay.consulting> Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-11-22leds: lp3952: Export I2C module alias information for module autoloadJavier Martinez Canillas1-0/+1
If the driver is built as a module, I2C module alias information is not filled so the module won't be autoloaded if the device isn't registered over ACPI. Export the I2C device table alias with MODULE_DEVICE_TABLE() macro so the information is exported in the module. Before this patch: $ modinfo drivers/leds/leds-lp3952.ko | grep alias alias: acpi*:TXNW3952:* After this patch: $ modinfo drivers/leds/leds-lp3952.ko | grep alias alias: i2c:lp3952 alias: acpi*:TXNW3952:* Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-11-22leds: mc13783: Fix MC13892 keypad led accessAlexander Kurz1-2/+3
Fix the register access shift argument calculation introduced with commit a59ce6584d56 ("leds: leds-mc13783: Add MC34708 LED support") and re-enable access to the "keypad" led for MC13892 MFC devices. Signed-off-by: Alexander Kurz <akurz@blala.de> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-11-22ledtrig-cpu.c: fix englishPavel Machek1-1/+1
Fix english spelling. Signed-off-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-11-22leds: Use macro for max device node name sizeDavid Lechner1-1/+2
Use a macro instead of hard-coding the max device node name size. The uleds driver introduced a macro for this value, so using it. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-11-22leds: Introduce userspace LED class driverDavid Lechner3-0/+246
This driver creates a userspace leds driver similar to uinput. New LEDs are created by opening /dev/uleds and writing a uleds_user_dev struct. A new LED class device is registered with the name given in the struct. Reading will return a single byte that is the current brightness. The poll() syscall is also supported. It will be triggered whenever the brightness changes. Closing the file handle to /dev/uleds will remove the leds class device. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-11-21mfd: qcom-pm8xxx: Clean up PM8XXX namespaceLinus Walleij1-1/+1
The Kconfig and file naming for the PM8xxx driver is totally confusing: - Kconfig options MFD_PM8XXX and MFD_PM8921_CORE, some in-kernel users depending on or selecting either at random. - A driver file named pm8921-core.c even if it is indeed used by the whole PM8xxx family of chips. - An irqchip named pm8xxx since it was (I guess) realized that the driver was generic for all pm8xxx PMICs. As I may want to add support for PM8901 this is starting to get really messy. Fix this situation by: - Remove the MFD_PM8921_CORE symbol and rely solely on MFD_PM8XXX and convert all users, including LEDs Kconfig and ARM defconfigs for qcom and multi_v7 to use that single symbol. - Renaming the driver to qcom-pm8xxx.c to fit along the two other qcom* prefixed drivers. - Rename functions withing the driver from 8921 to 8xxx to indicate it is generic. - Just drop the =m config from the pxa_defconfig, I have no clue why it is even there, it is not a Qualcomm platform. (Possibly older Kconfig noise from saveconfig.) Cc: Stephen Boyd <sboyd@codeaurora.org> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Abhijeet Dharmapurikar <adharmap@codeaurora.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Gross <andy.gross@linaro.org> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2016-09-20leds: triggers: Check return value of kobject_uevent_env()Jacek Anaszewski1-1/+3
Log error message if kobject_uevent_env() fails in led_trigger_set(). Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-09-20leds: triggers: Return from led_trigger_set() if there is nothing to doJacek Anaszewski1-0/+3
If led_trigger_set() is called with "trig" argument set to NULL, and there is no trigger to remove then the function should return immediately so as to avoid doing unnecessary allocation and sending uevent. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Reported-by: Daniel Romell <daro@hms.se> Acked-by Daniel Romell <daro@hms.se>
2016-09-15leds: gpio: fix and simplify error handling in gpio_leds_createHeiner Kallweit1-8/+4
Simplify the error handling and add a missing call to fwnode_handle_put when checking led.name. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-09-15leds: gpio: switch to managed version of led_classdev_registerHeiner Kallweit1-21/+2
Using the managed version of led_classdev_register allows to significantly simplify the code. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-09-15leds: gpio: fix and simplify reading property "label"Heiner Kallweit1-9/+7
Checking for the presence of the property first isn't strictly needed as we can react on the return code of fwnode_property_read_string. Also, even if the presence of a property "label" was checked, reading a string value for it theoretically still can fail and this case isn't handled. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>