aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2024-06-26regulator: Add Renesas RZ/G2L USB VBUS regulator driverBiju Das3-0/+84
As per the RZ/G2L HW manual, VBUSEN can be controlled by the VBOUT bit of the VBUS Control Register. This register is mapped in the reset framework. The reset driver expose this register as regmap and instantiates this driver. The consumer will use the regulator API to control the VBOUT bit as the control need to be done in the atomic context. Signed-off-by: Biju Das <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-06-26regulator: core: Add helper for allow HW access to enable/disable regulatorBiju Das1-0/+28
Add a helper function that allow regulator consumers to allow low-level HW access, in order to enable/disable regulator in atomic context. The use-case for RZ/G2L SoC is to enable VBUS selection register based on vbus detection that happens in interrupt context. Signed-off-by: Biju Das <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-06-26nvmet-fc: Remove __counted_by from nvmet_fc_tgt_queue.fod[]Nathan Chancellor1-1/+1
Work for __counted_by on generic pointers in structures (not just flexible array members) has started landing in Clang 19 (current tip of tree). During the development of this feature, a restriction was added to __counted_by to prevent the flexible array member's element type from including a flexible array member itself such as: struct foo { int count; char buf[]; }; struct bar { int count; struct foo data[] __counted_by(count); }; because the size of data cannot be calculated with the standard array size formula: sizeof(struct foo) * count This restriction was downgraded to a warning but due to CONFIG_WERROR, it can still break the build. The application of __counted_by on the fod member of 'struct nvmet_fc_tgt_queue' triggers this restriction, resulting in: drivers/nvme/target/fc.c:151:2: error: 'counted_by' should not be applied to an array with element of unknown size because 'struct nvmet_fc_fcp_iod' is a struct type with a flexible array member. This will be an error in a future compiler version [-Werror,-Wbounds-safety-counted-by-elt-type-unknown-size] 151 | struct nvmet_fc_fcp_iod fod[] __counted_by(sqsize); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. Remove this use of __counted_by to fix the warning/error. However, rather than remove it altogether, leave it commented, as it may be possible to support this in future compiler releases. Cc: [email protected] Closes: https://github.com/ClangBuiltLinux/linux/issues/2027 Fixes: ccd3129aca28 ("nvmet-fc: Annotate struct nvmet_fc_tgt_queue with __counted_by") Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Keith Busch <[email protected]>
2024-06-26nvme-multipath: prepare for "queue-depth" iopolicyJohn Meneghini1-6/+15
This patch prepares for the introduction of a new iopolicy by breaking up the nvme_find_path() code path into sub-routines. Signed-off-by: John Meneghini <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Reviewed-by: Chaitanya Kulkarni <[email protected]> Signed-off-by: Keith Busch <[email protected]>
2024-06-26drm/panel: add Ilitek ILI9806E panel driverMichael Walle3-0/+412
The Ortustech COM35H3P70ULC panel is based on the ILI9806E DSI display controller. Co-developed-by: Gunnar Dibbern <[email protected]> Signed-off-by: Gunnar Dibbern <[email protected]> Signed-off-by: Michael Walle <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-26drm/panel: add lincolntech lcd197 supportJerome Brunet3-0/+274
Add support for the Lincoln Technologies LCD197 1080x1920 DSI panel. Signed-off-by: Jerome Brunet <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-26drm/panel: sitronix-st7703: transition to mipi_dsi wrapped functionsTejas Vipin1-436/+400
Use functions introduced in commit 966e397e4f60 ("drm/mipi-dsi: Introduce mipi_dsi_*_write_seq_multi()") and commit f79d6d28d8fe ("drm/mipi-dsi: wrap more functions for streamline handling") for sitronix-st7703 based panels. Signed-off-by: Tejas Vipin <[email protected]> Reviewed-by: Guido Günther <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-26leds: leds-lp5569: Add support for Texas Instruments LP5569Christian Marangi3-3/+558
Add support for Texas Instruments LP5569 LED driver. Texas Instruments LP5569 is 9 channels chip with programmable engines. It almost a copy of LP5523 with fundamental changes to regs order and regs content. Has difference in how the clock is handled and doesn't support detecting clock time automatically, different handling for selftest and different scheme for the status regs. LED chip supports ENGINE and MUX to group LED and run precompiled code with magic values to run patterns. This is loaded via the sysfs entry and it's passed as a string of ASCII HEX char. One some devices using this LED Controller (a NBG7815 Router) it was found loading big precompiled pattern with up to 96 bytes of code. To have support for this "extended" scenario, hardcode each engine to support 4 pages of precompiled pattern (128 bytes of code) and 1 page for each MUX. This gives plenty of space for any kind precompiled pattern keeping simple logic for page handling of each engine and mux. Signed-off-by: Christian Marangi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: leds-lp55xx: Drop deprecated definesChristian Marangi4-116/+0
Drop deprecated defines not used anymore as the related function got moved to lp55xx-common. Signed-off-by: Christian Marangi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: leds-lp55xx: Support ENGINE program up to 128 bytesChristian Marangi4-19/+49
Some LED chip supports up to 16 pages and with some magic they can be divided in 4 page for each ENGINE + 1 for each MUX. Following this we can support bigger programs up to 128 bytes. Rework the update_program_memory function to support program of multiple pages instead of hardcoding it to one page per programs. Signed-off-by: Christian Marangi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: leds-lp55xx: Generalize sysfs master_faderChristian Marangi3-139/+156
Generalize sysfs master_fader since their implementation is the same across some lp55xx based LED driver. Suggested-by: Lee Jones <[email protected]> Signed-off-by: Christian Marangi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: leds-lp55xx: Generalize sysfs engine_ledsChristian Marangi3-129/+131
Generalize sysfs engine_leds since their implementation is the same across some lp55xx based LED driver. While at it simplify the implementation for show_engine_leds. Suggested-by: Lee Jones <[email protected]> Signed-off-by: Christian Marangi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: leds-lp55xx: Generalize sysfs engine_load and engine_modeChristian Marangi4-186/+117
Generalize sysfs engine_load and engine_mode since their implementation is the same acrosso some lp55xx based LED driver. Suggested-by: Lee Jones <[email protected]> Signed-off-by: Christian Marangi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: leds-lp55xx: Generalize stop_engine functionChristian Marangi4-34/+20
Generalize stop_engine function as the implementation is the same for most of the lp55xx based LED driver. Suggested-by: Lee Jones <[email protected]> Signed-off-by: Christian Marangi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: leds-lp55xx: Generalize turn_off_channels functionChristian Marangi4-18/+13
Generalize turn_off_channels function as the implementation is the same for most of the lp55xx based LED driver. Suggested-by: Lee Jones <[email protected]> Signed-off-by: Christian Marangi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: leds-lp55xx: Generalize set_led_current functionChristian Marangi5-24/+26
Generalize set_led_current function as the implementation is the same for most of the lp55xx based LED driver. Suggested-by: Lee Jones <[email protected]> Signed-off-by: Christian Marangi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: leds-lp55xx: Generalize multicolor_brightness functionChristian Marangi4-40/+24
Generalize multicolor_brightness function as the implementation is the same for most of the lp55xx based LED driver. Suggested-by: Lee Jones <[email protected]> Signed-off-by: Christian Marangi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: leds-lp55xx: Generalize led_brightness functionChristian Marangi5-41/+29
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 <[email protected]> Signed-off-by: Christian Marangi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: leds-lp55xx: Generalize firmware_loaded functionChristian Marangi6-88/+30
Generalize firmware_loaded function as lp55xx based LED driver all share the same logic. Suggested-by: Lee Jones <[email protected]> Signed-off-by: Christian Marangi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: leds-lp55xx: Generalize update_program_memory functionChristian Marangi6-198/+79
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 <[email protected]> Signed-off-by: Christian Marangi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: leds-lp55xx: Generalize run_engine functionChristian Marangi6-146/+65
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 <[email protected]> Signed-off-by: Christian Marangi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: leds-lp55xx: Generalize load_engine_and_select_page functionChristian Marangi4-33/+21
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 <[email protected]> Signed-off-by: Christian Marangi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: leds-lp55xx: Generalize load_engine functionChristian Marangi6-84/+43
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 <[email protected]> Signed-off-by: Christian Marangi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: leds-lp55xx: Generalize probe/remove functionsChristian Marangi6-362/+127
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 <[email protected]> Signed-off-by: Christian Marangi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: leds-lp55xx: Generalize stop_all_engine OPChristian Marangi6-34/+84
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 <[email protected]> Signed-off-by: Christian Marangi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: sy7802: Add support for Silergy SY7802 flash LED controllerAndré Apitzsch3-0/+551
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 <[email protected]> Signed-off-by: André Apitzsch <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: pca9532: Change default blinking frequency to 1HzBastien Curutchet1-2/+2
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: pca9532: Explicitly disable hardware blink when PWM1 is unavailableBastien Curutchet1-0/+9
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: pca9532: Use PWM1 for hardware blinkingBastien Curutchet1-10/+43
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: pca9532: Use defines to select PWM instanceBastien Curutchet1-9/+12
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: trigger: input-events: Rewrite to fix a serious locking issueHans de Goede1-102/+34
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: powernv: Replace of_node_put to __freeMarileneGarcia1-19/+9
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 <[email protected]> Signed-off-by: MarileneGarcia <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: mt6360: Fix memory leak in mt6360_init_isnk_properties()Javier Carrasco1-1/+4
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: [email protected] Fixes: 679f8652064b ("leds: Add mt6360 driver") Signed-off-by: Javier Carrasco <[email protected]> Acked-by: Pavel Machek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: tlc591xx: Replace of_node_put to __freeMarilene A Garcia1-11/+7
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 <[email protected]> Signed-off-by: Marilene A Garcia <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: rgb: leds-qcom-lpg: Add PPG check for setting/clearing PBS triggersAnjelique Melendez1-1/+7
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 <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: triggers: Flush pending brightness before activating triggerThomas Weißschuh2-5/+6
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: [email protected] Tested-by: Dustin L. Howett <[email protected]> Signed-off-by: Thomas Weißschuh <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: spi-byte: Move OF ID table closer to their userAndy Shevchenko1-7/+6
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: spi-byte: Use devm_mutex_init() for mutex initializationAndy Shevchenko1-20/+6
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: spi-byte: Utilise temporary variable for struct deviceAndy Shevchenko1-1/+1
We have a temporary variable to keep a pointer to struct device. Utilise it where it makes sense. Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: spi-byte: Make use of device propertiesAndy Shevchenko2-9/+7
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: spi-byte: Get rid of custom led_init_default_state_get()Andy Shevchenko1-12/+5
LED core provides a helper to parse default state from firmware node. Use it instead of custom implementation. Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: spi-byte: Call of_node_put() on error pathAndy Shevchenko1-1/+5
Add a missing call to of_node_put(np) on error. Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: ncp5623: Use common error handling code in ncp5623_probe()Markus Elfring1-8/+8
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26leds: core: Omit set_brightness error message for a LED supporting hw ↵Lee Jones1-6/+13
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/[email protected]/ Reworked the function to provide Heiner's required semantics whilst simultaneously increasing readability and flow. Cc: Pavel Machek <[email protected]> Cc: [email protected] Suggested-by: Heiner Kallweit <[email protected]> Reviewed-by: Heiner Kallweit <[email protected]> Signed-off-by: Lee Jones <[email protected]>
2024-06-26backlight: lm3509_bl: Fix early returns in for_each_child_of_node()Javier Carrasco1-2/+1
The for_each_child_of_node() macro automatically decrements the child refcount at the end of every iteration. On early exits, of_node_put() must be used to manually decrement the refcount and avoid memory leaks. The scoped version of the macro accounts for such early breaks, fixing the early exits without the need for explicit calls to of_node_put(). Reported-by: kernel test robot <[email protected]> Reported-by: Julia Lawall <[email protected]> Closes: https://lore.kernel.org/r/[email protected]/ Fixes: b72755f5b577 ("backlight: Add new lm3509 backlight driver") Signed-off-by: Javier Carrasco <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26soc: samsung: exynos-pmu: update to use of_syscon_register_regmap()Peter Griffin1-24/+14
For SoCs like gs101 that need a special regmap, register this with of_syscon_register_regmap api, so it can be returned by syscon_regmap_lookup_by_phandle() and friends. For SoCs that don't require a custom regmap, revert back to syscon creating the mmio regmap rather than duplicating the logic here. exynos_get_pmu_regmap_by_phandle() api is also updated to retrieve the regmap via syscon. The exynos_get_pmu_regmap_by_phandle() api is kept around until fw_devlink support for syscon property is added for the pinctrl-samsung driver that also runs at postcore_initcall level. All other exynos client drivers can revert back to syscon_regmap_lookup_by_phandle(). Signed-off-by: Peter Griffin <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]> Reviewed-by: Sam Protsenko <[email protected]> Tested-by: Will McVicker <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26mfd: syscon: Add of_syscon_register_regmap() APIPeter Griffin1-0/+48
The of_syscon_register_regmap() API allows an externally created regmap to be registered with syscon. This regmap can then be returned to client drivers using the syscon_regmap_lookup_by_phandle() APIs. The API is used by platforms where mmio access to the syscon registers is not possible, and a underlying soc driver like exynos-pmu provides a SoC specific regmap that can issue a SMC or hypervisor call to write the register. This approach keeps the SoC complexities out of syscon, but allows common drivers such as syscon-poweroff, syscon-reboot and friends that are used by many SoCs already to be re-used. Signed-off-by: Peter Griffin <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]> Reviewed-by: Sam Protsenko <[email protected]> Tested-by: Will McVicker <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-26gpu: ipu-v3: pre: don't use fixed timeout when waiting for safe windowLucas Stach1-8/+14
The timeout when waiting for the PRE safe window is rather short, as normally we would only need to wait a few dozen usecs for the problematic scanline region to pass and we don't want to spin too long in case something goes wrong. This however mixes badly with preemption, as we can easily get scheduled away from the CPU for a longer time than our timeout, in which case we would hit a spurious timeout and wrongly skip the PRE update. Instead of disabling preemption across the wait loop, potentially impacting the overall system latency, use a wait loop with a fixed max number of iterations, so time spent away from the CPU is not accounted against the timeout budget. Signed-off-by: Lucas Stach <[email protected]> Reviewed-by: Philipp Zabel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Philipp Zabel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-26gpu: ipu-v3: pre: add dynamic buffer layout reconfigurationLucas Stach3-30/+63
imx-drm doesn't mandate a modeset when the framebuffer modifier changes, but currently the tile prefetch and resolve (TPR) configuration of the PRE is only set up on the initial modeset. As the TPR configuration is double buffered, same as all the other PRE states, we can support dynamic reconfiguration of the buffer layout from one frame to another. As switching between (super-)tiled and linear prefetch needs to touch the CTRL register make sure to do the reconfiguration inside the safe window. Signed-off-by: Lucas Stach <[email protected]> Reviewed-by: Philipp Zabel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Philipp Zabel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-26gpu: ipu-v3: pre: move state into structLucas Stach1-12/+15
Move the variables tracking the current dynamic state into a struct to separate it a bit better from the static device properties. Signed-off-by: Lucas Stach <[email protected]> Reviewed-by: Philipp Zabel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Philipp Zabel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.