aboutsummaryrefslogtreecommitdiff
path: root/drivers/leds/trigger
AgeCommit message (Collapse)AuthorFilesLines
2023-05-31leds: trigger: netdev: refactor code setting device nameAndrew Lunn1-9/+20
Move the code into a helper, ready for it to be called at other times. No intended behaviour change. Signed-off-by: Andrew Lunn <[email protected]> Signed-off-by: Christian Marangi <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-05-25leds: trigger: netdev: Remove NULL check before dev_{put, hold}Yang Li1-4/+2
The call netdev_{put, hold} of dev_{put, hold} will check NULL, so there is no need to check before using dev_{put, hold}, remove it to silence the warnings: ./drivers/leds/trigger/ledtrig-netdev.c:291:3-10: WARNING: NULL check before dev_{put, hold} functions is not needed. ./drivers/leds/trigger/ledtrig-netdev.c:401:2-9: WARNING: NULL check before dev_{put, hold} functions is not needed. Reported-by: Abaci Robot <[email protected]> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=4929 Signed-off-by: Yang Li <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-05-25leds: Change led_trigger_blink[_oneshot]() delay parameters to pass-by-valueHans de Goede2-12/+5
led_blink_set[_oneshot]()'s delay_on and delay_off function parameters are pass by reference, so that hw-blink implementations can report back the actual achieved delays when the values have been rounded to something the hw supports. This is really only interesting for the sysfs API / the timer trigger. Other triggers don't really care about this and none of the callers of led_trigger_blink[_oneshot]() do anything with the returned delay values. Change the led_trigger_blink[_oneshot]() delay parameters to pass-by-value, there are 2 reasons for this: 1. led_cdev->blink_set() may sleep, while led_trigger_blink() may not. So on hw where led_cdev->blink_set() sleeps the call needs to be deferred to a workqueue, in which case the actual achieved delays are unknown (this is a preparation patch for the deferring). 2. Since the callers don't care about the actual achieved delays, allowing callers to directly pass a value leads to simpler code for most callers. Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Jacek Anaszewski <[email protected]> Tested-by: Yauhen Kharuzhy <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Acked-by: Sebastian Reichel <[email protected]> Acked-by: Florian Westphal <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2023-05-25leds: trigger: netdev: Use mutex instead of spinlocksChristian Marangi1-9/+9
Some LEDs may require to sleep while doing some operation like setting brightness and other cleanup. For this reason, using a spinlock will cause a sleep under spinlock warning. It should be safe to convert this to a sleepable lock since: - sysfs read/write can sleep - netdev_trig_work is a work queue and can sleep - netdev _trig_notify can sleep The spinlock was used when brightness didn't support sleeping, but this changed and now it supported with brightness_set_blocking(). Convert to mutex lock to permit sleeping using brightness_set_blocking(). Signed-off-by: Christian Marangi <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-05-25leds: trigger: netdev: Convert device attr to macroChristian Marangi1-41/+16
Convert link tx and rx device attr to a common macro to reduce common code and in preparation for additional attr. Signed-off-by: Christian Marangi <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-05-25leds: trigger: netdev: Rename add namespace to netdev trigger enum modesChristian Marangi1-33/+25
Rename NETDEV trigger enum modes to a more symbolic name and add a namespace to them. Also add __TRIGGER_NETDEV_MAX to identify the max modes of the netdev trigger. This is a cleanup to drop the define and no behaviour change are intended. Signed-off-by: Christian Marangi <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-05-25leds: trigger: netdev: Drop NETDEV_LED_MODE_LINKUP from modeChristian Marangi1-11/+8
Putting NETDEV_LED_MODE_LINKUP in the same list of the netdev trigger modes is wrong as it's used to set the link state of the device and not to set a blink mode as it's done by NETDEV_LED_LINK, NETDEV_LED_TX and NETDEV_LED_RX. It's also wrong to put this state in the same bitmap of the netdev trigger mode and should be external to it. Drop NETDEV_LED_MODE_LINKUP from mode list and convert to a simple bool that will be true or false based on the carrier link. No functional change intended. Signed-off-by: Christian Marangi <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-05-25leds: trigger: netdev: Recheck NETDEV_LED_MODE_LINKUP on dev renameChristian Marangi1-0/+3
Dev can be renamed also while up for supported device. We currently wrongly clear the NETDEV_LED_MODE_LINKUP flag on NETDEV_CHANGENAME event. Fix this by rechecking if the carrier is ok on NETDEV_CHANGENAME and correctly set the NETDEV_LED_MODE_LINKUP bit. Fixes: 5f820ed52371 ("leds: trigger: netdev: fix handling on interface rename") Cc: [email protected] # v5.5+ Signed-off-by: Christian Marangi <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-03-16leds: Mark GPIO LED trigger brokenLinus Walleij1-0/+1
The GPIO LED trigger exposes a userspace ABI where a user can echo a GPIO number from the global GPIO numberspace into a file that will trigger a certain LED when active. This is problematic because the global GPIO numberspace is inherently instable. The trigger came about at a time when systems had one GPIO controller that defined hard-wired GPIOs numbered 0..N and this number space was stable. We have since moved to dynamic allocation of GPIO numbers and there is no real guarantee that a GPIO number will stay consistent even across a reboot: consider a USB attached GPIO controller for example. Or two. Or the effect of probe order after adding -EPROBE_DEFER to the kernel. The trigger was added to support keypad LEDs on the Nokia n810 from the GPIO event when a user slides up/down the keypad. This is arch/arm/boot/dts/omap2420-n810.dts. A userspace script is needed to activate the trigger. This will be broken unless the script was updated recently since the OMAP GPIO controller now uses dynamic GPIO number allocations. I want to know that this trigger has active users that cannot live without it if we are to continue to support it. Option if this is really needed: I can develop a new trigger that can associate GPIOs with LEDs as triggers using device tree, which should also remove the use of userspace custom scripts to achieve this and be much more trustworthy, if someone with the Nokia n810 or a device with a similar need is willing to test it. Suggested-by Pavel Machek <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-02-04leds: Remove ide-disk triggerCorentin Labbe1-4/+0
No user of ide-disk remains, so remove this deprecated trigger. Only a few platforms used this and were fixed in 2016. Signed-off-by: Corentin Labbe <[email protected]> Acked-by: Rob Herring <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-12-25treewide: Convert del_timer*() to timer_shutdown*()Steven Rostedt (Google)4-4/+4
Due to several bugs caused by timers being re-armed after they are shutdown and just before they are freed, a new state of timers was added called "shutdown". After a timer is set to this state, then it can no longer be re-armed. The following script was run to find all the trivial locations where del_timer() or del_timer_sync() is called in the same function that the object holding the timer is freed. It also ignores any locations where the timer->function is modified between the del_timer*() and the free(), as that is not considered a "trivial" case. This was created by using a coccinelle script and the following commands: $ cat timer.cocci @@ expression ptr, slab; identifier timer, rfield; @@ ( - del_timer(&ptr->timer); + timer_shutdown(&ptr->timer); | - del_timer_sync(&ptr->timer); + timer_shutdown_sync(&ptr->timer); ) ... when strict when != ptr->timer ( kfree_rcu(ptr, rfield); | kmem_cache_free(slab, ptr); | kfree(ptr); ) $ spatch timer.cocci . > /tmp/t.patch $ patch -p1 < /tmp/t.patch Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Steven Rostedt (Google) <[email protected]> Acked-by: Pavel Machek <[email protected]> [ LED ] Acked-by: Kalle Valo <[email protected]> [ wireless ] Acked-by: Paolo Abeni <[email protected]> [ networking ] Signed-off-by: Linus Torvalds <[email protected]>
2022-12-07leds: use sysfs_emit() to instead of scnprintf()ye xingchen1-1/+1
Replace the open-code with sysfs_emit() to simplify the code. Signed-off-by: ye xingchen <[email protected]> Signed-off-by: Pavel Machek <[email protected]>
2021-10-13leds: trigger: Disable CPU trigger on PREEMPT_RTSebastian Andrzej Siewior1-0/+1
The CPU trigger is invoked on ARM from CPU-idle. That trigger later invokes led_trigger_event() which may invoke the callback of the actual driver. That driver can acquire a spinlock_t which is okay on kernel without PREEMPT_RT. On a PREEMPT_RT enabled kernel this lock is turned into a sleeping lock and must not be acquired with disabled interrupts. Disable the CPU trigger on PREEMPT_RT. Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Pavel Machek <[email protected]>
2021-08-18leds: trigger: remove reference to obsolete CONFIG_IDE_GD_ATALukas Bulwahn1-1/+1
Commit b7fb14d3ac63 ("ide: remove the legacy ide driver") removes the definition of the config IDE_GD_ATA. So, remove the obsolete reference in ./drivers/leds/trigger/Kconfig. Signed-off-by: Lukas Bulwahn <[email protected]> Signed-off-by: Pavel Machek <[email protected]>
2021-08-03leds: trigger: audio: Add an activate callback to ensure the initial ↵Hans de Goede1-8/+29
brightness is set Some 2-in-1s with a detachable (USB) keyboard(dock) have mute-LEDs in the speaker- and/or mic-mute keys on the keyboard. Examples of this are the Lenovo Thinkpad10 tablet (with its USB kbd-dock) and the HP x2 10 series. The detachable nature of these keyboards means that the keyboard and thus the mute LEDs may show up after the user (or userspace restoring old mixer settings) has muted the speaker and/or mic. Current LED-class devices with a default_trigger of "audio-mute" or "audio-micmute" initialize the brightness member of led_classdev with ledtrig_audio_get() before registering the LED. This makes the software state after attaching the keyboard match the actual audio mute state, e.g. cat /sys/class/leds/foo/brightness will show the right value. But before this commit nothing was actually calling the led_classdev's brightness_set[_blocking] callback so the value returned by ledtrig_audio_get() was never actually being sent to the hw, leading to the mute LEDs staying in their default power-on state, after attaching the keyboard, even if ledtrig_audio_get() returned a different state. This could be fixed by having the individual LED drivers call brightness_set[_blocking] themselves after registering the LED, but this really is something which should be done by a led-trigger activate callback. Add an activate callback for this, fixing the issue of the mute LEDs being out of sync after (re)attaching the keyboard. Cc: Takashi Iwai <[email protected]> Fixes: faa2541f5b1a ("leds: trigger: Introduce audio mute LED trigger") Reviewed-by: Marek Behún <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Pavel Machek <[email protected]>
2021-07-03Merge tag 'leds-5.14-rc1' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds Pull LED updates from Pavel Machek: "This contains quite a lot of fixes, with more fixes in my inbox that did not make it (sorry)" * tag 'leds-5.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds: (36 commits) leds: lgm: Fix up includes leds: ktd2692: Fix an error handling path leds: as3645a: Fix error return code in as3645a_parse_node() leds: turris-omnia: add missing MODULE_DEVICE_TABLE leds: lp55xx: Initialize enable GPIO direction to output leds: lm36274: Add missed property.h leds: el15203000: Make error handling more robust leds: pwm: Make error handling more robust leds: lt3593: Make use of device properties leds: lp50xx: Put fwnode in error case during ->probe() leds: lm3697: Don't spam logs when probe is deferred leds: lm3692x: Put fwnode in any case during ->probe() leds: lm36274: Correct headers (of*.h -> mod_devicetable.h) leds: lm36274: Put fwnode in error case during ->probe() leds: lm3532: Make error handling more robust leds: lm3532: select regmap I2C API leds: lgm-sso: Drop duplicate NULL check for GPIO operations leds: lgm-sso: Remove unneeded of_match_ptr() leds: lgm-sso: Fix clock handling leds: el15203000: Introduce to_el15203000_led() helper ...
2021-07-01kernel.h: split out panic and oops helpersAndy Shevchenko3-0/+3
kernel.h is being used as a dump for all kinds of stuff for a long time. Here is the attempt to start cleaning it up by splitting out panic and oops helpers. There are several purposes of doing this: - dropping dependency in bug.h - dropping a loop by moving out panic_notifier.h - unload kernel.h from something which has its own domain At the same time convert users tree-wide to use new headers, although for the time being include new header back to kernel.h to avoid twisted indirected includes for existing users. [[email protected]: thread_info.h needs limits.h] [[email protected]: ia64 fix] Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Co-developed-by: Andrew Morton <[email protected]> Acked-by: Mike Rapoport <[email protected]> Acked-by: Corey Minyard <[email protected]> Acked-by: Christian Brauner <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Acked-by: Kees Cook <[email protected]> Acked-by: Wei Liu <[email protected]> Acked-by: Rasmus Villemoes <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Acked-by: Sebastian Reichel <[email protected]> Acked-by: Luis Chamberlain <[email protected]> Acked-by: Stephen Boyd <[email protected]> Acked-by: Thomas Bogendoerfer <[email protected]> Acked-by: Helge Deller <[email protected]> # parisc Signed-off-by: Linus Torvalds <[email protected]>
2021-05-28leds: trigger: ledtrig-cpu: Fix incorrectly documented param 'ledevt'Lee Jones1-1/+1
Fixes the following W=1 kernel build warning(s): drivers/leds/trigger/ledtrig-cpu.c:52: warning: Function parameter or member 'ledevt' not described in 'ledtrig_cpu' drivers/leds/trigger/ledtrig-cpu.c:52: warning: Excess function parameter 'evt' description in 'ledtrig_cpu' Cc: Pavel Machek <[email protected]> Cc: Linus Walleij <[email protected]> Cc: Bryan Wu <[email protected]> Cc: [email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Pavel Machek <[email protected]>
2021-05-03Merge tag 'leds-5.13-rc1' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds Pull LED updates from Pavel Machek: "Nothing too exciting here, just some fixes" * tag 'leds-5.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds: leds: pca9532: Assign gpio base dynamically leds: trigger: pattern: Switch to using the new API kobj_to_dev() leds: LEDS_BLINK_LGM should depend on X86 leds: lgm: Fix spelling mistake "prepate" -> "prepare" MAINTAINERS: Remove Dan Murphy's bouncing email leds-lm3642: convert comma to semicolon leds: rt4505: Add support for Richtek RT4505 flash LED controller leds: rt4505: Add DT binding document for Richtek RT4505 leds: Kconfig: LEDS_CLASS is usually selected. leds: lgm: Improve Kconfig help leds: lgm: fix gpiolib dependency
2021-04-25leds: trigger: pattern: Switch to using the new API kobj_to_dev()Tian Tao1-1/+1
Switch to using the new API kobj_to_dev() to fix the below warnning: ./drivers/leds/trigger/ledtrig-pattern.c:336:60-61: WARNING opportunity for kobj_to_dev() Signed-off-by: Tian Tao <[email protected]> Signed-off-by: Pavel Machek <[email protected]>
2021-03-10leds: trigger/tty: Use led_set_brightness_sync() from workqueueUwe Kleine-König1-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 <[email protected]> Acked-by: Pavel Machek <[email protected]> Signed-off-by: Uwe Kleine-König <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-03-10leds: trigger: Fix error path to not unlock the unlocked mutexUwe Kleine-König1-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 <[email protected]> Acked-by: Pavel Machek <[email protected]> Signed-off-by: Uwe Kleine-König <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-01-15leds: trigger: implement a tty triggerUwe Kleine-König3-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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-09-30ledtrig-cpu: Limit to 8 CPUsPavel Machek1-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 <[email protected]>
2020-07-24leds: pattern trigger -- check pattern for validityPavel Machek1-2/+4
Don't allow invalid brightness in the pattern. Signed-off-by: Pavel Machek <[email protected]>
2020-07-12leds: trigger: gpio: Avoid warning on update of invertedJan Kiszka1-1/+2
If the GPIO has not been configured yet, writing to inverted will raise a kernel warning. Signed-off-by: Jan Kiszka <[email protected]> Signed-off-by: Pavel Machek <[email protected]>
2020-04-27leds: trigger: remove redundant assignment to variable retColin Ian King1-2/+2
The variable ret is being assigned with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Pavel Machek <[email protected]>
2020-01-22ledtrig-pattern: fix email address quoting in MODULE_AUTHOR()Pavel Machek1-2/+2
Apparently it is quite easy to forget ">" in quoting of email address. This fixes it. Signed-off-by: Pavel Machek <[email protected]>
2019-12-01Merge tag 'leds-5.5-rc1' of ↵Linus Torvalds1-1/+4
git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds Pull LED updates from Pavel Machek: "This contains usual small updates to drivers, and removal of PAGE_SIZE limits on /sys/class/leds/<led>/trigger. We should not be really having that many triggers; but with cpu activity triggers we do, and we'll eventually need to fix it, but... remove the limit for now" * tag 'leds-5.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds: (26 commits) leds: trigger: netdev: fix handling on interface rename leds: an30259a: add a check for devm_regmap_init_i2c leds: mlxreg: Fix possible buffer overflow leds: pca953x: Use of_device_get_match_data() leds: core: Fix leds.h structure documentation leds: core: Fix devm_classdev_match to reference correct structure leds: core: Remove extern from header leds: lm3601x: Convert class registration to device managed leds: flash: Add devm_* functions to the flash class leds: flash: Remove extern from the header file leds: flash: Convert non extended registration to inline leds: Kconfig: Be consistent with the usage of "LED" leds: remove PAGE_SIZE limit of /sys/class/leds/<led>/trigger leds: tlc591xx: update the maximum brightness leds: lm3692x: Use flags from LM3692X_BRT_CTRL leds: lm3692x: Use flags from LM3692X_BOOST_CTRL leds: lm3692x: Handle failure to probe the regulator leds: lm3692x: Don't overwrite return value in error path leds: lm3692x: Print error value on dev_err leds: tlc591xx: use devm_led_classdev_register_ext() ...
2019-11-21leds: Use all-in-one vtime aware kcpustat accessorFrederic Weisbecker1-5/+9
We can now safely read user kcpustat fields on nohz_full CPUs. Use the appropriate accessor. [ mingo: Fixed build failure. ] Reported-by: Yauheni Kaliuta <[email protected]> Signed-off-by: Frederic Weisbecker <[email protected]> Cc: Jacek Anaszewski <[email protected]> (maintainer:LED SUBSYSTEM) Cc: Pavel Machek <[email protected]> (maintainer:LED SUBSYSTEM) Cc: Dan Murphy <[email protected]> (reviewer:LED SUBSYSTEM) Cc: Peter Zijlstra <[email protected]> Cc: Wanpeng Li <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-11-03leds: trigger: netdev: fix handling on interface renameMartin Schiller1-1/+4
The NETDEV_CHANGENAME code is not "unneeded" like it is stated in commit 4cb6560514fa ("leds: trigger: netdev: fix refcnt leak on interface rename"). The event was accidentally misinterpreted equivalent to NETDEV_UNREGISTER, but should be equivalent to NETDEV_REGISTER. This was the case in the original code from the openwrt project. Otherwise, you are unable to set netdev led triggers for (non-existent) netdevices, which has to be renamed. This is the case, for example, for ppp interfaces in openwrt. Fixes: 06f502f57d0d ("leds: trigger: Introduce a NETDEV trigger") Fixes: 4cb6560514fa ("leds: trigger: netdev: fix refcnt leak on interface rename") Signed-off-by: Martin Schiller <[email protected]> Signed-off-by: Pavel Machek <[email protected]>
2019-10-29leds: Use vtime aware kcpustat accessor to fetch CPUTIME_SYSTEMFrederic Weisbecker1-1/+1
Now that we have a vtime safe kcpustat accessor for CPUTIME_SYSTEM, use it to start fixing frozen kcpustat values on nohz_full CPUs. Reported-by: Yauheni Kaliuta <[email protected]> Signed-off-by: Frederic Weisbecker <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: Jacek Anaszewski <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Pavel Machek <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Rafael J . Wysocki <[email protected]> Cc: Rik van Riel <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Viresh Kumar <[email protected]> Cc: Wanpeng Li <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-09-01leds: trigger: gpio: GPIO 0 is validAndy Shevchenko1-5/+7
Allow all valid GPIOs to be used in the driver. Fixes: 17354bfe8527 ("leds: Add gpio-led trigger") Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Jacek Anaszewski <[email protected]>
2019-07-09Merge tag 'leds-for-5.3-rc1' of ↵Linus Torvalds2-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds Pull LED updates from Jacek Anaszewski: - Add a new LED common module for ti-lmu driver family - Modify MFD ti-lmu bindings - add ti,brightness-resolution - add the ramp up/down property - Add regulator support for LM36274 driver to lm363x-regulator.c - New LED class drivers with DT bindings: - leds-spi-byte - leds-lm36274 - leds-lm3697 (move the support from MFD to LED subsystem) - Simplify getting the I2C adapter of a client: - leds-tca6507 - leds-pca955x - Convert LED documentation to ReST * tag 'leds-for-5.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds: dt: leds-lm36274.txt: fix a broken reference to ti-lmu.txt docs: leds: convert to ReST leds: leds-tca6507: simplify getting the adapter of a client leds: leds-pca955x: simplify getting the adapter of a client leds: lm36274: Introduce the TI LM36274 LED driver dt-bindings: leds: Add LED bindings for the LM36274 regulator: lm363x: Add support for LM36274 mfd: ti-lmu: Add LM36274 support to the ti-lmu dt-bindings: mfd: Add lm36274 bindings to ti-lmu leds: max77650: Remove set but not used variable 'parent' leds: avoid flush_work in atomic context leds: lm3697: Introduce the lm3697 driver mfd: ti-lmu: Remove support for LM3697 dt-bindings: ti-lmu: Modify dt bindings for the LM3697 leds: TI LMU: Add common code for TI LMU devices leds: spi-byte: add single byte SPI LED driver dt-bindings: leds: Add binding for spi-byte LED. dt-bindings: mfd: LMU: Add ti,brightness-resolution dt-bindings: mfd: LMU: Add the ramp up/down property
2019-07-03Merge branch 'timers/vdso' into timers/coreThomas Gleixner12-53/+12
so the hyper-v clocksource update can be applied.
2019-06-28docs: leds: convert to ReSTMauro Carvalho Chehab2-2/+2
Rename the leds documentation files to ReST, add an index for them and adjust in order to produce a nice html output via the Sphinx build system. At its new index.rst, let's add a :orphan: while this is not linked to the main index.rst file, in order to avoid build warnings. Signed-off-by: Mauro Carvalho Chehab <[email protected]> Acked-by: Pavel Machek <[email protected]> Signed-off-by: Jacek Anaszewski <[email protected]>
2019-06-22timekeeping: Use proper clock specifier names in functionsJason A. Donenfeld1-1/+1
This makes boot uniformly boottime and tai uniformly clocktai, to address the remaining oversights. Signed-off-by: Jason A. Donenfeld <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2019-06-19treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500Thomas Gleixner12-53/+12
Based on 2 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation # extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 4122 file(s). Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Enrico Weigelt <[email protected]> Reviewed-by: Kate Stewart <[email protected]> Reviewed-by: Allison Randal <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-05-31leds: avoid flush_work in atomic contextPavel Machek1-0/+5
It turns out that various triggers use led_blink_setup() from atomic context, so we can't do a flush_work there. Flush is still needed for slow LEDs, but we can move it to sysfs code where it is safe. WARNING: inconsistent lock state 5.2.0-rc1 #1 Tainted: G W -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. swapper/1/0 [HC0[0]:SC1[1]:HE1:SE0] takes: 000000006e30541b ((work_completion)(&led_cdev->set_brightness_work)){+.?.}, at: +__flush_work+0x3b/0x38a {SOFTIRQ-ON-W} state was registered at: lock_acquire+0x146/0x1a1 __flush_work+0x5b/0x38a flush_work+0xb/0xd led_blink_setup+0x1e/0xd3 led_blink_set+0x3f/0x44 tpt_trig_timer+0xdb/0x106 ieee80211_mod_tpt_led_trig+0xed/0x112 Fixes: 0db37915d912 ("leds: avoid races with workqueue") Signed-off-by: Pavel Machek <[email protected]> Tested-by: Hugh Dickins <[email protected]> Signed-off-by: Jacek Anaszewski <[email protected]>
2019-05-26leds: avoid flush_work in atomic contextPavel Machek1-0/+5
It turns out that various triggers use led_blink_setup() from atomic context, so we can't do a flush_work there. Flush is still needed for slow LEDs, but we can move it to sysfs code where it is safe. WARNING: inconsistent lock state 5.2.0-rc1 #1 Tainted: G W -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. swapper/1/0 [HC0[0]:SC1[1]:HE1:SE0] takes: 000000006e30541b ((work_completion)(&led_cdev->set_brightness_work)){+.?.}, at: +__flush_work+0x3b/0x38a {SOFTIRQ-ON-W} state was registered at: lock_acquire+0x146/0x1a1 __flush_work+0x5b/0x38a flush_work+0xb/0xd led_blink_setup+0x1e/0xd3 led_blink_set+0x3f/0x44 tpt_trig_timer+0xdb/0x106 ieee80211_mod_tpt_led_trig+0xed/0x112 Fixes: 0db37915d912 ("leds: avoid races with workqueue") Signed-off-by: Pavel Machek <[email protected]> Tested-by: Hugh Dickins <[email protected]> Signed-off-by: Jacek Anaszewski <[email protected]>
2019-05-21treewide: Add SPDX license identifier - Makefile/KconfigThomas Gleixner1-0/+1
Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-03-30leds: trigger: netdev: use memcpy in device_name_storeRasmus Villemoes1-1/+2
If userspace doesn't end the input with a newline (which can easily happen if the write happens from a C program that does write(fd, iface, strlen(iface))), we may end up including garbage from a previous, longer value in the device_name. For example # cat device_name # printf 'eth12' > device_name # cat device_name eth12 # printf 'eth3' > device_name # cat device_name eth32 I highly doubt anybody is relying on this behaviour, so switch to simply copying the bytes (we've already checked that size is < IFNAMSIZ) and unconditionally zero-terminate it; of course, we also still have to strip a trailing newline. This is also preparation for future patches. Fixes: 06f502f57d0d ("leds: trigger: Introduce a NETDEV trigger") Signed-off-by: Rasmus Villemoes <[email protected]> Acked-by: Pavel Machek <[email protected]> Signed-off-by: Jacek Anaszewski <[email protected]>
2019-03-26leds: trigger: netdev: fix refcnt leak on interface renameRafał Miłecki1-8/+5
Renaming a netdev-trigger-tracked interface was resulting in an unbalanced dev_hold(). Example: > iw phy phy0 interface add foo type __ap > echo netdev > trigger > echo foo > device_name > ip link set foo name bar > iw dev bar del [ 237.355366] unregister_netdevice: waiting for bar to become free. Usage count = 1 [ 247.435362] unregister_netdevice: waiting for bar to become free. Usage count = 1 [ 257.545366] unregister_netdevice: waiting for bar to become free. Usage count = 1 Above problem was caused by trigger checking a dev->name which obviously changes after renaming an interface. It meant missing all further events including the NETDEV_UNREGISTER which is required for calling dev_put(). This change fixes that by: 1) Comparing device struct *address* for notification-filtering purposes 2) Dropping unneeded NETDEV_CHANGENAME code (no behavior change) Fixes: 06f502f57d0d ("leds: trigger: Introduce a NETDEV trigger") Signed-off-by: Rafał Miłecki <[email protected]> Acked-by: Pavel Machek <[email protected]> Signed-off-by: Jacek Anaszewski <[email protected]>
2019-01-16leds: trigger: timer: Add initialization from Device TreeKrzysztof Kozlowski1-0/+34
Allow initialization of delays used in timer trigger from Device Tree property. This is especially useful for embedded systems where the trigger might be used early, before bringing up user-space. Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Jacek Anaszewski <[email protected]>
2019-01-16leds: trigger: oneshot: Add initialization from Device TreeKrzysztof Kozlowski1-2/+36
Allow initialization of delays used in oneshot trigger from Device Tree property. This is especially useful for embedded systems where the trigger might be used early, before bringing up user-space. Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Jacek Anaszewski <[email protected]>
2019-01-16leds: trigger: pattern: Add pattern initialization from Device TreeKrzysztof Kozlowski1-19/+80
Allow initialization of pattern used in pattern trigger from Device Tree property. This is especially useful for embedded systems where the pattern trigger would be used to indicate the process of boot status in a nice, user-friendly blinking way. This initialization pattern will be used till user-space is brought up and sets its own pattern, indicating the boot status is for example finished. Signed-off-by: Krzysztof Kozlowski <[email protected]> Acked-by: Pavel Machek <[email protected]> Signed-off-by: Jacek Anaszewski <[email protected]>
2018-11-28leds: trigger: Introduce audio mute LED triggerTakashi Iwai3-0/+52
This patch adds a new LED trigger for coupling the audio mixer change with the LED on laptops or other devices. Currently there are two trigger types, "audio-mute" and "audio-micmute". The audio driver triggers the LED brightness change via ledtrig_audio_set() call with the proper type (either mute or mic-mute). OTOH, the consumers may call ledtrig_audio_get() for the initial brightness value that may have been set by the audio driver beforehand. This new stuff will be used by HD-audio codec driver and some platform drivers (thinkpad_acpi and dell-laptop, also upcoming huawei-wmi). Acked-by: Jacek Anaszewski <[email protected]> Acked-by: Pavel Machek <[email protected]> Acked-by: Pali Rohár <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2018-11-07leds: trigger: Fix sleeping function called from invalid contextBaolin Wang1-16/+4
We will meet below issue due to mutex_lock() is called in interrupt context. The mutex lock is used to protect the pattern trigger data, but before changing new pattern trigger data (pattern values or repeat value) by users, we always cancel the timer firstly to clear previous patterns' performance. That means there is no race in pattern_trig_timer_function(), so we can drop the mutex lock in pattern_trig_timer_function() to avoid this issue. Moreover we can move the timer cancelling into mutex protection, since there is no deadlock risk if we remove the mutex lock in pattern_trig_timer_function(). BUG: sleeping function called from invalid context at kernel/locking/mutex.c:254 in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/1 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.20.0-rc1-koelsch-00841-ga338c8181013c1a9 #171 Hardware name: Generic R-Car Gen2 (Flattened Device Tree) [<c020f19c>] (unwind_backtrace) from [<c020aecc>] (show_stack+0x10/0x14) [<c020aecc>] (show_stack) from [<c07affb8>] (dump_stack+0x7c/0x9c) [<c07affb8>] (dump_stack) from [<c02417d4>] (___might_sleep+0xf4/0x158) [<c02417d4>] (___might_sleep) from [<c07c92c4>] (mutex_lock+0x18/0x60) [<c07c92c4>] (mutex_lock) from [<c067b28c>] (pattern_trig_timer_function+0x1c/0x11c) [<c067b28c>] (pattern_trig_timer_function) from [<c027f6fc>] (call_timer_fn+0x1c/0x90) [<c027f6fc>] (call_timer_fn) from [<c027f944>] (expire_timers+0x94/0xa4) [<c027f944>] (expire_timers) from [<c027fc98>] (run_timer_softirq+0x108/0x15c) [<c027fc98>] (run_timer_softirq) from [<c02021cc>] (__do_softirq+0x1d4/0x258) [<c02021cc>] (__do_softirq) from [<c0224d24>] (irq_exit+0x64/0xc4) [<c0224d24>] (irq_exit) from [<c0268dd0>] (__handle_domain_irq+0x80/0xb4) [<c0268dd0>] (__handle_domain_irq) from [<c045e1b0>] (gic_handle_irq+0x58/0x90) [<c045e1b0>] (gic_handle_irq) from [<c02019f8>] (__irq_svc+0x58/0x74) Exception stack(0xeb483f60 to 0xeb483fa8) 3f60: 00000000 00000000 eb9afaa0 c0217e80 00000000 ffffe000 00000000 c0e06408 3f80: 00000002 c0e0647c c0c6a5f0 00000000 c0e04900 eb483fb0 c0207ea8 c0207e98 3fa0: 60020013 ffffffff [<c02019f8>] (__irq_svc) from [<c0207e98>] (arch_cpu_idle+0x1c/0x38) [<c0207e98>] (arch_cpu_idle) from [<c0247ca8>] (do_idle+0x138/0x268) [<c0247ca8>] (do_idle) from [<c0248050>] (cpu_startup_entry+0x18/0x1c) [<c0248050>] (cpu_startup_entry) from [<402022ec>] (0x402022ec) Fixes: 5fd752b6b3a2 ("leds: core: Introduce LED pattern trigger") Signed-off-by: Baolin Wang <[email protected]> Reported-by: Geert Uytterhoeven <[email protected]> Tested-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Jacek Anaszewski <[email protected]>
2018-10-25Fix pattern handling optimalizationPavel Machek1-3/+4
Check for zero duration before skipping step. This fixes pattern echo "0 1000 10 2550 0 1000" > pattern which should do [ .-xXx-.] but does [ Xx-.] Signed-off-by: Pavel Machek <[email protected]> Suggested-by: Jacek Anaszewski <[email protected]> Signed-off-by: Jacek Anaszewski <[email protected]>
2018-10-11leds: core: Introduce LED pattern triggerBaolin Wang3-0/+419
This patch adds a new LED trigger that LED device can configure to employ software or hardware pattern engine. Consumers can write 'pattern' file to enable the software pattern which alters the brightness for the specified duration with one software timer. Moreover consumers can write 'hw_pattern' file to enable the hardware pattern for some LED controllers which can autonomously control brightness over time, according to some preprogrammed hardware patterns. Signed-off-by: Raphael Teysseyre <[email protected]> Signed-off-by: Baolin Wang <[email protected]> Signed-off-by: Jacek Anaszewski <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.