| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
There is a ti,enable-id-detection property in the Extcon Palmas
(extcon-palmas), but not in the Extcon USB GPIO binding and driver.
Reported-by: kernel test robot <[email protected]>
Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Krzysztof Kozlowski <[email protected]>
|
|
There will be three devices for this sound card, hw:x,0 is
the playback device for one SAI, hw:x,1 is the playback device
for another SAI, hw:x,2 is the capture device for audmix
output. then capture device and playback device can be configured
with different master/slave mode.
Signed-off-by: Shengjiu Wang <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
As audmix requires playback and capture stream in different
master/slave mode, so separate playback and capture stream to
different DAI. There are three DAIs required, two DAIs for playback
one DAI for capture.
Signed-off-by: Shengjiu Wang <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
The transmitter and receiver part of the SAI interface need to be
configured with different master/slave mode, especially to work
with the audiomix module.
+-------+ +-----------+
| SAI1 | --TX--> | |
| | <--RX-- | |
+-------+ | |
| AUDIOMIX |
+-------+ | |
| SAI2 | --TX--> | |
+-------+ +-----------+
The SAI1 TX is in master mode, but SAI1 RX is in slave mode.
So add another two DAIs for TX and RX separately. but only
defined fsl_sai_set_dai_fmt_tx() and fsl_sai_set_dai_fmt_rx()
ops function for current case, in the future, the other ops
function for TX and RX can be defined if required.
Signed-off-by: Shengjiu Wang <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
Some Sound Card might need special trigger ordering which is based on
CPU/Codec connection. It is already supported on ASoC, but Audio Graph
Card2 still not yet support it. Let's support it.
Cc: Maxim Kochetkov <[email protected]>
Signed-off-by: Kuninori Morimoto <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
Some Sound Card might need special trigger ordering which is based on
CPU/Codec connection. It is already supported on ASoC, but Audio Graph
Card still not yet support it. Let's support it.
Cc: Maxim Kochetkov <[email protected]>
Signed-off-by: Kuninori Morimoto <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
Some Sound Card might need special trigger ordering which is based on
CPU/Codec connection. It is already supported on ASoC, but Simple Audio
Card still not yet support it. Let's support it.
Cc: Maxim Kochetkov <[email protected]>
Signed-off-by: Kuninori Morimoto <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
Some Sound Card might need special trigger ordering which is based on
CPU/Codec connection. It is already supported on ASoC, but Simple Audio
Card / Audio Graph Card still not support it. Let's support it.
Cc: Maxim Kochetkov <[email protected]>
Signed-off-by: Kuninori Morimoto <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
Sound Card need to consider/adjust HW control ordering based on the
combination of CPU/Codec. The controlling feature is already supported
on ASoC, but Simple Audio Card / Audio Graph Card still not support it.
Let's support it.
Cc: Maxim Kochetkov <[email protected]>
Signed-off-by: Kuninori Morimoto <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
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]>
|
|
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]
|
|
Add the device tree binding for the Ilitek ILI9806E controller which can
be found on the Ortustech COME35H3P70ULC DSI display panel.
There are no peculiarities except for two different power signals.
Reviewed-by: Conor Dooley <[email protected]>
Signed-off-by: Michael Walle <[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]
|
|
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]
|
|
Like for mipi_dsi_msleep(), usleep_range() may often be called
in between mipi_dsi_dcs_*() functions and needs a multi compatible
counter part.
Suggested-by: Dmitry Baryshkov <[email protected]>
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]
|
|
This adds the bindings for the 1080x1920 Lincoln LCD197 DSI panel to
panel-simple-dsi.
Signed-off-by: Jerome Brunet <[email protected]>
Acked-by: Conor Dooley <[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]
|
|
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]
|
|
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]>
|
|
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]>
|
|
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]>
|
|
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]>
|
|
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]>
|
|
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]>
|
|
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]>
|
|
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]>
|
|
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]>
|
|
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]>
|
|
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]>
|
|
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]>
|
|
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]>
|
|
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]>
|
|
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]>
|
|
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]>
|
|
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]>
|
|
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]>
|
|
Add new ti,lp5569 compatible, this is similar to national,lp5523 with
slight change to reg order and reg type and advanced way for LED fault.
Signed-off-by: Christian Marangi <[email protected]>
Acked-by: Conor Dooley <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>
|
|
pwr-sel property is specific to ti,lp8501, make it conditional of the
related compatible.
Signed-off-by: Christian Marangi <[email protected]>
Acked-by: Rob Herring (Arm) <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>
|
|
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]>
|
|
Document Silergy SY7802 flash LED driver devicetree bindings.
Reviewed-by: Rob Herring <[email protected]>
Signed-off-by: André Apitzsch <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>
|
|
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]>
|
|
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]>
|
|
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]>
|
|
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]>
|
|
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]>
|
|
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]>
|
|
Pavel's repo hasn't been used actively for quite some time.
Let's make it official.
Cc: Pavel Machek <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
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]>
|
|
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]>
|
|
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]>
|
|
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]>
|
|
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]>
|