| Age | Commit message (Collapse) | Author |
|---|
|
Generalize turn_off_channels function as the implementation is the same for
most of the lp55xx based LED driver.
Suggested-by: Lee Jones <lee@kernel.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-14-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Generalize set_led_current function as the implementation is the same for
most of the lp55xx based LED driver.
Suggested-by: Lee Jones <lee@kernel.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-13-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Generalize multicolor_brightness function as the implementation is the
same for most of the lp55xx based LED driver.
Suggested-by: Lee Jones <lee@kernel.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-12-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Generalize led_brightness function as the implementation is the same for
most of the lp55xx based LED driver.
Introduce a new option in device_config, reg_led_pwm_base since the reg
value is not the same for every LED chip.
Suggested-by: Lee Jones <lee@kernel.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-11-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Generalize firmware_loaded function as lp55xx based LED driver all share
the same logic.
Suggested-by: Lee Jones <lee@kernel.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-10-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
LED Driver based on lp55xx all use the same logic to write memory in
SMEM. The only difference is that legacy chip doesn't support pages and
have the engine regs one after another.
To handle this apply the same logic used for load_engine also for
update_program_memory.
Introduce a new config in device_config, base_prog. For LED chip
that doesn't support pages, offset this values of 32 for each engine.
Update all lp55xx based LED driver to use this new function and define
all the required bits.
Suggested-by: Lee Jones <lee@kernel.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-9-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Generalize run_engine function for lp55xx based LED driver. The logic is
similar to every LED driver, rework it with more macro magic and account
for LED model that might have OP MODE and EXEC at base offset in the
reg.
Update any lp55xx based LED driver to use this generalized function and
declare required bits.
Suggested-by: Lee Jones <lee@kernel.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-8-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Generalize load_engine_and_select_page by reworking the implementation
and making it part of the generic load_engine function.
Add a new option in device_config, pages_per_engine used to define pages
assigned to each engine. With this option set, it's assumed LED chip
supports pages and load_engine will correctly setup the write page.
An equal amount of pages is assigned to each engine and they are
assigned from page 0.
Update any lp55xx based LED driver to define the option and use the new
function.
Suggested-by: Lee Jones <lee@kernel.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-7-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
LED driver based on lp55xx have all a very similar implementation for
load_engine function. Move the function to lp55xx-common and rework the
define to be more dynamic instead of having to declare a temp array for
them.
Engine mask are the same for every LED based on lp55xx.
Suggested-by: Lee Jones <lee@kernel.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-6-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Now that stop_all_engine is generalized, probe and remove function are
the same across every lp55xx based LED driver and can be generalized.
To permit to use a common probe, make use of the OF match_data and i2c
driver_data value to store the device_config struct specific for the
LED.
Also drop the now unused exported symbol in lp55xx-common and make them
static.
Update any lp55xx based LED driver to use the new generic probe/remove.
Suggested-by: Lee Jones <lee@kernel.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-5-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
In all the lp55xx based driver, we have a similar implementation of the
stop_all_engine function with the only difference of the required sleep
for the OP MODE change.
The main difference is legacy LEDs require a min of 152 us while new one
use a generic 1-2ms. The new one use a 1-2ms sleep as suggested in the
datasheet IN ALTERNATIVE to a much more robust approach by using the
newly introduced ENGINE_BUSY bit in the STATUS reg.
To better handle sleep after OP MODE change, add support for polling the
ENGINE_BUSY bit and use the legacy sleep for old LEDs.
With this change, stop_all_engine can be generalized and moved to
lp55xx-common.
To make more clear the double usage of lp55xx_reg, define a union for
additional scope of mask and shift.
Update all lp55xx based driver to use the new generalized function and
define the required bits in the device_config struct.
Suggested-by: Lee Jones <lee@kernel.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-4-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
The SY7802 is a current-regulated charge pump which can regulate two
current levels for Flash and Torch modes.
It is a high-current synchronous boost converter with 2-channel high
side current sources. Each channel is able to deliver 900mA current.
Acked-by: Lee Jones <lee@kernel.org>
Signed-off-by: André Apitzsch <git@apitzsch.eu>
Link: https://lore.kernel.org/r/20240624-sy7802-v5-2-7abc9d96bfa6@apitzsch.eu
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Default blinking period is set to 2s. This is too long to be handled by
the hardware (maximum is 1.69s).
Set the default blinking period to 1s to match what is done in the
other LED drivers.
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
Link: https://lore.kernel.org/r/20240617143910.154546-5-bastien.curutchet@bootlin.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
When a LED is used to drive a beeper, it uses PWM1. This can cause
conflicts if an other LED want to use PWM1 for blinking.
Disable use of hardware for blinking when one or more LEDs are used to
drive beepers.
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
Link: https://lore.kernel.org/r/20240617143910.154546-4-bastien.curutchet@bootlin.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
PSC0/PWM0 are used by all LEDs for brightness and blinking. This causes
conflicts when you set a brightness of a new LED while an other one is
already using PWM0 for blinking.
Use PSC1/PWM1 for blinking.
Check that no other LED is already blinking with a different PSC1/PWM1
configuration to avoid conflict.
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
Link: https://lore.kernel.org/r/20240617143910.154546-3-bastien.curutchet@bootlin.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Two tables are used to configure the PWM and PSC registers of the two
PWM available in the pca9532. Magic numbers are used to access this table
instead of defines.
Add defines PCA9532_PWM_ID_0 and PCA9532_PWM_ID_1 and use them in place of
these magic numbers.
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
Link: https://lore.kernel.org/r/20240617143910.154546-2-bastien.curutchet@bootlin.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
The input subsystem registers LEDs with default triggers while holding
the input_lock and input_register_handler() takes the input_lock this
means that a triggers activate method cannot directly call
input_register_handler() as the old ledtrig-input-events code is doing.
The initial implementation of the input-events trigger mainly did not use
the simple LED trigger mechanism because that mechanism had an issue with
the initial state of a newly activated LED not matching the last
led_trigger_event() call for the trigger. This issue has been fixed in
commit 822c91e72eac ("leds: trigger: Store brightness set by
led_trigger_event()").
Rewrite the "input-events" trigger to use the simple LED trigger mechanism,
registering a single input_handler at module_init() time and using
led_trigger_event() to set the brightness for all LEDs controlled by this
trigger.
Compared to the old code this looses the ability for the user to configure
a different brightness for the on state then LED_FULL, this is standard for
simple LED triggers and since this trigger is only in for-leds-next ATM
losing that functionality is not a regression.
This also changes the configurability of the LED off timeout from a per
LED setting to a global setting (runtime modifiable module-parameter).
Switching to registering a single input_handler at module_init() time fixes
the following locking issue reported by lockdep:
[ 2840.220145] usb 1-1.3: new low-speed USB device number 3 using xhci_hcd
[ 2840.307172] usb 1-1.3: New USB device found, idVendor=0603, idProduct=0002, bcdDevice= 2.21
[ 2840.307375] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 2840.307423] usb 1-1.3: Product: USB Composite Device
[ 2840.307456] usb 1-1.3: Manufacturer: SINO WEALTH
[ 2840.333985] input: SINO WEALTH USB Composite Device as /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.3/1-1.3:1.0/0003:0603:0002.0007/input/input19
[ 2840.386545] ======================================================
[ 2840.386549] WARNING: possible circular locking dependency detected
[ 2840.386554] 6.10.0-rc1+ #97 Tainted: G C E
[ 2840.386558] ------------------------------------------------------
[ 2840.386562] kworker/1:1/52 is trying to acquire lock:
[ 2840.386566] ffff98fcf1629300 (&led_cdev->led_access){+.+.}-{3:3}, at: led_classdev_register_ext+0x1c6/0x380
[ 2840.386590]
but task is already holding lock:
[ 2840.386593] ffffffff88130cc8 (input_mutex){+.+.}-{3:3}, at: input_register_device.cold+0x47/0x150
[ 2840.386608]
which lock already depends on the new lock.
[ 2840.386611]
the existing dependency chain (in reverse order) is:
[ 2840.386615]
-> #3 (input_mutex){+.+.}-{3:3}:
[ 2840.386624] __mutex_lock+0x8c/0xc10
[ 2840.386634] input_register_handler+0x1c/0xf0
[ 2840.386641] 0xffffffffc142c437
[ 2840.386655] led_trigger_set+0x1e1/0x2e0
[ 2840.386661] led_trigger_register+0x170/0x1b0
[ 2840.386666] do_one_initcall+0x5e/0x3a0
[ 2840.386675] do_init_module+0x60/0x220
[ 2840.386683] __do_sys_init_module+0x15f/0x190
[ 2840.386689] do_syscall_64+0x93/0x180
[ 2840.386696] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 2840.386705]
-> #2 (&led_cdev->trigger_lock){+.+.}-{3:3}:
[ 2840.386714] down_write+0x3b/0xd0
[ 2840.386720] led_trigger_register+0x12c/0x1b0
[ 2840.386725] rfkill_register+0xec/0x340 [rfkill]
[ 2840.386739] wiphy_register+0x82a/0x930 [cfg80211]
[ 2840.386907] brcmf_cfg80211_attach+0xcbd/0x1430 [brcmfmac]
[ 2840.386952] brcmf_attach+0x1ba/0x4c0 [brcmfmac]
[ 2840.386991] brcmf_pcie_setup+0x899/0xc70 [brcmfmac]
[ 2840.387030] brcmf_fw_request_done+0x13b/0x180 [brcmfmac]
[ 2840.387070] request_firmware_work_func+0x3b/0x70
[ 2840.387078] process_one_work+0x21a/0x590
[ 2840.387085] worker_thread+0x1d1/0x3e0
[ 2840.387090] kthread+0xee/0x120
[ 2840.387096] ret_from_fork+0x30/0x50
[ 2840.387105] ret_from_fork_asm+0x1a/0x30
[ 2840.387112]
-> #1 (leds_list_lock){++++}-{3:3}:
[ 2840.387123] down_write+0x3b/0xd0
[ 2840.387129] led_classdev_register_ext+0x29e/0x380
[ 2840.387134] 0xffffffffc0e6b74c
[ 2840.387143] platform_probe+0x40/0xa0
[ 2840.387151] really_probe+0xde/0x340
[ 2840.387157] __driver_probe_device+0x78/0x110
[ 2840.387162] driver_probe_device+0x1f/0xa0
[ 2840.387168] __driver_attach+0xba/0x1c0
[ 2840.387173] bus_for_each_dev+0x6b/0xb0
[ 2840.387180] bus_add_driver+0x111/0x1f0
[ 2840.387185] driver_register+0x6e/0xc0
[ 2840.387191] do_one_initcall+0x5e/0x3a0
[ 2840.387197] do_init_module+0x60/0x220
[ 2840.387204] __do_sys_init_module+0x15f/0x190
[ 2840.387210] do_syscall_64+0x93/0x180
[ 2840.387217] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 2840.387224]
-> #0 (&led_cdev->led_access){+.+.}-{3:3}:
[ 2840.387233] __lock_acquire+0x11c6/0x1f20
[ 2840.387239] lock_acquire+0xc8/0x2b0
[ 2840.387244] __mutex_lock+0x8c/0xc10
[ 2840.387251] led_classdev_register_ext+0x1c6/0x380
[ 2840.387256] input_leds_connect+0x139/0x260
[ 2840.387262] input_attach_handler.isra.0+0x75/0x90
[ 2840.387268] input_register_device.cold+0xa1/0x150
[ 2840.387274] hidinput_connect+0x848/0xb00
[ 2840.387280] hid_connect+0x567/0x5a0
[ 2840.387288] hid_hw_start+0x3f/0x60
[ 2840.387294] hid_device_probe+0x10d/0x190
[ 2840.387298] really_probe+0xde/0x340
[ 2840.387304] __driver_probe_device+0x78/0x110
[ 2840.387309] driver_probe_device+0x1f/0xa0
[ 2840.387314] __device_attach_driver+0x85/0x110
[ 2840.387320] bus_for_each_drv+0x78/0xc0
[ 2840.387326] __device_attach+0xb0/0x1b0
[ 2840.387332] bus_probe_device+0x94/0xb0
[ 2840.387337] device_add+0x64a/0x860
[ 2840.387343] hid_add_device+0xe5/0x240
[ 2840.387349] usbhid_probe+0x4bb/0x600
[ 2840.387356] usb_probe_interface+0xea/0x2b0
[ 2840.387363] really_probe+0xde/0x340
[ 2840.387368] __driver_probe_device+0x78/0x110
[ 2840.387373] driver_probe_device+0x1f/0xa0
[ 2840.387378] __device_attach_driver+0x85/0x110
[ 2840.387383] bus_for_each_drv+0x78/0xc0
[ 2840.387390] __device_attach+0xb0/0x1b0
[ 2840.387395] bus_probe_device+0x94/0xb0
[ 2840.387400] device_add+0x64a/0x860
[ 2840.387405] usb_set_configuration+0x5e8/0x880
[ 2840.387411] usb_generic_driver_probe+0x3e/0x60
[ 2840.387418] usb_probe_device+0x3d/0x120
[ 2840.387423] really_probe+0xde/0x340
[ 2840.387428] __driver_probe_device+0x78/0x110
[ 2840.387434] driver_probe_device+0x1f/0xa0
[ 2840.387439] __device_attach_driver+0x85/0x110
[ 2840.387444] bus_for_each_drv+0x78/0xc0
[ 2840.387451] __device_attach+0xb0/0x1b0
[ 2840.387456] bus_probe_device+0x94/0xb0
[ 2840.387461] device_add+0x64a/0x860
[ 2840.387466] usb_new_device.cold+0x141/0x38f
[ 2840.387473] hub_event+0x1166/0x1980
[ 2840.387479] process_one_work+0x21a/0x590
[ 2840.387484] worker_thread+0x1d1/0x3e0
[ 2840.387488] kthread+0xee/0x120
[ 2840.387493] ret_from_fork+0x30/0x50
[ 2840.387500] ret_from_fork_asm+0x1a/0x30
[ 2840.387506]
other info that might help us debug this:
[ 2840.387509] Chain exists of:
&led_cdev->led_access --> &led_cdev->trigger_lock --> input_mutex
[ 2840.387520] Possible unsafe locking scenario:
[ 2840.387523] CPU0 CPU1
[ 2840.387526] ---- ----
[ 2840.387529] lock(input_mutex);
[ 2840.387534] lock(&led_cdev->trigger_lock);
[ 2840.387540] lock(input_mutex);
[ 2840.387545] lock(&led_cdev->led_access);
[ 2840.387550]
*** DEADLOCK ***
[ 2840.387552] 7 locks held by kworker/1:1/52:
[ 2840.387557] #0: ffff98fcc1d07148 ((wq_completion)usb_hub_wq){+.+.}-{0:0}, at: process_one_work+0x4af/0x590
[ 2840.387570] #1: ffffb67e00213e60 ((work_completion)(&hub->events)){+.+.}-{0:0}, at: process_one_work+0x1d5/0x590
[ 2840.387583] #2: ffff98fcc6582190 (&dev->mutex){....}-{3:3}, at: hub_event+0x57/0x1980
[ 2840.387596] #3: ffff98fccb3c6990 (&dev->mutex){....}-{3:3}, at: __device_attach+0x26/0x1b0
[ 2840.387610] #4: ffff98fcc5260960 (&dev->mutex){....}-{3:3}, at: __device_attach+0x26/0x1b0
[ 2840.387622] #5: ffff98fce3999a20 (&dev->mutex){....}-{3:3}, at: __device_attach+0x26/0x1b0
[ 2840.387635] #6: ffffffff88130cc8 (input_mutex){+.+.}-{3:3}, at: input_register_device.cold+0x47/0x150
[ 2840.387649]
stack backtrace:
[ 2840.387653] CPU: 1 PID: 52 Comm: kworker/1:1 Tainted: G C E 6.10.0-rc1+ #97
[ 2840.387659] Hardware name: Xiaomi Inc Mipad2/Mipad, BIOS MIPad-P4.X64.0043.R03.1603071414 03/07/2016
[ 2840.387665] Workqueue: usb_hub_wq hub_event
[ 2840.387674] Call Trace:
[ 2840.387681] <TASK>
[ 2840.387689] dump_stack_lvl+0x68/0x90
[ 2840.387700] check_noncircular+0x10d/0x120
[ 2840.387710] ? register_lock_class+0x38/0x480
[ 2840.387717] ? check_noncircular+0x74/0x120
[ 2840.387727] __lock_acquire+0x11c6/0x1f20
[ 2840.387736] lock_acquire+0xc8/0x2b0
[ 2840.387743] ? led_classdev_register_ext+0x1c6/0x380
[ 2840.387753] __mutex_lock+0x8c/0xc10
[ 2840.387760] ? led_classdev_register_ext+0x1c6/0x380
[ 2840.387766] ? _raw_spin_unlock_irqrestore+0x35/0x60
[ 2840.387773] ? klist_next+0x158/0x160
[ 2840.387781] ? led_classdev_register_ext+0x1c6/0x380
[ 2840.387787] ? lockdep_init_map_type+0x58/0x250
[ 2840.387796] ? led_classdev_register_ext+0x1c6/0x380
[ 2840.387802] led_classdev_register_ext+0x1c6/0x380
[ 2840.387810] ? kvasprintf+0x70/0xb0
[ 2840.387820] ? kasprintf+0x3e/0x50
[ 2840.387829] input_leds_connect+0x139/0x260
[ 2840.387838] input_attach_handler.isra.0+0x75/0x90
[ 2840.387846] input_register_device.cold+0xa1/0x150
[ 2840.387854] hidinput_connect+0x848/0xb00
[ 2840.387862] ? usbhid_start+0x45b/0x7b0
[ 2840.387870] hid_connect+0x567/0x5a0
[ 2840.387878] ? __mutex_unlock_slowpath+0x2d/0x260
[ 2840.387891] hid_hw_start+0x3f/0x60
[ 2840.387899] hid_device_probe+0x10d/0x190
[ 2840.387906] ? __pfx___device_attach_driver+0x10/0x10
[ 2840.387913] really_probe+0xde/0x340
[ 2840.387919] ? pm_runtime_barrier+0x50/0x90
[ 2840.387927] __driver_probe_device+0x78/0x110
[ 2840.387934] driver_probe_device+0x1f/0xa0
[ 2840.387941] __device_attach_driver+0x85/0x110
[ 2840.387949] bus_for_each_drv+0x78/0xc0
[ 2840.387959] __device_attach+0xb0/0x1b0
[ 2840.387967] bus_probe_device+0x94/0xb0
[ 2840.387974] device_add+0x64a/0x860
[ 2840.387982] ? __debugfs_create_file+0x14a/0x1c0
[ 2840.387993] hid_add_device+0xe5/0x240
[ 2840.388002] usbhid_probe+0x4bb/0x600
[ 2840.388013] usb_probe_interface+0xea/0x2b0
[ 2840.388021] ? __pfx___device_attach_driver+0x10/0x10
[ 2840.388028] really_probe+0xde/0x340
[ 2840.388034] ? pm_runtime_barrier+0x50/0x90
[ 2840.388040] __driver_probe_device+0x78/0x110
[ 2840.388048] driver_probe_device+0x1f/0xa0
[ 2840.388055] __device_attach_driver+0x85/0x110
[ 2840.388062] bus_for_each_drv+0x78/0xc0
[ 2840.388071] __device_attach+0xb0/0x1b0
[ 2840.388079] bus_probe_device+0x94/0xb0
[ 2840.388086] device_add+0x64a/0x860
[ 2840.388094] ? __mutex_unlock_slowpath+0x2d/0x260
[ 2840.388103] usb_set_configuration+0x5e8/0x880
[ 2840.388114] ? __pfx___device_attach_driver+0x10/0x10
[ 2840.388121] usb_generic_driver_probe+0x3e/0x60
[ 2840.388129] usb_probe_device+0x3d/0x120
[ 2840.388137] really_probe+0xde/0x340
[ 2840.388142] ? pm_runtime_barrier+0x50/0x90
[ 2840.388149] __driver_probe_device+0x78/0x110
[ 2840.388156] driver_probe_device+0x1f/0xa0
[ 2840.388163] __device_attach_driver+0x85/0x110
[ 2840.388171] bus_for_each_drv+0x78/0xc0
[ 2840.388180] __device_attach+0xb0/0x1b0
[ 2840.388188] bus_probe_device+0x94/0xb0
[ 2840.388195] device_add+0x64a/0x860
[ 2840.388202] ? lockdep_hardirqs_on+0x78/0x100
[ 2840.388210] ? _raw_spin_unlock_irqrestore+0x35/0x60
[ 2840.388219] usb_new_device.cold+0x141/0x38f
[ 2840.388227] hub_event+0x1166/0x1980
[ 2840.388242] process_one_work+0x21a/0x590
[ 2840.388249] ? move_linked_works+0x70/0xa0
[ 2840.388260] worker_thread+0x1d1/0x3e0
[ 2840.388268] ? __pfx_worker_thread+0x10/0x10
[ 2840.388273] kthread+0xee/0x120
[ 2840.388279] ? __pfx_kthread+0x10/0x10
[ 2840.388287] ret_from_fork+0x30/0x50
[ 2840.388294] ? __pfx_kthread+0x10/0x10
[ 2840.388301] ret_from_fork_asm+0x1a/0x30
[ 2840.388315] </TASK>
[ 2840.415630] hid-generic 0003:0603:0002.0007: input,hidraw6: USB HID v1.10 Keyboard [SINO WEALTH USB Composite Device] on usb-0000:00:14.0-1.3/input0
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240602160203.27339-2-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Use __free for device_node values, and thus drop calls to
of_node_put.
The variable attribute __free adds a scope based cleanup to
the device node. The goal is to reduce memory management issues
in the kernel code.
The of_node_put calls were removed, and the
for_each_available_child_of_node was replaced to the equivalent
for_each_available_child_of_node_scoped which use the __free.
Suggested-by: Julia Lawall <julia.lawall@inria.fr>
Signed-off-by: MarileneGarcia <marilene.agarcia@gmail.com>
Link: https://lore.kernel.org/r/20240601031713.1307859-1-marilene.agarcia@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
The fwnode_for_each_child_node() loop requires manual intervention to
decrement the child refcount in case of an early return.
Add the missing calls to fwnode_handle_put(child) to avoid memory leaks
in the error paths.
Cc: stable@vger.kernel.org
Fixes: 679f8652064b ("leds: Add mt6360 driver")
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Link: https://lore.kernel.org/r/20240611-leds-mt6360-memleak-v1-1-93642eb5011e@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Use __free() for device_node values, and thus drop calls to
of_node_put().
The variable attribute __free() adds a scope based cleanup to
the device node. The goal is to reduce memory management issues
in the kernel code.
The for_each_available_child_of_node() was replaced to the equivalent
for_each_available_child_of_node_scoped() which uses the __free().
Suggested-by: Julia Lawall <julia.lawall@inria.fr>
Signed-off-by: Marilene A Garcia <marilene.agarcia@gmail.com>
Link: https://lore.kernel.org/r/20240611001740.10490-1-marilene.agarcia@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Currently, all LED LPG devices will call lpg_{set,clear}_pbs_trigger()
when setting brightness regardless of if they support PPG and have PBS
triggers. Check if device supports PPG before setting/clearing PBS
triggers.
Fixes: 6ab1f766a80a ("leds: rgb: leds-qcom-lpg: Add support for PPG through single SDAM")
Fixes: 5e9ff626861a ("leds: rgb: leds-qcom-lpg: Include support for PPG with dedicated LUT SDAM")
Signed-off-by: Anjelique Melendez <quic_amelende@quicinc.com>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20240607005250.4047135-1-quic_amelende@quicinc.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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>
|
|
There is no code that uses ID table directly, except the
struct device_driver at the end of the file. Hence, move
table closer to its user. It's always possible to access
them via a pointer.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20240606173037.3091598-7-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses mutex which was destroyed already
in module's remove() so use devm API instead.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20240606173037.3091598-6-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
We have a temporary variable to keep a pointer to struct device.
Utilise it where it makes sense.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20240606173037.3091598-5-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Convert the module to be property provider agnostic and allow
it to be used on non-OF platforms.
Add mod_devicetable.h include.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20240606173037.3091598-4-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
LED core provides a helper to parse default state from firmware node.
Use it instead of custom implementation.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20240606173037.3091598-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Add a missing call to of_node_put(np) on error.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20240606173037.3091598-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Add a label so that a bit of exception handling can be better reused
at the end of this function implementation.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Link: https://lore.kernel.org/r/5faec5de-fc36-4b38-abcb-c61954a824cd@web.de
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
trigger only
If both set_brightness functions return -ENOTSUPP, then the LED doesn't
support setting a fixed brightness value, and the error message isn't
helpful. This can be the case e.g. for LEDs supporting a specific hw
trigger only.
Pinched the subject line and commit message from Heiner:
Link: https://lore.kernel.org/all/44177e37-9512-4044-8991-bb23b184bf37@gmail.com/
Reworked the function to provide Heiner's required semantics whilst
simultaneously increasing readability and flow.
Cc: Pavel Machek <pavel@ucw.cz>
Cc: linux-leds@vger.kernel.org
Suggested-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Add a new trigger which turns LEDs on when there is input
(/dev/input/event*) activity and turns them back off again after there has
been no activity for 5 seconds.
This is primarily intended to control LED devices which are a backlight for
capacitive touch-buttons, such as e.g. the menu / home / back buttons found
on the bottom bezel of many somewhat older smartphones and tablets.
This can also be used to turn on the keyboard backlight LED on input
events and turn the keyboard backlight off again when idle.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240531135910.168965-2-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
ich7_lpc_probe() uses pci_read_config_dword() that returns PCIBIOS_*
codes. The error handling code assumes incorrectly it's a normal errno
and checks for < 0. The return code is returned from the probe function
as is but probe functions should return normal errnos.
Remove < 0 from the check and convert PCIBIOS_* returns code using
pcibios_err_to_errno() into normal errno before returning it.
Fixes: a328e95b82c1 ("leds: LED driver for Intel NAS SS4200 series (v5)")
Cc: <stable@vger.kernel.org>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20240527132700.14260-1-ilpo.jarvinen@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Fix the 'make W=1" issue:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/blink/leds-bcm63138.o
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://lore.kernel.org/r/20240517-md-leds-bcm63138-v1-1-247b7302edb6@quicinc.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Fix the 'make W=1' issues:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/simple/simatic-ipc-leds-gpio-apollolake.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/simple/simatic-ipc-leds-gpio-core.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/simple/simatic-ipc-leds-gpio-elkhartlake.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/simple/simatic-ipc-leds-gpio-f7188x.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/simple/simatic-ipc-leds.o
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Link: https://lore.kernel.org/r/20240517-md-simatic-ipc-v1-1-bbbd199262b8@quicinc.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Fix the 'make W=1" issue:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/flash/leds-rt4505.o
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Link: https://lore.kernel.org/r/20240517-md-leds-rt4505-v1-1-2f388ff6b672@quicinc.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
These drivers don't use the driver_data member of struct i2c_device_id,
so don't explicitly initialize this member.
This prepares putting driver_data in an anonymous union which requires
either no initialization or named designators. But it's also a nice
cleanup on its own.
While add it, also remove commas after the sentinel entries.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20240522165358.62238-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Some triggers call led_trigger_event() from their activate() callback
to initialize the brightness of the LED for which the trigger is being
activated.
In order for the LED's initial state to be set correctly this requires that
the led_trigger_event() call uses the new version of trigger->led_cdevs,
which has the new LED.
AFAICT led_trigger_event() will always use the new version when it is
running on the same CPU as where the list_add_tail_rcu() call was made,
which is why the missing synchronize_rcu() has not lead to bug reports.
But if activate() is pre-empted, sleeps or uses a worker then
the led_trigger_event() call may run on another CPU which may still use
the old trigger->led_cdevs list.
Add a synchronize_rcu() call to ensure that any led_trigger_event() calls
done from activate() always use the new list.
Triggers using led_trigger_event() from their activate() callback are:
net/bluetooth/leds.c, net/rfkill/core.c and drivers/tty/vt/keyboard.c.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240531120124.75662-1-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Triggers which have trigger specific sysfs attributes typically store
related data in trigger-data allocated by the activate() callback and
freed by the deactivate() callback.
Calling device_remove_groups() after calling deactivate() leaves a window
where the sysfs attributes show/store functions could be called after
deactivation and then operate on the just freed trigger-data.
Move the device_remove_groups() call to before deactivate() to close
this race window.
This also makes the deactivation path properly do things in reverse order
of the activation path which calls the activate() callback before calling
device_add_groups().
Fixes: a7e7a3156300 ("leds: triggers: add device attribute support")
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20240504162533.76780-1-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
'is31fl3190_regmap_config' and 'is31fl3196_regmap_config' are not modified
in this diver and are only used as a const struct regmap_config.
Constifying these structures moves some data to a read-only section, so
increase overall security.
On a x86_64, with allmodconfig:
Before:
text data bss dec hex filename
13827 2002 32 15861 3df5 drivers/leds/leds-is31fl319x.o
After:
text data bss dec hex filename
14467 1370 32 15869 3dfd drivers/leds/leds-is31fl319x.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/82a5cb26ff8af1865a790286bdbc3c4a2bd149f1.1714892598.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
'ib-mfd-leds-platform-6.11' into ibs-for-leds-merged
|
|
The ChromeOS Embedded Controller exposes an LED control command.
Expose its functionality through the leds subsystem.
The LEDs are exposed as multicolor devices.
A hardware trigger, which is active by default, is provided to let the
EC itself take over control over the LED.
The driver is designed to be probed via the cros_ec mfd device.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20240613-cros_ec-led-v3-4-500b50f41e0f@weissschuh.net
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
There are no external users left, make the array static.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20240613-cros_ec-led-v3-3-500b50f41e0f@weissschuh.net
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
led_get_color_name() is a safer alternative to led_colors.
led-class-multicolor.c is the only external user of led_colors and its
removal allows unexporting the array.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20240613-cros_ec-led-v3-2-500b50f41e0f@weissschuh.net
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
This is similar to the existing led_colors[] array but is safer to use and
usable by everyone.
Getting string representations of color ids is useful for drivers
which are handling color IDs anyways, for example for the multicolor API.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20240613-cros_ec-led-v3-1-500b50f41e0f@weissschuh.net
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
trigger the default trigger"
Commit 66601a29bb23 ("leds: class: If no default trigger is given, make
hw_control trigger the default trigger") causes ledtrig-netdev to get
set as default trigger on various network LEDs.
This causes users to hit a pre-existing AB-BA deadlock issue in
ledtrig-netdev between the LED-trigger locks and the rtnl mutex,
resulting in hung tasks in kernels >= 6.9.
Solving the deadlock is non trivial, so for now revert the change to
set the hw_control trigger as default trigger, so that ledtrig-netdev
no longer gets activated automatically for various network LEDs.
The netdev trigger is not needed because the network LEDs are usually under
hw-control and the netdev trigger tries to leave things that way so setting
it as the active trigger for the LED class device is a no-op.
Fixes: 66601a29bb23 ("leds: class: If no default trigger is given, make hw_control trigger the default trigger")
Reported-by: Genes Lists <lists@sapience.com>
Closes: https://lore.kernel.org/all/9d189ec329cfe68ed68699f314e191a10d4b5eda.camel@sapience.com/
Reported-by: Johannes Wüller <johanneswueller@gmail.com>
Closes: https://lore.kernel.org/lkml/e441605c-eaf2-4c2d-872b-d8e541f4cf60@gmail.com/
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Lee Jones <lee@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Add a mechanism for drivers to opt-out of the automatic device renaming
on conflicts.
Those drivers will provide their own conflict resolution.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20240526-cros_ec-kbd-led-framework-v3-2-ee577415a521@weissschuh.net
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Other warnings refer to the name after renaming, which is clearer when
that name is mentioned first.
It is also clearer where "ret" comes from.
While at it, also add the necessary newline to the message and fix the
parameter alignment.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20240526-cros_ec-kbd-led-framework-v3-1-ee577415a521@weissschuh.net
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Add a new led_mc_trigger_event() function for triggers which want to
change the color of a multi-color LED based on their trigger conditions.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://lore.kernel.org/r/20240531114124.45346-6-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Add a new led_mc_set_brightness() function for in kernel color/brightness
changing of multi-color LEDs.
led-class-multicolor can be build as a module and led_mc_set_brightness()
will have the builtin callers, so put led_mc_set_brightness() inside
led-core instead, just like how led_set_brightness() is part of the core
and not of the led-class object.
This also adds a new LED_MULTI_COLOR led_classdev flag to allow
led_mc_set_brightness() to verify that it is operating on a multi-color
LED classdev, avoiding casting the passed in LED classdev to a multi-color
LED classdev, when it actually is not a multi-color LED.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://lore.kernel.org/r/20240531114124.45346-5-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
The mutex must be initialized before the LED class device is registered
otherwise there is a race where it may get used before it is initialized:
DEBUG_LOCKS_WARN_ON(lock->magic != lock)
WARNING: CPU: 2 PID: 2045 at kernel/locking/mutex.c:587 __mutex_lock
...
RIP: 0010:__mutex_lock+0x7db/0xc10
...
set_brightness_delayed_set_brightness.part.0+0x17/0x60
set_brightness_delayed+0xf1/0x100
process_one_work+0x222/0x5a0
Move the mutex_init() call earlier to avoid this race condition and
switch to devm_mutex_init() to avoid the need to add error-exit
cleanup to probe() if probe() fails later on.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://lore.kernel.org/r/20240531114124.45346-4-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
