linux/drivers/leds/trigger, branch v5.1

leds: trigger: netdev: use memcpy in device_name_store

2019-03-30T18:09:32Z

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 Acked-by: Pavel Machek Signed-off-by: Jacek Anaszewski

leds: trigger: netdev: fix refcnt leak on interface rename

2019-03-26T19:25:37Z

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 Acked-by: Pavel Machek Signed-off-by: Jacek Anaszewski

leds: trigger: timer: Add initialization from Device Tree

2019-01-16T21:09:25Z

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 Signed-off-by: Jacek Anaszewski

leds: trigger: oneshot: Add initialization from Device Tree

2019-01-16T21:09:18Z

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 Signed-off-by: Jacek Anaszewski

leds: trigger: pattern: Add pattern initialization from Device Tree

2019-01-16T21:08:47Z

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 Acked-by: Pavel Machek Signed-off-by: Jacek Anaszewski

leds: trigger: Introduce audio mute LED trigger

2018-11-28T11:28:30Z

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 Acked-by: Pavel Machek Acked-by: Pali Rohár Signed-off-by: Takashi Iwai

leds: trigger: Fix sleeping function called from invalid context

2018-11-07T20:43:25Z

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) [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x7c/0x9c) [] (dump_stack) from [] (___might_sleep+0xf4/0x158) [] (___might_sleep) from [] (mutex_lock+0x18/0x60) [] (mutex_lock) from [] (pattern_trig_timer_function+0x1c/0x11c) [] (pattern_trig_timer_function) from [] (call_timer_fn+0x1c/0x90) [] (call_timer_fn) from [] (expire_timers+0x94/0xa4) [] (expire_timers) from [] (run_timer_softirq+0x108/0x15c) [] (run_timer_softirq) from [] (__do_softirq+0x1d4/0x258) [] (__do_softirq) from [] (irq_exit+0x64/0xc4) [] (irq_exit) from [] (__handle_domain_irq+0x80/0xb4) [] (__handle_domain_irq) from [] (gic_handle_irq+0x58/0x90) [] (gic_handle_irq) from [] (__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 [] (__irq_svc) from [] (arch_cpu_idle+0x1c/0x38) [] (arch_cpu_idle) from [] (do_idle+0x138/0x268) [] (do_idle) from [] (cpu_startup_entry+0x18/0x1c) [] (cpu_startup_entry) from [<402022ec>] (0x402022ec) Fixes: 5fd752b6b3a2 ("leds: core: Introduce LED pattern trigger") Signed-off-by: Baolin Wang Reported-by: Geert Uytterhoeven Tested-by: Geert Uytterhoeven Signed-off-by: Jacek Anaszewski

Fix pattern handling optimalization

2018-10-25T18:47:46Z

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 Suggested-by: Jacek Anaszewski Signed-off-by: Jacek Anaszewski

leds: core: Introduce LED pattern trigger

2018-10-11T19:55:58Z

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 Signed-off-by: Baolin Wang Signed-off-by: Jacek Anaszewski

leds: gpio trigger: simplifications from core changes

2018-07-05T21:21:15Z

The trigger core learned error handling for the activate callback and to handle device attributes. Also make use of the module_led_trigger() helper to simplify trigger registration. Signed-off-by: Uwe Kleine-König Acked-by: Pavel Machek Signed-off-by: Jacek Anaszewski