| Age | Commit message (Collapse) | Author |
|---|
|
[ Upstream commit ab477b766edd3bfb6321a6e3df4c790612613fae ]
The race fixed in timer_trig_activate() between a blocking
set_brightness() call and trigger->activate() can affect any trigger.
So move the call to flush_work() into led_trigger_set() where it can
avoid the race for all triggers.
Fixes: 0db37915d912 ("leds: avoid races with workqueue")
Fixes: 8c0f693c6eff ("leds: avoid flush_work in atomic context")
Cc: stable@vger.kernel.org
Tested-by: Dustin L. Howett <dustin@howett.net>
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20240613-led-trigger-flush-v2-1-f4f970799d77@weissschuh.net
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 415798bc07dd1c1ae3a656aa026580816e0b9fe8 ]
Commit d5e01266e7f5 ("leds: trigger: netdev: add additional specific link
speed mode") in the various changes, reworked the way to set the LINKUP
mode in commit cee4bd16c319 ("leds: trigger: netdev: Recheck
NETDEV_LED_MODE_LINKUP on dev rename") and moved it to a generic function.
This changed the logic where, in the previous implementation the dev
from the trigger event was used to check if the carrier was ok, but in
the new implementation with the generic function, the dev in
trigger_data is used instead.
This is problematic and cause a possible kernel panic due to the fact
that the dev in the trigger_data still reference the old one as the
new one (passed from the trigger event) still has to be hold and saved
in the trigger_data struct (done in the NETDEV_REGISTER case).
On calling of get_device_state(), an invalid net_dev is used and this
cause a kernel panic.
To handle this correctly, move the call to get_device_state() after the
new net_dev is correctly set in trigger_data (in the NETDEV_REGISTER
case) and correctly parse the new dev.
Fixes: d5e01266e7f5 ("leds: trigger: netdev: add additional specific link speed mode")
Cc: stable@vger.kernel.org
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20240203235413.1146-1-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
failed
[ Upstream commit afacb21834bb02785ddb0c3ec197208803b74faa ]
It doesn't make sense to register the panic notifier if creating the
panic trigger failed.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/8a61e229-5388-46c7-919a-4d18cc7362b2@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit 25054b232681c286fca9c678854f56494d1352cc upstream.
The ttyname buffer for the ledtrig_tty_data struct is allocated in the
sysfs ttyname_store() function. This buffer must be released on trigger
deactivation. This was missing and is thus a memory leak.
While we are at it, the TTY handler in the ledtrig_tty_data struct should
also be returned in case of the trigger deactivation call.
Cc: stable@vger.kernel.org
Fixes: fd4a641ac88f ("leds: trigger: implement a tty trigger")
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20231127081621.774866-1-fe@dev.tdt.de
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit fe2b1226656afae56702d1d84c6900f6b67df297 upstream.
When working on LED support for r8169 I got the following lockdep
warning. Easiest way to prevent this scenario seems to be to take
the RTNL lock before the trigger_data lock in set_device_name().
======================================================
WARNING: possible circular locking dependency detected
6.7.0-rc2-next-20231124+ #2 Not tainted
------------------------------------------------------
bash/383 is trying to acquire lock:
ffff888103aa1c68 (&trigger_data->lock){+.+.}-{3:3}, at: netdev_trig_notify+0xec/0x190 [ledtrig_netdev]
but task is already holding lock:
ffffffff8cddf808 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock+0x12/0x20
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (rtnl_mutex){+.+.}-{3:3}:
__mutex_lock+0x9b/0xb50
mutex_lock_nested+0x16/0x20
rtnl_lock+0x12/0x20
set_device_name+0xa9/0x120 [ledtrig_netdev]
netdev_trig_activate+0x1a1/0x230 [ledtrig_netdev]
led_trigger_set+0x172/0x2c0
led_trigger_write+0xf1/0x140
sysfs_kf_bin_write+0x5d/0x80
kernfs_fop_write_iter+0x15d/0x210
vfs_write+0x1f0/0x510
ksys_write+0x6c/0xf0
__x64_sys_write+0x14/0x20
do_syscall_64+0x3f/0xf0
entry_SYSCALL_64_after_hwframe+0x6c/0x74
-> #0 (&trigger_data->lock){+.+.}-{3:3}:
__lock_acquire+0x1459/0x25a0
lock_acquire+0xc8/0x2d0
__mutex_lock+0x9b/0xb50
mutex_lock_nested+0x16/0x20
netdev_trig_notify+0xec/0x190 [ledtrig_netdev]
call_netdevice_register_net_notifiers+0x5a/0x100
register_netdevice_notifier+0x85/0x120
netdev_trig_activate+0x1d4/0x230 [ledtrig_netdev]
led_trigger_set+0x172/0x2c0
led_trigger_write+0xf1/0x140
sysfs_kf_bin_write+0x5d/0x80
kernfs_fop_write_iter+0x15d/0x210
vfs_write+0x1f0/0x510
ksys_write+0x6c/0xf0
__x64_sys_write+0x14/0x20
do_syscall_64+0x3f/0xf0
entry_SYSCALL_64_after_hwframe+0x6c/0x74
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(rtnl_mutex);
lock(&trigger_data->lock);
lock(rtnl_mutex);
lock(&trigger_data->lock);
*** DEADLOCK ***
8 locks held by bash/383:
#0: ffff888103ff33f0 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x6c/0xf0
#1: ffff888103aa1e88 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x114/0x210
#2: ffff8881036f1890 (kn->active#82){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x11d/0x210
#3: ffff888108e2c358 (&led_cdev->led_access){+.+.}-{3:3}, at: led_trigger_write+0x30/0x140
#4: ffffffff8cdd9e10 (triggers_list_lock){++++}-{3:3}, at: led_trigger_write+0x75/0x140
#5: ffff888108e2c270 (&led_cdev->trigger_lock){++++}-{3:3}, at: led_trigger_write+0xe3/0x140
#6: ffffffff8cdde3d0 (pernet_ops_rwsem){++++}-{3:3}, at: register_netdevice_notifier+0x1c/0x120
#7: ffffffff8cddf808 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock+0x12/0x20
stack backtrace:
CPU: 0 PID: 383 Comm: bash Not tainted 6.7.0-rc2-next-20231124+ #2
Hardware name: Default string Default string/Default string, BIOS ADLN.M6.SODIMM.ZB.CY.015 08/08/2023
Call Trace:
<TASK>
dump_stack_lvl+0x5c/0xd0
dump_stack+0x10/0x20
print_circular_bug+0x2dd/0x410
check_noncircular+0x131/0x150
__lock_acquire+0x1459/0x25a0
lock_acquire+0xc8/0x2d0
? netdev_trig_notify+0xec/0x190 [ledtrig_netdev]
__mutex_lock+0x9b/0xb50
? netdev_trig_notify+0xec/0x190 [ledtrig_netdev]
? __this_cpu_preempt_check+0x13/0x20
? netdev_trig_notify+0xec/0x190 [ledtrig_netdev]
? __cancel_work_timer+0x11c/0x1b0
? __mutex_lock+0x123/0xb50
mutex_lock_nested+0x16/0x20
? mutex_lock_nested+0x16/0x20
netdev_trig_notify+0xec/0x190 [ledtrig_netdev]
call_netdevice_register_net_notifiers+0x5a/0x100
register_netdevice_notifier+0x85/0x120
netdev_trig_activate+0x1d4/0x230 [ledtrig_netdev]
led_trigger_set+0x172/0x2c0
? preempt_count_add+0x49/0xc0
led_trigger_write+0xf1/0x140
sysfs_kf_bin_write+0x5d/0x80
kernfs_fop_write_iter+0x15d/0x210
vfs_write+0x1f0/0x510
ksys_write+0x6c/0xf0
__x64_sys_write+0x14/0x20
do_syscall_64+0x3f/0xf0
entry_SYSCALL_64_after_hwframe+0x6c/0x74
RIP: 0033:0x7f269055d034
Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d 35 c3 0d 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 48 89 54 24 18 48
RSP: 002b:00007ffddb7ef748 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000000007 RCX: 00007f269055d034
RDX: 0000000000000007 RSI: 000055bf5f4af3c0 RDI: 0000000000000001
RBP: 000055bf5f4af3c0 R08: 0000000000000073 R09: 0000000000000001
R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000007
R13: 00007f26906325c0 R14: 00007f269062ff20 R15: 0000000000000000
</TASK>
Fixes: d5e01266e7f5 ("leds: trigger: netdev: add additional specific link speed mode")
Cc: stable@vger.kernel.org
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/fb5c8294-2a10-4bf5-8f10-3d2b77d2757e@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 259e33cbb1712a7dd844fc9757661cc47cb0e39b upstream.
GCC 13.2 complains about array subscript 17 is above array bounds of
'char[16]' with IFNAMSIZ set to 16.
The warning is correct but this scenario is impossible.
set_device_name is called by device_name_store (store sysfs entry) and
netdev_trig_activate.
device_name_store already check if size is >= of IFNAMSIZ and return
-EINVAL. (making the warning scenario impossible)
netdev_trig_activate works on already defined interface, where the name
has already been checked and should already follow the condition of
strlen() < IFNAMSIZ.
Aside from the scenario being impossible, set_device_name can be
improved to both mute the warning and make the function safer.
To make it safer, move size check from device_name_store directly to
set_device_name and prevent any out of bounds scenario.
Cc: stable@vger.kernel.org
Fixes: 28a6a2ef18ad ("leds: trigger: netdev: refactor code setting device name")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202309192035.GTJEEbem-lkp@intel.com/
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20231007131042.15032-1-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit ff50f53276131a3059e8307d11293af388ed2bcd ]
In order to teach the compiler that 'trig->name' will never be truncated,
we need to tell it that 'cpu' is not negative.
When building with W=1, this fixes the following warnings:
drivers/leds/trigger/ledtrig-cpu.c: In function ‘ledtrig_cpu_init’:
drivers/leds/trigger/ledtrig-cpu.c:155:56: error: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size 5 [-Werror=format-truncation=]
155 | snprintf(trig->name, MAX_NAME_LEN, "cpu%d", cpu);
| ^~
drivers/leds/trigger/ledtrig-cpu.c:155:52: note: directive argument in the range [-2147483648, 7]
155 | snprintf(trig->name, MAX_NAME_LEN, "cpu%d", cpu);
| ^~~~~~~
drivers/leds/trigger/ledtrig-cpu.c:155:17: note: ‘snprintf’ output between 5 and 15 bytes into a destination of size 8
155 | snprintf(trig->name, MAX_NAME_LEN, "cpu%d", cpu);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fixes: 8f88731d052d ("led-triggers: create a trigger for CPU activity")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/3f4be7a99933cf8566e630da54f6ab913caac432.1695453322.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds
Pull LED updates from Lee Jones:
"Core Frameworks:
- Add new framework to support Group Multi-Color (GMC) LEDs
- Offer an 'optional' API for non-essential LEDs
- Support obtaining 'max brightness' values from Device Tree
- Provide new led_classdev member 'color' (settable via DT and SYFS)
- Stop TTY Trigger from using the old LED_ON constraints
- Statically allocate leds_class
New Drivers:
- Add support for NXP PCA995x I2C Constant Current LED Driver
New Device Support:
- Add support for Siemens Simatic IPC BX-21 to Simatic IPC
Fix-ups:
- Some dependency / Kconfig tweaking
- Move final probe() functions back over from .probe_new()
- Simplify obtaining resources (memory, device data) using unified
API helpers
- Bunch of Device Tree additions, conversions and adaptions
- Fix trivial styling issues; comments
- Ensure correct includes are present and remove some that are not
required
- Omit the use of redundant casts and if relevant replace with better
ones
- Use purpose-built APIs for various actions; sysfs_emit(),
module_led_trigger()
- Remove a bunch of superfluous locking
Bug Fixes:
- Ensure error codes are correctly propagated back up the call chain
- Fix incorrect error values from being returned (missing '-')
- Ensure get'ed resources are put'ed to prevent leaks
- Use correct class when exporting module resources
- Fixing rounding (or lack there of) issues
- Fix 'always false' LED_COLOR_ID_MULTI BUG() check"
* tag 'leds-next-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (40 commits)
leds: aw2013: Enable pull-up supply for interrupt and I2C
dt-bindings: leds: Document pull-up supply for interrupt and I2C
dt-bindings: leds: aw2013: Document interrupt
leds: uleds: Use module_misc_device macro to simplify the code
leds: trigger: netdev: Use module_led_trigger macro to simplify the code
dt-bindings: leds: Fix reference to definition of default-state
leds: turris-omnia: Drop unnecessary mutex locking
leds: turris-omnia: Use sysfs_emit() instead of sprintf()
leds: Make leds_class a static const structure
leds: Remove redundant of_match_ptr()
dt-bindings: leds: Add gpio-line-names to PCA9532 GPIO
leds: trigger: tty: Do not use LED_ON/OFF constants, use led_blink_set_oneshot instead
dt-bindings: leds: rohm,bd71828: Drop select:false
leds: Fix BUG_ON check for LED_COLOR_ID_MULTI that is always false
leds: multicolor: Use rounded division when calculating color components
leds: rgb: Add a multicolor LED driver to group monochromatic LEDs
dt-bindings: leds: Add binding for a multicolor group of LEDs
leds: class: Store the color index in struct led_classdev
leds: Provide devm_of_led_get_optional()
leds: pca995x: Fix MODULE_DEVICE_TABLE for OF
...
|
|
Cross-merge networking fixes after downstream PR.
Conflicts:
include/net/inet_sock.h
f866fbc842de ("ipv4: fix data-races around inet->inet_id")
c274af224269 ("inet: introduce inet->inet_flags")
https://lore.kernel.org/all/679ddff6-db6e-4ff6-b177-574e90d0103d@tessares.net/
Adjacent changes:
drivers/net/bonding/bond_alb.c
e74216b8def3 ("bonding: fix macvlan over alb bond support")
f11e5bd159b0 ("bonding: support balance-alb with openvswitch")
drivers/net/ethernet/broadcom/bgmac.c
d6499f0b7c7c ("net: bgmac: Return PTR_ERR() for fixed_phy_register()")
23a14488ea58 ("net: bgmac: Fix return value check for fixed_phy_register()")
drivers/net/ethernet/broadcom/genet/bcmmii.c
32bbe64a1386 ("net: bcmgenet: Fix return value check for fixed_phy_register()")
acf50d1adbf4 ("net: bcmgenet: Return PTR_ERR() for fixed_phy_register()")
net/sctp/socket.c
f866fbc842de ("ipv4: fix data-races around inet->inet_id")
b09bde5c3554 ("inet: move inet->mc_loop to inet->inet_frags")
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Commit b655892ffd6d ("leds: trigger: netdev: expose hw_control status
via sysfs") exposed to sysfs the flag that tells whether the LED trigger
is offloaded to hardware, under the name "hw_control", since that is the
name under which this setting is called in the code.
Everywhere else in kernel when some work that is normally done in
software can be made to be done by hardware instead, we use the word
"offloading" to describe this, e.g. "LED blinking is offloaded to
hardware".
Normally renaming sysfs entries is a no-go because of backwards
compatibility. But since this patch was not yet released in a stable
kernel, I think it is still possible to rename it, if there is
consensus.
Fixes: b655892ffd6d ("leds: trigger: netdev: expose hw_control status via sysfs")
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20230821121453.30203-1-kabel@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Use the module_led_trigger macro to simplify the code, which is the
same as declaring with module_init() and module_exit().
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20230815075944.1089298-2-lizetao1@huawei.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
led_blink_set_oneshot instead
The tty LED trigger uses the obsolete LED_ON & LED_OFF constants when
setting LED brightness. This is bad because the LED_ON constant is equal
to 1, and so when activating the tty LED trigger on a LED class device
with max_brightness greater than 1, the LED is dimmer than it can be
(when max_brightness is 255, the LED is very dimm indeed; some devices
translate 1/255 to 0, so the LED is OFF all the time).
Instead of directly setting brightness to a specific value, use the
led_blink_set_oneshot() function from LED core to configure the blink.
This function takes the current configured brightness as blink
brightness if not zero, and max brightness otherwise.
This also changes the behavior of the TTY LED trigger. Previously if
rx/tx stats kept changing, the LED was ON all the time they kept
changing. With this patch the LED will blink on TTY activity.
Fixes: fd4a641ac88f ("leds: trigger: implement a tty trigger")
Signed-off-by: Marek Behún <kabel@kernel.org>
Link: https://lore.kernel.org/r/20230802090753.13611-1-kabel@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Ensure that the offloading of blinking is stopped when the trigger is
deactivated. Calling led_set_brightness() is documented as stopping
offload and setting the LED to a constant brightness.
Suggested-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Tested-by: Daniel Golle <daniel@makrotopia.org>
Link: https://lore.kernel.org/r/20230808210436.838995-5-andrew@lunn.ch
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
When the netdev trigger is activates, it tries to determine what
device the LED blinks for, and what the current blink mode is.
The documentation for hw_control_get() says:
* Return 0 on success, a negative error number on failing parsing the
* initial mode. Error from this function is NOT FATAL as the device
* may be in a not supported initial state by the attached LED trigger.
*/
For the Marvell PHY and the Armada 370-rd board, the initial LED blink
mode is not supported by the trigger, so it returns an error. This
resulted in not getting the device the LED is blinking for. As a
result, the device is unknown and offloaded is never performed.
Change to condition to always get the device if offloading is
supported, and reduce the scope of testing for an error from
hw_control_get() to skip setting trigger internal state if there is an
error.
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Daniel Golle <daniel@makrotopia.org>
Link: https://lore.kernel.org/r/20230808210436.838995-2-andrew@lunn.ch
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds
Pull LED updates from Lee Jones:
"New Drivers:
- Add support for Intel Cherry Trail Whiskey Cove PMIC LEDs
- Add support for Awinic AW20036/AW20054/AW20072 LEDs
New Device Support:
- Add support for PMI632 LPG to QCom LPG
- Add support for PMI8998 to QCom Flash
- Add support for MT6331, WLEDs and MT6332 to Mediatek MT6323 PMIC
New Functionality:
- Implement the LP55xx Charge Pump
- Add support for suspend / resume to Intel Cherry Trail Whiskey Cove PMIC
- Add support for breathing mode to Intel Cherry Trail Whiskey Cove PMIC
- Enable per-pin resolution Pinctrl in LEDs GPIO
Fix-ups:
- Allow thread to sleep by switching from spinlock to mutex
- Add lots of Device Tree bindings / support
- Adapt relationships / dependencies driven by Kconfig
- Switch I2C drivers from .probe_new() to .probe()
- Remove superfluous / duplicate code
- Replace strlcpy() with strscpy() for efficiency and overflow prevention
- Staticify various functions
- Trivial: Fixing coding style
- Simplify / reduce code
Bug Fixes:
- Prevent NETDEV_LED_MODE_LINKUP from being cleared on rename
- Repair race between led_set_brightness(LED_{OFF,FULL})
- Fix Oops relating to sleeping in critical sections
- Clear LED_INIT_DEFAULT_TRIGGER flag when clearing the current trigger
- Do not leak resources in error handling paths
- Fix unsigned comparison which can never be negative
- Provide missing NULL terminating entries in tables
- Fix misnaming issues"
* tag 'leds-next-6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (53 commits)
leds: leds-mt6323: Adjust return/parameter types in wled get/set callbacks
leds: sgm3140: Add richtek,rt5033-led compatible
dt-bindings: leds: sgm3140: Document richtek,rt5033 compatible
dt-bindings: backlight: kinetic,ktz8866: Add missing type for "current-num-sinks"
dt-bindings: leds: Drop unneeded quotes
leds: Fix config reference for AW200xx driver
leds: leds-mt6323: Add support for WLEDs and MT6332
leds: leds-mt6323: Add support for MT6331 leds
leds: leds-mt6323: Open code and drop MT6323_CAL_HW_DUTY macro
leds: leds-mt6323: Drop MT6323_ prefix from macros and defines
leds: leds-mt6323: Specify registers and specs in platform data
dt-bindings: leds: leds-mt6323: Document mt6332 compatible
dt-bindings: leds: leds-mt6323: Document mt6331 compatible
leds: simatic-ipc-leds-gpio: Introduce more Kconfig switches
leds: simatic-ipc-leds-gpio: Split up into multiple drivers
leds: simatic-ipc-leds-gpio: Move two extra gpio pins into another table
leds: simatic-ipc-leds-gpio: Add terminating entries to gpio tables
leds: flash: leds-qcom-flash: Fix an unsigned comparison which can never be negative
leds: cht-wcove: Remove unneeded semicolon
leds: cht-wcove: Fix an unsigned comparison which can never be negative
...
|
|
Expose hw_control status via sysfs for the netdev trigger to give
userspace better understanding of the current state of the trigger and
the LED.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Acked-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Add additional modes for specific link duplex. Use ethtool APIs to get the
current link duplex and enable the LED accordingly. Under netdev event
handler the rtnl lock is already held and is not needed to be set to
access ethtool APIs.
This is especially useful for PHY and Switch that supports LEDs hw
control for specific link duplex.
Add additional modes:
- half_duplex: Turn on LED when link is half duplex
- full_duplex: Turn on LED when link is full duplex
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Add additional modes for specific link speed. Use ethtool APIs to get the
current link speed and enable the LED accordingly. Under netdev event
handler the rtnl lock is already held and is not needed to be set to
access ethtool APIs.
This is especially useful for PHY and Switch that supports LEDs hw
control for specific link speed. (example scenario a PHY that have 2 LED
connected one green and one orange where the green is turned on with
1000mbps speed and orange is turned on with 10mpbs speed)
On mode set from sysfs we check if we have enabled split link speed mode
and reject enabling generic link mode to prevent wrong and redundant
configuration.
Rework logic on the set baseline state to support these new modes to
select if we need to turn on or off the LED.
Add additional modes:
- link_10: Turn on LED when link speed is 10mbps
- link_100: Turn on LED when link speed is 100mbps
- link_1000: Turn on LED when link speed is 1000mbps
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The qca8k_cled_hw_control_get() function which implements ->hw_control_get
sets the appropriate bits but does not clear them. This leads to an
uninitialized variable bug. Fix this by setting mode to zero at the
start.
Fixes: e0256648c831 ("net: dsa: qca8k: implement hw_control ops")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Lee Jones <lee@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Expose netdev trigger modes to make them accessible by LED driver that
will support netdev trigger for hw control.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
On netdev trigger activation, hw control may be already active by
default. If this is the case and a device is actually provided by
hw_control_get_device(), init the already active mode and set the
bool to hw_control bool to true to reflect the already set mode in the
trigger_data.
Co-developed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The netdev which the LED should blink for is configurable in
/sys/class/led/foo/device_name. Ensure when offloading that the
configured netdev is the same as the netdev the LED is associated
with. If it is not, only perform software blinking.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Add support for LED hw control for the netdev trigger.
The trigger on calling set_baseline_state to configure a new mode, will
do various check to verify if hw control can be used for the requested
mode in can_hw_control() function.
It will first check if the LED driver supports hw control for the netdev
trigger, then will use hw_control_is_supported() and finally will call
hw_control_set() to apply the requested mode.
To use such mode, interval MUST be set to the default value and net_dev
MUST be set. If one of these 2 value are not valid, hw control will
never be used and normal software fallback is used.
The default interval value is moved to a define to make sure they are
always synced.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Reject interval store with hw_control enabled. It's are currently not
supported and MUST be set to the default value with hw control enabled.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Add basic check for hw control support. Check if the required API are
defined and check if the defined trigger supported in hw control for the
LED driver match netdev.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Introduce function to check if the requested mode can use hw control in
preparation for hw control support. Currently everything is handled in
software so can_hw_control will always return false.
Add knob with the new value hw_control in trigger_data struct to
set hw control possible. Useful for future implementation to implement
in set_baseline_state() the required function to set the requested mode
using LEDs hw control ops and in other function to reject set if hw
control is currently active.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Move the code into a helper, ready for it to be called at
other times. No intended behaviour change.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
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 <abaci@linux.alibaba.com>
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=4929
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Link: https://lore.kernel.org/r/20230511070820.52731-1-yang.lee@linux.alibaba.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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 <hdegoede@redhat.com>
Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Tested-by: Yauhen Kharuzhy <jekhor@gmail.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Acked-by: Florian Westphal <fw@strlen.de>
Link: https://lore.kernel.org/r/20230510162234.291439-2-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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 <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230419210743.3594-6-ansuelsmth@gmail.com
|
|
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 <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230419210743.3594-5-ansuelsmth@gmail.com
|
|
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 <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230419210743.3594-4-ansuelsmth@gmail.com
|
|
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 <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230419210743.3594-3-ansuelsmth@gmail.com
|
|
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: stable@vger.kernel.org # v5.5+
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230419210743.3594-2-ansuelsmth@gmail.com
|
|
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 <pavel@ucw.cz>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230314210059.419159-1-linus.walleij@linaro.org
|
|
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 <clabbe@baylibre.com>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230131140304.626779-2-clabbe@baylibre.com
|
|
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/20221123201306.823305113@linutronix.de/
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Acked-by: Pavel Machek <pavel@ucw.cz> [ LED ]
Acked-by: Kalle Valo <kvalo@kernel.org> [ wireless ]
Acked-by: Paolo Abeni <pabeni@redhat.com> [ networking ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Replace the open-code with sysfs_emit() to simplify the code.
Signed-off-by: ye xingchen <ye.xingchen@zte.com.cn>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
|
|
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 <bigeasy@linutronix.de>
Link: https://lkml.kernel.org/r/20210924111501.m57cwwn7ahiyxxdd@linutronix.de
Signed-off-by: Pavel Machek <pavel@ucw.cz>
|
|
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 <lukas.bulwahn@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
|
|
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 <tiwai@suse.de>
Fixes: faa2541f5b1a ("leds: trigger: Introduce audio mute LED trigger")
Reviewed-by: Marek Behún <kabel@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
|
|
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
...
|
|
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.
[akpm@linux-foundation.org: thread_info.h needs limits.h]
[andriy.shevchenko@linux.intel.com: ia64 fix]
Link: https://lkml.kernel.org/r/20210520130557.55277-1-andriy.shevchenko@linux.intel.com
Link: https://lkml.kernel.org/r/20210511074137.33666-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Co-developed-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Mike Rapoport <rppt@linux.ibm.com>
Acked-by: Corey Minyard <cminyard@mvista.com>
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Wei Liu <wei.liu@kernel.org>
Acked-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Sebastian Reichel <sre@kernel.org>
Acked-by: Luis Chamberlain <mcgrof@kernel.org>
Acked-by: Stephen Boyd <sboyd@kernel.org>
Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Acked-by: Helge Deller <deller@gmx.de> # parisc
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
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 <pavel@ucw.cz>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Bryan Wu <bryan.wu@canonical.com>
Cc: linux-leds@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
|
|
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
|
|
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 <tiantao6@hisilicon.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
