summaryrefslogtreecommitdiffstats
path: root/drivers/leds
Commit message (Collapse)AuthorAgeFilesLines
* leds: trigger/tty: Use led_set_brightness_sync() from workqueueUwe Kleine-König2021-03-101-2/+2
| | | | | | | | | | | | | | led_set_brightness() involves scheduling a workqueue. As here the led's brightness setting is done in context of the trigger's workqueue this is unjustified overhead and it's more sensible to use led_set_brightness_sync(). Fixes: fd4a641ac88f ("leds: trigger: implement a tty trigger") Reported-by: Pavel Machek <pavel@ucw.cz> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20210219133307.4840-3-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* leds: trigger: Fix error path to not unlock the unlocked mutexUwe Kleine-König2021-03-101-5/+2
| | | | | | | | | | | | ttyname is allocated before the mutex is taken, so it must not be unlocked in the error path. Fixes: fd4a641ac88f ("leds: trigger: implement a tty trigger") Reported-by: Pavel Machek <pavel@ucw.cz> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20210219133307.4840-2-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Merge tag 'leds-5.12-rc1' of ↵Linus Torvalds2021-02-2620-126/+1030
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds Pull LED updates from Pavel Machek: "Besides the usual fixes and new drivers, we are changing CLASS_FLASH to return success to make it easier to work with V4L2 stuff disabled, and we are getting rid of enum that should have been plain integer long time ago. I'm slightly nervous about potential warnings, but it needed to be fixed at some point" * tag 'leds-5.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds: leds: lp50xx: Get rid of redundant explicit casting leds: lp50xx: Update headers block to reflect reality leds: lp50xx: Get rid of redundant check in lp50xx_enable_disable() leds: lp50xx: Reduce level of dereferences leds: lp50xx: Switch to new style i2c-driver probe function leds: lp50xx: Don't spam logs when probe is deferred leds: apu: extend support for PC Engines APU1 with newer firmware leds: flash: Fix multicolor no-ops registration by return 0 leds: flash: Add flash registration with undefined CONFIG_LEDS_CLASS_FLASH leds: lgm: Add LED controller driver for LGM SoC dt-bindings: leds: Add bindings for Intel LGM SoC leds: led-core: Get rid of enum led_brightness leds: gpio: Set max brightness to 1 leds: lm3533: Switch to using the new API kobj_to_dev() leds: ss4200: simplify the return expression of register_nasgpio_led() leds: Use DEVICE_ATTR_{RW, RO, WO} macros
| * leds: lp50xx: Get rid of redundant explicit castingAndy Shevchenko2021-02-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | In the line like u32 bar = ...; u8 foo = (u8)(bar >> 8) & 0xff; is no need to have neither explicit casting nor ' & 0xff' part. Get rid of them. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
| * leds: lp50xx: Update headers block to reflect realityAndy Shevchenko2021-02-191-2/+1
| | | | | | | | | | | | | | | | The OF is not used in the driver, thus the OF headers are not needed, but mod_devicetable.h is missed. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
| * leds: lp50xx: Get rid of redundant check in lp50xx_enable_disable()Andy Shevchenko2021-02-191-5/+3
| | | | | | | | | | | | | | | | Since GPIO is optional the API is NULL aware and will check descriptor anyway. Remove duplicate redundant check in lp50xx_enable_disable(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
| * leds: lp50xx: Reduce level of dereferencesAndy Shevchenko2021-02-191-14/+12
| | | | | | | | | | | | | | | | The priv->dev is effectively the same as &priv->client->dev. So, drop the latter for the former. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
| * leds: lp50xx: Switch to new style i2c-driver probe functionAndy Shevchenko2021-02-191-17/+16
| | | | | | | | | | | | | | | | | | Switch to the new style i2c-driver probe_new probe function. Note we do not have any old style board files using this but user still has a possibility to instantiate device from sysfs. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
| * leds: lp50xx: Don't spam logs when probe is deferredAndy Shevchenko2021-02-191-6/+3
| | | | | | | | | | | | | | | | | | When requesting GPIO line the probe can be deferred. In such case don't spam logs with an error message. This can be achieved by switching to dev_err_probe(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
| * leds: apu: extend support for PC Engines APU1 with newer firmwareAndreas Eberlein2021-02-191-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | The DMI_PRODUCT_NAME entry on current firmware of PC Engines APU1 changed from "APU" to "apu1" This modification adds the missing DMI data and thereby the LED support for the PC Engines APU1 with firmware versions >= 4.6.8. Signed-off-by: Andreas Eberlein <foodeas@aeberlein.de> Tested-by: Zbyněk Kocur <zbynek.kocur@fel.cvut.cz> Signed-off-by: Pavel Machek <pavel@ucw.cz>
| * leds: lgm: Add LED controller driver for LGM SoCAmireddy Mallikarjuna reddy2021-02-195-0/+916
| | | | | | | | | | | | | | | | | | | | | | Parallel to serial conversion, which is also called SSO controller, can drive external shift register for LED outputs, reset or general purpose outputs. This driver enables LED support for Serial Shift Output Controller (SSO). Signed-off-by: Amireddy Mallikarjuna reddy <mallikarjunax.reddy@linux.intel.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
| * leds: led-core: Get rid of enum led_brightnessAbanoub Sameh2021-02-193-19/+10
| | | | | | | | | | | | | | | | | | | | | | This gets rid of enum led_brightness in the main led files, because it is deprecated, and an unsigned int can be used instead. We can get rid of led_brightness completely and patches can also be supplied for the other drivers' files. Signed-off-by: Abanoub Sameh <abanoubsameh@protonmail.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
| * leds: gpio: Set max brightness to 1Dylan Van Assche2021-02-031-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | GPIO LEDs only know 2 states: ON or OFF and do not have PWM capabilities. However, the max brightness is reported as 255. This patch sets the max brightness value of a GPIO controlled LED to 1. Tested on my PinePhone 1.2. Signed-off-by: Dylan Van Assche <me@dylanvanassche.be> Signed-off-by: Pavel Machek <pavel@ucw.cz>
| * leds: lm3533: Switch to using the new API kobj_to_dev()Tian Tao2021-02-031-1/+1
| | | | | | | | | | | | | | | | fixed the following coccicheck: drivers/leds/leds-lm3533.c:611:60-61: WARNING opportunity for kobj_to_dev(). Signed-off-by: Tian Tao <tiantao6@hisilicon.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
| * leds: ss4200: simplify the return expression of register_nasgpio_led()Zheng Yongjun2020-12-301-5/+1
| | | | | | | | | | | | | | Simplify the return expression. Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
| * leds: Use DEVICE_ATTR_{RW, RO, WO} macrosDwaipayan Ray2020-12-308-53/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | Instead of open coding DEVICE_ATTR() defines, use the DEVICE_ATTR_RW(), DEVICE_ATTR_WO(), and DEVICE_ATTR_RO() macros. This required a few functions to be renamed, but the functionality itself is unchanged. Reviewed-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Dwaipayan Ray <dwaipayanray1@gmail.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* | Merge tag 'tty-5.12-rc1' of ↵Linus Torvalds2021-02-203-0/+193
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty Pull tty/serial driver updates from Greg KH: "Here is the big set of tty/serial driver changes for 5.12-rc1. Nothing huge, just lots of good cleanups and additions: - n_tty line discipline cleanups - vt core cleanups and reworks to make the code more "modern" - stm32 driver additions - tty led support added to the tty core and led layer - minor serial driver fixups and additions All of these have been in linux-next for a while with no reported issues" * tag 'tty-5.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (54 commits) serial: core: Remove BUG_ON(in_interrupt()) check vt_ioctl: Remove in_interrupt() check dt-bindings: serial: imx: Switch to my personal address vt: keyboard, use new API for keyboard_tasklet serial: stm32: improve platform_get_irq condition handling in init_port serial: ifx6x60: Remove driver for deprecated platform tty: fix up iterate_tty_read() EOVERFLOW handling tty: fix up hung_up_tty_read() conversion tty: fix up hung_up_tty_write() conversion tty: teach the n_tty ICANON case about the new "cookie continuations" too tty: teach n_tty line discipline about the new "cookie continuations" tty: clean up legacy leftovers from n_tty line discipline tty: implement read_iter tty: convert tty_ldisc_ops 'read()' function to take a kernel pointer serial: remove sirf prima/atlas driver serial: mxs-auart: Remove <asm/cacheflush.h> serial: mxs-auart: Remove serial_mxs_probe_dt() serial: fsl_lpuart: Use of_device_get_match_data() dt-bindings: serial: renesas,hscif: Add r8a779a0 support tty: serial: Drop unused efm32 serial driver ...
| * | leds: trigger: implement a tty triggerUwe Kleine-König2021-01-153-0/+193
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Usage is as follows: myled=ledname tty=ttyS0 echo tty > /sys/class/leds/$myled/trigger echo $tty > /sys/class/leds/$myled/ttyname . When this new trigger is active it periodically checks the tty's statistics and when it changed since the last check the led is flashed once. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20210113173018.bq2fkea2o3yp6rf6@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | leds: rt8515: add V4L2_FLASH_LED_CLASS dependencyArnd Bergmann2021-02-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The leds-rt8515 driver can optionall use the v4l2 flash led class, but it causes a link error when that class is in a loadable module and the rt8515 driver itself is built-in: ld.lld: error: undefined symbol: v4l2_flash_init >>> referenced by leds-rt8515.c >>> leds/flash/leds-rt8515.o:(rt8515_probe) in archive drivers/built-in.a Adding 'depends on V4L2_FLASH_LED_CLASS' in Kconfig would avoid that, but it would make it impossible to use the driver without the v4l2 support. Add the same dependency that the other users of this class have instead, which just prevents the broken configuration. Fixes: e1c6edcbea13 ("leds: rt8515: Add Richtek RT8515 LED driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* | leds: rt8515: Add Richtek RT8515 LED driverLinus Walleij2021-01-315-0/+421
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a driver for the Richtek RT8515 dual channel torch/flash white LED driver. This LED driver is found in some mobile phones from Samsung such as the GT-S7710 and GT-I8190. A V4L interface is added. We do not have a proper datasheet for the RT8515 but it turns out that RT9387A has a public datasheet and is essentially the same chip. We designed the driver in accordance with this datasheet. The day someone needs to drive a RT9387A this driver can probably easily be augmented to handle that chip too. Sakari Ailus, Pavel Machek and Andy Shevchenko helped significantly in getting this driver right. Cc: Sakari Ailus <sakari.ailus@iki.fi> Cc: newbytee@protonmail.com Cc: Stephan Gerhold <stephan@gerhold.net> Cc: linux-media@vger.kernel.org Cc: phone-devel@vger.kernel.org Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* | leds: trigger: fix potential deadlock with libataAndrea Righi2021-01-311-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have the following potential deadlock condition: ======================================================== WARNING: possible irq lock inversion dependency detected 5.10.0-rc2+ #25 Not tainted -------------------------------------------------------- swapper/3/0 just changed the state of lock: ffff8880063bd618 (&host->lock){-...}-{2:2}, at: ata_bmdma_interrupt+0x27/0x200 but this lock took another, HARDIRQ-READ-unsafe lock in the past: (&trig->leddev_list_lock){.+.?}-{2:2} and interrupts could create inverse lock ordering between them. other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&trig->leddev_list_lock); local_irq_disable(); lock(&host->lock); lock(&trig->leddev_list_lock); <Interrupt> lock(&host->lock); *** DEADLOCK *** no locks held by swapper/3/0. the shortest dependencies between 2nd lock and 1st lock: -> (&trig->leddev_list_lock){.+.?}-{2:2} ops: 46 { HARDIRQ-ON-R at: lock_acquire+0x15f/0x420 _raw_read_lock+0x42/0x90 led_trigger_event+0x2b/0x70 rfkill_global_led_trigger_worker+0x94/0xb0 process_one_work+0x240/0x560 worker_thread+0x58/0x3d0 kthread+0x151/0x170 ret_from_fork+0x1f/0x30 IN-SOFTIRQ-R at: lock_acquire+0x15f/0x420 _raw_read_lock+0x42/0x90 led_trigger_event+0x2b/0x70 kbd_bh+0x9e/0xc0 tasklet_action_common.constprop.0+0xe9/0x100 tasklet_action+0x22/0x30 __do_softirq+0xcc/0x46d run_ksoftirqd+0x3f/0x70 smpboot_thread_fn+0x116/0x1f0 kthread+0x151/0x170 ret_from_fork+0x1f/0x30 SOFTIRQ-ON-R at: lock_acquire+0x15f/0x420 _raw_read_lock+0x42/0x90 led_trigger_event+0x2b/0x70 rfkill_global_led_trigger_worker+0x94/0xb0 process_one_work+0x240/0x560 worker_thread+0x58/0x3d0 kthread+0x151/0x170 ret_from_fork+0x1f/0x30 INITIAL READ USE at: lock_acquire+0x15f/0x420 _raw_read_lock+0x42/0x90 led_trigger_event+0x2b/0x70 rfkill_global_led_trigger_worker+0x94/0xb0 process_one_work+0x240/0x560 worker_thread+0x58/0x3d0 kthread+0x151/0x170 ret_from_fork+0x1f/0x30 } ... key at: [<ffffffff83da4c00>] __key.0+0x0/0x10 ... acquired at: _raw_read_lock+0x42/0x90 led_trigger_blink_oneshot+0x3b/0x90 ledtrig_disk_activity+0x3c/0xa0 ata_qc_complete+0x26/0x450 ata_do_link_abort+0xa3/0xe0 ata_port_freeze+0x2e/0x40 ata_hsm_qc_complete+0x94/0xa0 ata_sff_hsm_move+0x177/0x7a0 ata_sff_pio_task+0xc7/0x1b0 process_one_work+0x240/0x560 worker_thread+0x58/0x3d0 kthread+0x151/0x170 ret_from_fork+0x1f/0x30 -> (&host->lock){-...}-{2:2} ops: 69 { IN-HARDIRQ-W at: lock_acquire+0x15f/0x420 _raw_spin_lock_irqsave+0x52/0xa0 ata_bmdma_interrupt+0x27/0x200 __handle_irq_event_percpu+0xd5/0x2b0 handle_irq_event+0x57/0xb0 handle_edge_irq+0x8c/0x230 asm_call_irq_on_stack+0xf/0x20 common_interrupt+0x100/0x1c0 asm_common_interrupt+0x1e/0x40 native_safe_halt+0xe/0x10 arch_cpu_idle+0x15/0x20 default_idle_call+0x59/0x1c0 do_idle+0x22c/0x2c0 cpu_startup_entry+0x20/0x30 start_secondary+0x11d/0x150 secondary_startup_64_no_verify+0xa6/0xab INITIAL USE at: lock_acquire+0x15f/0x420 _raw_spin_lock_irqsave+0x52/0xa0 ata_dev_init+0x54/0xe0 ata_link_init+0x8b/0xd0 ata_port_alloc+0x1f1/0x210 ata_host_alloc+0xf1/0x130 ata_host_alloc_pinfo+0x14/0xb0 ata_pci_sff_prepare_host+0x41/0xa0 ata_pci_bmdma_prepare_host+0x14/0x30 piix_init_one+0x21f/0x600 local_pci_probe+0x48/0x80 pci_device_probe+0x105/0x1c0 really_probe+0x221/0x490 driver_probe_device+0xe9/0x160 device_driver_attach+0xb2/0xc0 __driver_attach+0x91/0x150 bus_for_each_dev+0x81/0xc0 driver_attach+0x1e/0x20 bus_add_driver+0x138/0x1f0 driver_register+0x91/0xf0 __pci_register_driver+0x73/0x80 piix_init+0x1e/0x2e do_one_initcall+0x5f/0x2d0 kernel_init_freeable+0x26f/0x2cf kernel_init+0xe/0x113 ret_from_fork+0x1f/0x30 } ... key at: [<ffffffff83d9fdc0>] __key.6+0x0/0x10 ... acquired at: __lock_acquire+0x9da/0x2370 lock_acquire+0x15f/0x420 _raw_spin_lock_irqsave+0x52/0xa0 ata_bmdma_interrupt+0x27/0x200 __handle_irq_event_percpu+0xd5/0x2b0 handle_irq_event+0x57/0xb0 handle_edge_irq+0x8c/0x230 asm_call_irq_on_stack+0xf/0x20 common_interrupt+0x100/0x1c0 asm_common_interrupt+0x1e/0x40 native_safe_halt+0xe/0x10 arch_cpu_idle+0x15/0x20 default_idle_call+0x59/0x1c0 do_idle+0x22c/0x2c0 cpu_startup_entry+0x20/0x30 start_secondary+0x11d/0x150 secondary_startup_64_no_verify+0xa6/0xab This lockdep splat is reported after: commit e918188611f0 ("locking: More accurate annotations for read_lock()") To clarify: - read-locks are recursive only in interrupt context (when in_interrupt() returns true) - after acquiring host->lock in CPU1, another cpu (i.e. CPU2) may call write_lock(&trig->leddev_list_lock) that would be blocked by CPU0 that holds trig->leddev_list_lock in read-mode - when CPU1 (ata_ac_complete()) tries to read-lock trig->leddev_list_lock, it would be blocked by the write-lock waiter on CPU2 (because we are not in interrupt context, so the read-lock is not recursive) - at this point if an interrupt happens on CPU0 and ata_bmdma_interrupt() is executed it will try to acquire host->lock, that is held by CPU1, that is currently blocked by CPU2, so: * CPU0 blocked by CPU1 * CPU1 blocked by CPU2 * CPU2 blocked by CPU0 *** DEADLOCK *** The deadlock scenario is better represented by the following schema (thanks to Boqun Feng <boqun.feng@gmail.com> for the schema and the detailed explanation of the deadlock condition): CPU 0: CPU 1: CPU 2: ----- ----- ----- led_trigger_event(): read_lock(&trig->leddev_list_lock); <workqueue> ata_hsm_qc_complete(): spin_lock_irqsave(&host->lock); write_lock(&trig->leddev_list_lock); ata_port_freeze(): ata_do_link_abort(): ata_qc_complete(): ledtrig_disk_activity(): led_trigger_blink_oneshot(): read_lock(&trig->leddev_list_lock); // ^ not in in_interrupt() context, so could get blocked by CPU 2 <interrupt> ata_bmdma_interrupt(): spin_lock_irqsave(&host->lock); Fix by using read_lock_irqsave/irqrestore() in led_trigger_event(), so that no interrupt can happen in between, preventing the deadlock condition. Apply the same change to led_trigger_blink_setup() as well, since the same deadlock scenario can also happen in power_supply_update_bat_leds() -> led_trigger_blink() -> led_trigger_blink_setup() (workqueue context), and potentially prevent other similar usages. Link: https://lore.kernel.org/lkml/20201101092614.GB3989@xps-13-7390/ Fixes: eb25cb9956cc ("leds: convert IDE trigger to common disk trigger") Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* | leds: leds-ariel: convert comma to semicolonZheng Yongjun2021-01-311-3/+3
| | | | | | | | | | | | | | | | Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Reviewed-by: Alexander Dahl <ada@thorsis.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* | leds: leds-lm3533: convert comma to semicolonZheng Yongjun2021-01-311-1/+1
|/ | | | | | | Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: turris-omnia: check for LED_COLOR_ID_RGB instead LED_COLOR_ID_MULTIMarek Behún2020-11-251-2/+2
| | | | | | | | | LED core does not allow LED_COLOR_ID_MULTI for now and instead for RGB LEDs prefers LED_COLOR_ID_RGB. Signed-off-by: Marek Behún <kabel@kernel.org> Fixes: 77dce3a22e89 ("leds: disallow /sys/class/leds/*:multi:* for now") Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: turris-omnia: fix checkpatch warningMarek Behún2020-11-251-2/+2
| | | | | | | Use kstrtoul instead of sscanf to satisfy checkpatch. Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: turris-omnia: wrap to 80 columnsMarek Behún2020-11-251-19/+24
| | | | | | | | Although checkpatch changed the max-line-length default to 100 columns, we still prefer 80 columns somewhere. Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: turris-omnia: use constants instead of macros for color commandMarek Behún2020-11-251-21/+13
| | | | | | | | | Use integer constants directly when building I2C messages for LED color change command, instead of macros. The command is simple enough to understand what is going on even without these names. Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: lp50xx: Fix an error handling path in 'lp50xx_probe_dt()'Christophe JAILLET2020-11-251-2/+4
| | | | | | | | | | | | | In case of memory allocation failure, we must release some resources as done in all other error handling paths of the function. 'goto child_out' instead of a direct return so that 'fwnode_handle_put()' is called when we break out of a 'device_for_each_child_node' loop. Fixes: 242b81170fb8 ("leds: lp50xx: Add the LP50XX family of the RGB LED driver") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: netxbig: add missing put_device() call in netxbig_leds_get_of_pdata()Yu Kuai2020-11-251-11/+24
| | | | | | | | | | if of_find_device_by_node() succeed, netxbig_leds_get_of_pdata() doesn't have a corresponding put_device(). Thus add jump target to fix the exception handling for this function implementation. Fixes: 2976b1798909 ("leds: netxbig: add device tree binding") Signed-off-by: Yu Kuai <yukuai3@huawei.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: pwm: Remove platform_data supportAlexander Dahl2020-10-071-25/+5
| | | | | | | | | | | | | | Since commit 141f15c66d94 ("leds: pwm: remove header") that platform interface is not usable from outside and there seems to be no in tree user anymore. All in-tree users of the leds-pwm driver seem to use DT currently. Getting rid of the old platform interface allows the leds-pwm driver to switch over from 'devm_led_classdev_register()' to 'devm_led_classdev_register_ext()'. Signed-off-by: Alexander Dahl <post@lespocky.de> Cc: Denis Osterland-Heim <denis.osterland@diehl.com> Reviewed-by: Marek Behún <marek.behun@nic.cz> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: lm3697: Fix out-of-bound accessGabriel David2020-10-051-3/+5
| | | | | | | | | | | | If both LED banks aren't used in device tree, an out-of-bounds condition in lm3697_init occurs because of the for loop assuming that all the banks are used. Fix it by adding a variable that contains the number of used banks. Signed-off-by: Gabriel David <ultracoolguy@tutanota.com> [removed extra rename, minor tweaks] Signed-off-by: Pavel Machek <pavel@ucw.cz> Cc: stable@kernel.org
* leds: ns2: do not guard OF match pointer with of_match_ptrMarek Behún2020-09-301-7/+7
| | | | | | | | | | | | Do not match OF match pointer with of_match_ptr, so that even if CONFIG_OF is disabled, the driver can still be bound via another method. Move definition of of_ns2_leds_match just before ns2_led_driver definition, since it is not needed sooner. Signed-off-by: Marek Behún <kabel@kernel.org> Tested-by: Simon Guinot <simon.guinot@sequanux.org> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: ns2: convert to fwnode APIMarek Behún2020-09-301-29/+26
| | | | | | | | | | | | | Convert from OF api to fwnode API, so that it is possible to bind this driver without device-tree. The fwnode API does not expose a function to read a specific element of an array. We therefore change the types of the ns2_led_modval structure so that we can read the whole modval array with one fwnode call. Signed-off-by: Marek Behún <kabel@kernel.org> Tested-by: Simon Guinot <simon.guinot@sequanux.org> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: tlc591xx: fix leak of device node iteratorTobias Jordan2020-09-301-1/+3
| | | | | | | | | | | | In one of the error paths of the for_each_child_of_node loop in tlc591xx_probe, add missing call to of_node_put. Fixes: 1ab4531ad132 ("leds: tlc591xx: simplify driver by using the managed led API") Signed-off-by: Tobias Jordan <kernel@cdqe.de> Reviewed-by: Marek Behún <kabel@kernel.org> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: pca963x: use struct led_init_data when registeringMarek Behún2020-09-301-13/+12
| | | | | | | | | | | | | | | | | | | | By using struct led_init_data when registering we do not need to parse `label` DT property. Moreover `label` is deprecated and if it is not present but `color` and `function` are, LED core will compose a name from these properties instead. Previously if the `label` DT property was not present, the code composed name for the LED in the form "pca963x:%d:%.2x:%u" For backwards compatibility we therefore set init_data->default_label to this value so that the LED will not get a different name if `label` property is not present, nor are `color` and `function`. Signed-off-by: Marek Behún <marek.behun@nic.cz> Cc: Peter Meerwald <p.meerwald@bct-electronic.com> Cc: Ricardo Ribalda <ribalda@kernel.org> Cc: Zahari Petkov <zahari@balena.io> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: pca963x: register LEDs immediately after parsing, get rid of platdataMarek Behún2020-09-301-117/+71
| | | | | | | | | | | | Register LEDs immediately after parsing their properties. This allows us to get rid of platdata, and since no one in tree uses header linux/platform_data/leds-pca963x.h, remove it. Signed-off-by: Marek Behún <marek.behun@nic.cz> Cc: Peter Meerwald <p.meerwald@bct-electronic.com> Cc: Ricardo Ribalda <ribalda@kernel.org> Cc: Zahari Petkov <zahari@balena.io> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: tca6507: remove binding commentMarek Behún2020-09-301-17/+0
| | | | | | | | | | | | Remove the binding comment at the beginning. The information for platdata is now obsolete and DT binding is documented in device-tree bindings. Signed-off-by: Marek Behún <marek.behun@nic.cz> Cc: NeilBrown <neilb@suse.de> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: tca6507: cosmetic change: use helper variableMarek Behún2020-09-301-17/+16
| | | | | | | | | | Use helper variable dev instead of always writing &client->dev. Signed-off-by: Marek Behún <marek.behun@nic.cz> Cc: NeilBrown <neilb@suse.de> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: tca6507: do not set GPIO namesMarek Behún2020-09-301-3/+0
| | | | | | | | | | | Do not set GPIO names. Let gpiolib determine GPIO names from the DT property `gpio-line-names`. Signed-off-by: Marek Behún <marek.behun@nic.cz> Cc: NeilBrown <neilb@suse.de> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* ledtrig-cpu: Limit to 8 CPUsPavel Machek2020-09-301-3/+10
| | | | | | | | | Some machines have thousands of CPUs... and trigger mechanisms was not really meant for thousands of triggers. I doubt anyone uses this trigger on many-CPU machine; but if they do, they'll need to do it properly. Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: TODO: Add documentation about possible subsystem improvementsPavel Machek2020-09-301-0/+75
| | | | | | Help welcome :-). Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: pca9532: read pwm settings from device treeMarkus Moll2020-09-301-0/+5
| | | | | | | | | While the two pca9532 pwms can be configured in the platform data struct, there was no corresponding dt binding. Users need to configure the pwm if some leds should blink or continue blinking during boot. Signed-off-by: Markus Moll <mmoll@de.pepperl-fuchs.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: pca9532: correct shift computation in pca9532_getledMarkus Moll2020-09-301-3/+5
| | | | | | | | | | Each led setting occupies two bits in a corresponding led register. Accessing these bits requires shifting and masking, which was implemented incorrectly in pca9532_getled. Two new helper macros concentrate the computation of those masks in one place. Signed-off-by: Markus Moll <mmoll@de.pepperl-fuchs.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: lm36274: Fix warning for undefined parametersDan Murphy2020-09-301-2/+3
| | | | | | | | Fix warnings for undefined parameters when building with W=1. Signed-off-by: Dan Murphy <dmurphy@ti.com> Reviewed-by: Marek Behún <kabel@kernel.org> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: lm3532: Fix warnings for undefined parametersDan Murphy2020-09-301-25/+25
| | | | | | | | Fix warnings for undefined parameters when W=1 is used. Signed-off-by: Dan Murphy <dmurphy@ti.com> Reviewed-by: Marek Behún <kabel@kernel.org> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: pca963x: use flexible arrayMarek Behún2020-09-301-16/+12
| | | | | | | | | | | Instead of doing two allocations, allocate only once, by utilizing flexible array members. Signed-off-by: Marek Behún <marek.behun@nic.cz> Cc: Peter Meerwald <p.meerwald@bct-electronic.com> Cc: Ricardo Ribalda <ribalda@kernel.org> Cc: Zahari Petkov <zahari@balena.io> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: pca963x: cosmetic: rename variablesMarek Behún2020-09-301-51/+53
| | | | | | | | | | Rename variable of type struct pca963x_led from pca963x to simple led. Signed-off-by: Marek Behún <marek.behun@nic.cz> Cc: Peter Meerwald <p.meerwald@bct-electronic.com> Cc: Ricardo Ribalda <ribalda@kernel.org> Cc: Zahari Petkov <zahari@balena.io> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: pca963x: cosmetic: rename variablesMarek Behún2020-09-301-27/+28
| | | | | | | | | | | | Rename variables chip and pca963x_chip to chipdef and chip, respectively, so that their names correspond to the names of their types. Signed-off-by: Marek Behún <marek.behun@nic.cz> Cc: Peter Meerwald <p.meerwald@bct-electronic.com> Cc: Ricardo Ribalda <ribalda@kernel.org> Cc: Zahari Petkov <zahari@balena.io> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: pca963x: use devres LED registering functionMarek Behún2020-09-301-20/+2
| | | | | | | | | | | By using devres version of LED registering function we can remove the .remove method from this driver. The probe method also gets simpler. Signed-off-by: Marek Behún <marek.behun@nic.cz> Cc: Peter Meerwald <p.meerwald@bct-electronic.com> Cc: Ricardo Ribalda <ribalda@kernel.org> Cc: Zahari Petkov <zahari@balena.io> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: pca963x: cosmetic: use helper variables, better indentationMarek Behún2020-09-301-68/+71
| | | | | | | | | | | | | | | | | Use helper variables: instead of writing &client->dev at many places, write only dev. The same with pca963x->chip->chipdef, pca963x->chip->client). Use helper variable u8 val for i2c_smbus_write_byte_data, for better indentation. Indent better on various places. Signed-off-by: Marek Behún <marek.behun@nic.cz> Cc: Peter Meerwald <p.meerwald@bct-electronic.com> Cc: Ricardo Ribalda <ribalda@kernel.org> Cc: Zahari Petkov <zahari@balena.io> Signed-off-by: Pavel Machek <pavel@ucw.cz>