Commit Graph

2044 Commits

Author SHA1 Message Date
Linus Torvalds
fea17683c4 - Core Frameworks
- Add new Trigger for Input Events
    - Add new led_mc_set_brightness() call to adapt colour/brightness for mutli-colour LEDs
    - Add new lled_mc_trigger_event() call to call the above based on given trigger conditions
    - Add new led_get_color_name() call, a wrapper around the existing led_colors[] array
    - Add a new flag to avoid automatic renaming of LED devices
 
  - New Drivers
    - Add support for Silergy SY7802 Flash LED Controller
    - Add support for Texas Instruments LP5569 LED Controller
    - Add support for ChromeOS EC LED Controller
 
  - New Device Support
    - Add support for KTD202{6,7} to Kinetic KTD2026/7 LEDs
 
  - Fix-ups
    - Replace ACPI/DT firmware helpers with agnostic variants
    - Make use of resource managed devm_* API calls
    - Device Tree binding adaptions/conversions/creation
    - Constify/staticise applicable data structures
    - Trivial; spelling, whitespace, coding-style adaptions
    - Drop i2c_device_id::driver_data where the value is unused
    - Utilise centrally provided helpers and macros to aid simplicity/duplication
    - Use generic platform device properties instead of OF/ACPI specific ones
    - Consolidate/de-duplicate various functionality
    - Remove superfluous/duplicated/unused sections
    - Make use of the new *_scoped() guard APIs
    - Improve/simplify error handling
 
  - Bug Fixes
    - Flush pending brightness changes before activating the trigger
    - Repair incorrect device naming preventing matches
    - Prevent memory leaks by correctly free resources during error handling routines
    - Repair locking issue causing circular dependency splats and lock-ups
    - Unregister sysfs entries before deactivating triggers to prevent use-after issues
    - Supply a bunch of MODULE_DESCRIPTIONs to silence modpost warnings
    - Use correct return codes expected by the callers
    - Omit set_brightness() error message for a LEDs that support only HW triggers
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAmaWgMEACgkQUa+KL4f8
 d2Glng//Sw3+ev7IFn4PmNfMHtKeWlJEerT8kyF0GdK05zn7ImlydkSVW5RvHN8B
 J2A8cfXXkhggYoG2i4zjs1wtfPDXP9iJMhVaRnPPuWgYJpPrhUFSSkJKiauSKyGN
 Tp3Vn6QaHM5Gs/THUidcTV0+USE6j9+DXdLjLASAi2YXqoGCC3KWcq4Hb6NdGM/Q
 ajEuGnrO1HEF0dOaEgkYuNIXcADHzeeQlU0Y96bGv7qnUBw7LAIpH+AC1d49jcXS
 gIJNxmtmn0QqCK0/lS74DmR9r2quofeYer6G5WDJVv72R8KIljFN16AGFLdC8ID/
 3B4JnjQKpEyn344gmvqzx23dp3jqvCupgDcojR6RY7yIZTXSjg0R0OocKYQlDnNY
 LoNZqZ9J2nNDWNlx7r7PXuIAm7Bb9kdY0/PWgXOwWsEb19DcxyAHE3+xGeyQF6f5
 /s1bGZxQyfBnDZm8+XiJ6KTsiZ1t0MljG9y7xil6vtzJIJTynao9qzZipcrx7UuT
 3UyoGa/Z4o95OkQye9n6tKGJJDKLJIZL7x4pGOW3HeHgfvJ1koyHr8WwhmK4Zoh/
 xeHfHABuaMoulTsuGjtnRP4/UWOTEf2hh7FK1mSrpxSCvv+I9W4lTO9QBkXU8xuD
 1oCekcTYWOwKhxaFX4jjaGEHXIWYzXDjE7hqroLzj8Ifhqe9xrc=
 =0Kyu
 -----END PGP SIGNATURE-----

Merge tag 'leds-next-6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds

Pull LED updates from Lee Jones:
 "Core Frameworks:
   - New trigger for Input Events
   - New led_mc_set_brightness() call to adapt colour/brightness for
     mutli-colour LEDs
   - New lled_mc_trigger_event() call to call the above based on given
     trigger conditions
   - New led_get_color_name() call, a wrapper around the existing
     led_colors[] array
   - A new flag to avoid automatic renaming of LED devices

  New Drivers:
   - Silergy SY7802 Flash LED Controller
   - Texas Instruments LP5569 LED Controller
   - ChromeOS EC LED Controller

  New Device Support:
   - KTD202{6,7} support for Kinetic KTD2026/7 LEDs

  Fix-ups:
   - Replace ACPI/DT firmware helpers with agnostic variants
   - Make use of resource managed devm_* API calls
   - Device Tree binding adaptions/conversions/creation
   - Constify/staticise applicable data structures
   - Trivial; spelling, whitespace, coding-style adaptions
   - Drop i2c_device_id::driver_data where the value is unused
   - Utilise centrally provided helpers and macros to aid simplicity and
     avoid duplication
   - Use generic platform device properties instead of OF/ACPI specific
     ones
   - Consolidate/de-duplicate various functionality
   - Remove superfluous/duplicated/unused sections
   - Make use of the new *_scoped() guard APIs
   - Improve/simplify error handling

  Bug Fixes:
   - Flush pending brightness changes before activating the trigger
   - Repair incorrect device naming preventing matches
   - Prevent memory leaks by correctly free resources during error
     handling routines
   - Repair locking issue causing circular dependency splats and
     lock-ups
   - Unregister sysfs entries before deactivating triggers to prevent
     use-after issues
   - Supply a bunch of MODULE_DESCRIPTIONs to silence modpost warnings
   - Use correct return codes expected by the callers
   - Omit set_brightness() error message for a LEDs that support only HW
     triggers"

* tag 'leds-next-6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (65 commits)
  leds: leds-lp5569: Enable chip after chip configuration
  leds: leds-lp5569: Better handle enabling clock internal setting
  leds: leds-lp5569: Fix typo in driver name
  leds: flash: leds-qcom-flash: Test the correct variable in init
  leds: leds-lp55xx: Convert mutex lock/unlock to guard API
  leds: leds-lp5523: Convert to sysfs_emit API
  leds: leds-lp5569: Convert to sysfs_emit API
  Revert "leds: led-core: Fix refcount leak in of_led_get()"
  leds: leds-lp5569: Add support for Texas Instruments LP5569
  leds: leds-lp55xx: Drop deprecated defines
  leds: leds-lp55xx: Support ENGINE program up to 128 bytes
  leds: leds-lp55xx: Generalize sysfs master_fader
  leds: leds-lp55xx: Generalize sysfs engine_leds
  leds: leds-lp55xx: Generalize sysfs engine_load and engine_mode
  leds: leds-lp55xx: Generalize stop_engine function
  leds: leds-lp55xx: Generalize turn_off_channels function
  leds: leds-lp55xx: Generalize set_led_current function
  leds: leds-lp55xx: Generalize multicolor_brightness function
  leds: leds-lp55xx: Generalize led_brightness function
  leds: leds-lp55xx: Generalize firmware_loaded function
  ...
2024-07-17 17:51:30 -07:00
Linus Torvalds
1200af3ac1 - New Drivers
- Add support for ROHM BD96801 Power Management IC
    - Add support for Cirrus Logic CS40L50 Haptic Driver with Waveform Memory
    - Add support for Marvell 88PM886 Power Management IC
 
  - New Device Support
    - Add support for Keyboard Backlight to ChromeOS Embedded Controller
    - Add support for LEDs to ChromeOS Embedded Controller
    - Add support for Charge Control to ChromeOS Embedded Controller
    - Add support for the HW Monitoring Service to ChromeOS Embedded Controller
    - Add support for AUXADCs to MediaTek MT635{7,8,9} Power Management ICs
 
  - New Functionality
    - Allow Syscon consumers to supply their own Regmaps on registration
 
  - Fix-ups
    - Constify/staticise applicable data structures
    - Remove superfluous/duplicated/unused sections
    - Device Tree binding adaptions/conversions/creation
    - Trivial; spelling, whitespace, coding-style adaptions
    - Utilise centrally provided helpers and macros to aid simplicity/duplication
    - Drop i2c_device_id::driver_data where the value is unused
    - Replace ACPI/DT firmware helpers with agnostic variants
    - Move over to GPIOD (descriptor-based) APIs
    - Annotate a bunch of __counted_by() cases
    - Straighten out some includes
 
  - Bug Fixes
    - Ensure potentially asserted recent lines are deasserted during initialisation
    - Avoid "<module>.ko is added to multiple modules" warnings
    - Supply a bunch of MODULE_DESCRIPTIONs to silence modpost warnings
    - Fix Wvoid-pointer-to-enum-cast warnings
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAmaWf6sACgkQUa+KL4f8
 d2HhAw//UMujhKk/IfzGck3RoaKH3H22oVpd98BpzJCZBKSpl9pGsumHCicBMVAK
 gp8SuwKNCAX+Fa/TubHz0xH6FWxLFXezh5DvO1t1DrPNokG+u4QPTfgMJ1IfBMHO
 w7aL74rtJEyWBeod4+qNVoq6KNDaWjiWQlxGQ+9IoSNmxSTL6pkYMqo935RnqhRr
 nm2TfSOIshk4tiO9tVA1ecCgjVwsG51803hypmd1AH6qBb7JsY6k1HWukLGaqUiV
 +57oQzCTPIRYJhYdca06xi4ZmPg2kmoYKlxqW5ExyM7Mxs9aZZzwwZ7929LKXC6o
 ebAPDc3auoww7B5mHbbVuBj0gDZKtfXpBRKSHLNtmhi0xmjnwZxQIumkpVGQALkI
 0TQffgYVU4O7IXsAZG9w5igyMzEo9SZJMyrfFaQ0iB3rx5bXuh4b6btfewAkyI1H
 +o3Yjymf4CR1trY9qnWCGWM/COQLIiGRhsk/RqGjy0xtpQo1Skx+AIkc6QD2zl6Y
 ohC0JzEWTQe7c1DOM3SLpNoCb/GbFpVi0RrXRVfRltPHpVb/r54Zlbo+PrCaC8FB
 EkU+86XbxGMh7hLtz5yhmnNCWKHQ6jbaFESwtZLo4d42CKvZaobL4xVCL56OntsH
 ikmTNG+X0mUAZiCwGgK5OhEVCAtCcjRtz1U93wgDBaz7Y39z+yM=
 =DSjk
 -----END PGP SIGNATURE-----

Merge tag 'mfd-next-6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd

Pull MFD updates from Lee Jones:
 "New Drivers:
   - ROHM BD96801 Power Management IC
   - Cirrus Logic CS40L50 Haptic Driver with Waveform Memory
   - Marvell 88PM886 Power Management IC

  New Device Support:
   - Keyboard Backlight to ChromeOS Embedded Controller
   - LEDs to ChromeOS Embedded Controller
   - Charge Control to ChromeOS Embedded Controller
   - HW Monitoring Service to ChromeOS Embedded Controller
   - AUXADCs to MediaTek MT635{7,8,9} Power Management ICs

  New Functionality:
   - Allow Syscon consumers to supply their own Regmaps on registration

  Fix-ups:
   - Constify/staticise applicable data structures
   - Remove superfluous/duplicated/unused sections
   - Device Tree binding adaptions/conversions/creation
   - Trivial; spelling, whitespace, coding-style adaptions
   - Utilise centrally provided helpers and macros to aid
     simplicity/duplication
   - Drop i2c_device_id::driver_data where the value is unused
   - Replace ACPI/DT firmware helpers with agnostic variants
   - Move over to GPIOD (descriptor-based) APIs
   - Annotate a bunch of __counted_by() cases
   - Straighten out some includes

  Bug Fixes:
   - Ensure potentially asserted recent lines are deasserted during
     initialisation
   - Avoid "<module>.ko is added to multiple modules" warnings
   - Supply a bunch of MODULE_DESCRIPTIONs to silence modpost warnings
   - Fix Wvoid-pointer-to-enum-cast warnings"

* tag 'mfd-next-6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (87 commits)
  mfd: timberdale: Attach device properties to TSC2007 board info
  mfd: tmio: Move header to platform_data
  mfd: tmio: Sanitize comments
  mfd: tmio: Update include files
  mmc: tmio/sdhi: Fix includes
  mfd: tmio: Remove obsolete io accessors
  mfd: tmio: Remove obsolete platform_data
  watchdog: bd96801_wdt: Add missing include for FIELD_*()
  dt-bindings: mfd: syscon: Add APM poweroff mailbox
  dt-bindings: mfd: syscon: Split and enforce documenting MFD children
  dt-bindings: mfd: rk817: Merge support for RK809
  dt-bindings: mfd: rk817: Fixup clocks and reference dai-common
  dt-bindings: mfd: syscon: Add TI's opp table compatible
  mfd: omap-usb-tll: Use struct_size to allocate tll
  dt-bindings: mfd: Explain lack of child dependency in simple-mfd
  dt-bindings: mfd: Dual licensing for st,stpmic1 bindings
  mfd: omap-usb-tll: Annotate struct usbtll_omap with __counted_by
  mfd: tps6594-core: Remove unneeded semicolon in tps6594_check_crc_mode()
  mfd: lm3533: Move to new GPIO descriptor-based APIs
  mfd: tps65912: Use devm helper functions to simplify probe
  ...
2024-07-17 17:42:20 -07:00
Christian Marangi
b0eed39762 leds: leds-lp5569: Enable chip after chip configuration
Documentation say that clock internal config needs to be set BEFORE chip
is enabled. Align code to this and move the CHIP enable after the CHIP
is configured.

While at it also make use of STATUS reg and check when STARTUP is
completed instead of sleep for 1-2 ms.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240712004556.15601-3-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
2024-07-12 08:32:37 +01:00
Christian Marangi
2a498d626d leds: leds-lp5569: Better handle enabling clock internal setting
Better handle enabling clock internal setting. In further testing it was
notice that internal clock config MUST be set before clock output config
or the LED CHIP might stop working.

This wasn't documented and was actually found on devices that have 2
chip chained where one chip provide clock for the other.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240712004556.15601-2-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
2024-07-12 08:32:37 +01:00
Christian Marangi
9c5fd27925 leds: leds-lp5569: Fix typo in driver name
Remove extra x from driver name as this was a typo from copy-paste
error.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240712004556.15601-1-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
2024-07-12 08:32:37 +01:00
Dan Carpenter
87e552ad65 leds: flash: leds-qcom-flash: Test the correct variable in init
This code was passing the incorrect pointer to PTR_ERR_OR_ZERO() so it
always returned success.  It should have been checking the array element
instead of the array itself.

Fixes: 96a2e242a5 ("leds: flash: Add driver to support flash LED module in QCOM PMICs")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://lore.kernel.org/r/ZoWJS_epjIMCYITg@stanley.mountain
Signed-off-by: Lee Jones <lee@kernel.org>
2024-07-11 12:46:33 +01:00
Christian Marangi
4137d94fd8 leds: leds-lp55xx: Convert mutex lock/unlock to guard API
Convert any entry of mutex lock/unlock to guard API and simplify code.
With the use of guard API, handling for selttest functions can be
greatly simplified.

Suggested-by: Markus Elfring <Markus.Elfring@web.de>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626221520.2846-3-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
2024-07-11 12:46:25 +01:00
Lee Jones
5ffe70d81e Merge branch 'ib-mfd-leds-platform-6.11' into ibs-for-mfd-merged 2024-07-04 17:07:01 +01:00
Christian Marangi
8eac0379d3 leds: leds-lp5523: Convert to sysfs_emit API
Convert sprintf to the much safer sysfs_emit API to handle output for
sysfs.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626221520.2846-2-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
2024-07-04 16:44:45 +01:00
Christian Marangi
6f2fdde909 leds: leds-lp5569: Convert to sysfs_emit API
Convert sprintf to the much safer sysfs_emit API to handle output for
sysfs.

Also better handle situation where on the same chip there may be LED
open and shorted at the same time.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626221520.2846-1-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
2024-07-04 16:44:45 +01:00
Luca Ceresoli
940b27161a Revert "leds: led-core: Fix refcount leak in of_led_get()"
This reverts commit da1afe8e60.

Commit 699a8c7c4b ("leds: Add of_led_get() and led_put()"), introduced in
5.5, added of_led_get() and led_put() but missed a put_device() in
led_put(), thus creating a leak in case the consumer device is removed.

Arguably device removal was not very popular, so this went apparently
unnoticed until 2022. In January 2023 two different patches got merged to
fix the same bug:

 - commit da1afe8e60 ("leds: led-core: Fix refcount leak in of_led_get()")
 - commit 445110941e ("leds: led-class: Add missing put_device() to led_put()")

They fix the bug in two different ways, which creates no patch conflicts,
and both were merged in v6.2. The result is that now there is one more
put_device() than get_device()s, instead of one less.

Arguably device removal is not very popular yet, so this apparently hasn't
been noticed as well up to now. But it blew up here while I'm working with
device tree overlay insertion and removal. The symptom is an apparently
unrelated list of oopses on device removal, with reasons:

  kernfs: can not remove 'uevent', no directory
  kernfs: can not remove 'brightness', no directory
  kernfs: can not remove 'max_brightness', no directory
  ...

Here sysfs fails removing attribute files, which is because the device name
changed and so the sysfs path. This is because the device name string got
corrupted, which is because it got freed too early and its memory reused.

Different symptoms could appear in different use cases.

Fix by removing one of the two fixes.

The choice was to remove commit da1afe8e60 because:

 * it is calling put_device() inside of_led_get() just after getting the
   device, thus it is basically not refcounting the LED device at all
   during its entire lifetime
 * it does not add a corresponding put_device() in led_get(), so it fixes
   only the OF case

The other fix (445110941e) is adding the put_device() in led_put() so it
covers the entire lifetime, and it works even in the non-DT case.

Fixes: da1afe8e60 ("leds: led-core: Fix refcount leak in of_led_get()")
Co-developed-by: Hervé Codina <herve.codina@bootlin.com>
Signed-off-by: Hervé Codina <herve.codina@bootlin.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://lore.kernel.org/r/20240625-led-class-device-leak-v2-1-75fdccf47421@bootlin.com
Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-27 09:08:37 +01:00
Christian Marangi
30c6743cc8 leds: leds-lp5569: Add support for Texas Instruments LP5569
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 <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-21-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-26 17:08:31 +01:00
Christian Marangi
49d943a426 leds: leds-lp55xx: Drop deprecated defines
Drop deprecated defines not used anymore as the related function got
moved to lp55xx-common.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-20-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-26 17:08:31 +01:00
Christian Marangi
b9d55087df leds: leds-lp55xx: Support ENGINE program up to 128 bytes
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 <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-19-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-26 17:08:31 +01:00
Christian Marangi
5a15b2ab57 leds: leds-lp55xx: Generalize sysfs master_fader
Generalize sysfs master_fader since their implementation is the same across
some 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-18-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-26 17:08:31 +01:00
Christian Marangi
8913c2c147 leds: leds-lp55xx: Generalize sysfs engine_leds
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 <lee@kernel.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-17-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-26 17:08:31 +01:00
Christian Marangi
082a4d3f06 leds: leds-lp55xx: Generalize sysfs engine_load and engine_mode
Generalize sysfs engine_load and engine_mode since their implementation
is the same acrosso some 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-16-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-26 17:08:31 +01:00
Christian Marangi
43e91e5eb9 leds: leds-lp55xx: Generalize stop_engine function
Generalize stop_engine 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-15-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-26 17:08:31 +01:00
Christian Marangi
e35bc5d8a0 leds: leds-lp55xx: Generalize turn_off_channels function
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>
2024-06-26 17:08:31 +01:00
Christian Marangi
01e0290d17 leds: leds-lp55xx: Generalize set_led_current function
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>
2024-06-26 17:08:31 +01:00
Christian Marangi
794826b2d8 leds: leds-lp55xx: Generalize multicolor_brightness function
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>
2024-06-26 17:08:31 +01:00
Christian Marangi
c63580b27a leds: leds-lp55xx: Generalize led_brightness function
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>
2024-06-26 17:08:31 +01:00
Christian Marangi
a3df1906fb leds: leds-lp55xx: Generalize firmware_loaded function
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>
2024-06-26 17:08:31 +01:00
Christian Marangi
31379a57cf leds: leds-lp55xx: Generalize update_program_memory function
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>
2024-06-26 17:08:30 +01:00
Christian Marangi
42a9eaac97 leds: leds-lp55xx: Generalize run_engine function
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>
2024-06-26 17:08:30 +01:00
Christian Marangi
409a9dc536 leds: leds-lp55xx: Generalize load_engine_and_select_page function
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>
2024-06-26 17:08:30 +01:00
Christian Marangi
4d310b96f2 leds: leds-lp55xx: Generalize load_engine function
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>
2024-06-26 17:08:30 +01:00
Christian Marangi
db30c2891b leds: leds-lp55xx: Generalize probe/remove functions
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>
2024-06-26 17:08:30 +01:00
Christian Marangi
a9b202b9cf leds: leds-lp55xx: Generalize stop_all_engine OP
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>
2024-06-26 17:08:30 +01:00
André Apitzsch
c581f17a66 leds: sy7802: Add support for Silergy SY7802 flash LED controller
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>
2024-06-26 17:04:39 +01:00
Bastien Curutchet
1dee6a4d62 leds: pca9532: Change default blinking frequency to 1Hz
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>
2024-06-26 17:04:37 +01:00
Bastien Curutchet
f51bc3cedf leds: pca9532: Explicitly disable hardware blink when PWM1 is unavailable
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>
2024-06-26 17:04:37 +01:00
Bastien Curutchet
48ca7f302c leds: pca9532: Use PWM1 for hardware blinking
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>
2024-06-26 17:04:36 +01:00
Bastien Curutchet
0e69c9062b leds: pca9532: Use defines to select PWM instance
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>
2024-06-26 17:04:35 +01:00
Hans de Goede
a031c81497 leds: trigger: input-events: Rewrite to fix a serious locking issue
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 822c91e72e ("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>
2024-06-26 16:56:12 +01:00
MarileneGarcia
d35625734a leds: powernv: Replace of_node_put to __free
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>
2024-06-26 16:56:11 +01:00
Javier Carrasco
e41d574b35 leds: mt6360: Fix memory leak in mt6360_init_isnk_properties()
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: 679f865206 ("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>
2024-06-26 16:56:10 +01:00
Marilene A Garcia
8d89afc635 leds: tlc591xx: Replace of_node_put to __free
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>
2024-06-26 16:56:09 +01:00
Anjelique Melendez
7e776e2125 leds: rgb: leds-qcom-lpg: Add PPG check for setting/clearing PBS triggers
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: 6ab1f766a8 ("leds: rgb: leds-qcom-lpg: Add support for PPG through single SDAM")
Fixes: 5e9ff62686 ("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>
2024-06-26 16:56:08 +01:00
Thomas Weißschuh
ab477b766e leds: triggers: Flush pending brightness before activating trigger
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: 0db37915d9 ("leds: avoid races with workqueue")
Fixes: 8c0f693c6e ("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>
2024-06-26 16:56:07 +01:00
Andy Shevchenko
25458b2a40 leds: spi-byte: Move OF ID table closer to their user
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>
2024-06-26 16:56:07 +01:00
Andy Shevchenko
133f941f22 leds: spi-byte: Use devm_mutex_init() for mutex initialization
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>
2024-06-26 16:56:06 +01:00
Andy Shevchenko
9ed388d1ac leds: spi-byte: Utilise temporary variable for struct device
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>
2024-06-26 16:56:05 +01:00
Andy Shevchenko
67b66160bd leds: spi-byte: Make use of device properties
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>
2024-06-26 16:56:04 +01:00
Andy Shevchenko
4b268456e0 leds: spi-byte: Get rid of custom led_init_default_state_get()
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>
2024-06-26 16:56:04 +01:00
Andy Shevchenko
7f9ab862e0 leds: spi-byte: Call of_node_put() on error path
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>
2024-06-26 16:56:03 +01:00
Markus Elfring
e1524a6299 leds: ncp5623: Use common error handling code in ncp5623_probe()
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>
2024-06-26 16:56:02 +01:00
Lee Jones
d33d1214a1 leds: core: Omit set_brightness error message for a LED supporting hw 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>
2024-06-26 16:55:44 +01:00
Hans de Goede
6f963a20ee leds: trigger: Add new LED Input events trigger
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>
2024-06-21 11:57:17 +01:00
Ilpo Järvinen
ce068e8397 leds: ss4200: Convert PCIBIOS_* return codes to errnos
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: a328e95b82 ("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>
2024-06-21 11:57:16 +01:00