linux-stable.git/drivers/leds, branch linux-6.13.y

leds: rgb: leds-qcom-lpg: Fix calculation of best period Hi-Res PWMs

2025-04-20T08:18:12+00:00

commit 2528eec7da0ec58fcae6d12cfa79a622c933d86b upstream.

When determining the actual best period by looping through all
possible PWM configs, the resolution currently used is based on
bit shift value which is off-by-one above the possible maximum
PWM value allowed.

So subtract one from the resolution before determining the best
period so that the maximum duty cycle requested by the PWM user
won't result in a value above the maximum allowed by the selected
resolution.

Cc: stable@vger.kernel.org    # 6.4
Fixes: b00d2ed37617 ("leds: rgb: leds-qcom-lpg: Add support for high resolution PWM")
Signed-off-by: Abel Vesa 
Reviewed-by: Sebastian Reichel 
Link: https://lore.kernel.org/r/20250305-leds-qcom-lpg-fix-max-pwm-on-hi-res-v4-3-bfe124a53a9f@linaro.org
Signed-off-by: Lee Jones 
Signed-off-by: Greg Kroah-Hartman

leds: rgb: leds-qcom-lpg: Fix pwm resolution max for Hi-Res PWMs

2025-04-20T08:18:11+00:00

commit b7881eacc07fdf50be3f33c662997541bb59366d upstream.

Ideally, the requested duty cycle should never translate to a PWM
value higher than the selected resolution (PWM size), but currently the
best matched period is never reported back to the PWM consumer, so the
consumer will still be using the requested period which is higher than
the best matched one. This will result in PWM consumer requesting
duty cycle values higher than the allowed PWM value.

For example, a consumer might request a period of 5ms while the best
(closest) period the PWM hardware will do is 4.26ms. For this best
matched resolution, if the selected resolution is 8-bit wide, when
the consumer asks for a duty cycle of 5ms, the PWM value will be 300,
which is outside of what the resolution allows. This will happen with
all possible resolutions when selected.

Since for these Hi-Res PWMs, the current implementation is capping the PWM
value at a 15-bit resolution, even when lower resolutions are selected,
the value will be wrapped around by the HW internal logic to the selected
resolution.

Fix the issue by capping the PWM value to the maximum value allowed by
the selected resolution.

Cc: stable@vger.kernel.org    # 6.4
Fixes: b00d2ed37617 ("leds: rgb: leds-qcom-lpg: Add support for high resolution PWM")
Signed-off-by: Abel Vesa 
Reviewed-by: Bjorn Andersson 
Reviewed-by: Sebastian Reichel 
Link: https://lore.kernel.org/r/20250305-leds-qcom-lpg-fix-max-pwm-on-hi-res-v4-2-bfe124a53a9f@linaro.org
Signed-off-by: Lee Jones 
Signed-off-by: Greg Kroah-Hartman

leds: Fix LED_OFF brightness race

2025-04-10T12:41:44+00:00

[ Upstream commit 2c70953b6f535f7698ccbf22c1f5ba26cb6c2816 ]

While commit fa15d8c69238 ("leds: Fix set_brightness_delayed() race")
successfully forces led_set_brightness() to be called with LED_OFF at
least once when switching from blinking to LED on state so that
hw-blinking can be disabled, another race remains. Indeed in
led_set_brightness(LED_OFF) followed by led_set_brightness(any)
scenario the following CPU scheduling can happen:

    CPU0                                     CPU1
    ----                                     ----
 set_brightness_delayed() {
   test_and_clear_bit(BRIGHTNESS_OFF)
                                         led_set_brightness(LED_OFF) {
                                           set_bit(BRIGHTNESS_OFF)
					   queue_work()
                                         }
                                         led_set_brightness(any) {
                                           set_bit(BRIGHTNESS)
					   queue_work() //already queued
                                         }
   test_and_clear_bit(BRIGHTNESS)
     /* LED set with brightness any */
 }

 /* From previous CPU1 queue_work() */
 set_brightness_delayed() {
   test_and_clear_bit(BRIGHTNESS_OFF)
     /* LED turned off */
   test_and_clear_bit(BRIGHTNESS)
     /* Clear from previous run, LED remains off */

In that case the led_set_brightness(LED_OFF)/led_set_brightness(any)
sequence will be effectively executed in reverse order and LED will
remain off.

With the introduction of commit 32360bf6a5d4 ("leds: Introduce ordered
workqueue for LEDs events instead of system_wq") the race is easier to
trigger as sysfs brightness configuration does not wait for
set_brightness_delayed() work to finish (flush_work() removal).

Use delayed_set_value to optionnally re-configure brightness after a
LED_OFF. That way a LED state could be configured more that once but
final state will always be as expected. Ensure that delayed_set_value
modification is seen before set_bit() using smp_mb__before_atomic().

Fixes: fa15d8c69238 ("leds: Fix set_brightness_delayed() race")
Signed-off-by: Remi Pommarel 
Reviewed-by: Hans de Goede 
Link: https://lore.kernel.org/r/19c81177059dab7b656c42063958011a8e4d1a66.1740050412.git.repk@triplefau.lt
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin

leds: lp8860: Write full EEPROM, not only half of it

2025-02-17T10:36:14+00:00

commit 0d2e820a86793595e2a776855d04701109e46663 upstream.

I struggle to explain dividing an ARRAY_SIZE() by the size of an element
once again. As the latter equals to 2, only the half of EEPROM was ever
written. Drop the unexplainable division and write full ARRAY_SIZE().

Cc: stable@vger.kernel.org
Fixes: 7a8685accb95 ("leds: lp8860: Introduce TI lp8860 4 channel LED driver")
Signed-off-by: Alexander Sverdlin 
Link: https://lore.kernel.org/r/20241114101402.2562878-1-alexander.sverdlin@siemens.com
Signed-off-by: Lee Jones 
Signed-off-by: Greg Kroah-Hartman

leds: cht-wcove: Use devm_led_classdev_register() to avoid memory leak

2025-02-08T09:01:15+00:00

[ Upstream commit 417cad5dc782096350e6a967ee5dd3417a19a24e ]

cht_wc_leds_probe() leaks memory when the second led_classdev_register()
call in the for-loop fails as it does not call the cleanup function
led_classdev_unregister() on the first device. Avoid this leak by
calling devm_led_classdev_register().

Fixes: 047da762b9a9 ("leds: Add Intel Cherry Trail Whiskey Cove PMIC LED driver")
Signed-off-by: Joe Hattori 
Link: https://lore.kernel.org/r/20241220085346.533675-1-joe@pf.is.s.u-tokyo.ac.jp
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin

leds: netxbig: Fix an OF node reference leak in netxbig_leds_get_of_pdata()

2025-02-08T09:01:10+00:00

[ Upstream commit 0508316be63bb735f59bdc8fe4527cadb62210ca ]

netxbig_leds_get_of_pdata() does not release the OF node obtained by
of_parse_phandle() when of_find_device_by_node() fails. Add an
of_node_put() call to fix the leak.

This bug was found by an experimental static analysis tool that I am
developing.

Fixes: 9af512e81964 ("leds: netxbig: Convert to use GPIO descriptors")
Signed-off-by: Joe Hattori 
Link: https://lore.kernel.org/r/20241216074923.628509-1-joe@pf.is.s.u-tokyo.ac.jp
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin

module: Convert symbol namespace to string literal

2024-12-02T19:34:44+00:00

Clean up the existing export namespace code along the same lines of
commit 33def8498fdd ("treewide: Convert macro and uses of __section(foo)
to __section("foo")") and for the same reason, it is not desired for the
namespace argument to be a macro expansion itself.

Scripted using

  git grep -l -e MODULE_IMPORT_NS -e EXPORT_SYMBOL_NS | while read file;
  do
    awk -i inplace '
      /^#define EXPORT_SYMBOL_NS/ {
        gsub(/__stringify\(ns\)/, "ns");
        print;
        next;
      }
      /^#define MODULE_IMPORT_NS/ {
        gsub(/__stringify\(ns\)/, "ns");
        print;
        next;
      }
      /MODULE_IMPORT_NS/ {
        $0 = gensub(/MODULE_IMPORT_NS\(([^)]*)\)/, "MODULE_IMPORT_NS(\"\\1\")", "g");
      }
      /EXPORT_SYMBOL_NS/ {
        if ($0 ~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+),/) {
  	if ($0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/ &&
  	    $0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(\)/ &&
  	    $0 !~ /^my/) {
  	  getline line;
  	  gsub(/[[:space:]]*\\$/, "");
  	  gsub(/[[:space:]]/, "", line);
  	  $0 = $0 " " line;
  	}

  	$0 = gensub(/(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/,
  		    "\\1(\\2, \"\\3\")", "g");
        }
      }
      { print }' $file;
  done

Requested-by: Masahiro Yamada 
Signed-off-by: Peter Zijlstra (Intel) 
Link: https://mail.google.com/mail/u/2/#inbox/FMfcgzQXKWgMmjdFwwdsfgxzKpVHWPlc
Acked-by: Greg KH 
Signed-off-by: Linus Torvalds

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

2024-11-23T00:25:20+00:00

PULL LED updates from Lee Jones:

 - Remove unused local header files from various drivers

 - Revert platform driver removal to the original method for consistency

 - Introduce ordered workqueues for LED events, replacing the less
   efficient system_wq

 - Switch to a safer iteration macro in several drivers to prevent
   potential memory leaks

 - Fix a refcounting bug in the mt6360 flash LED driver

 - Fix an uninitialized variable in the mt6370_mc_pattern_clear()
   function

 - Resolve Smatch warnings in the leds-bcm6328 driver

 - Address a potential NULL pointer dereference in the brightness_show()
   function

 - Fix an incorrect format specifier in the ss4200 driver

 - Prevent a resource leak in the max5970 driver's probe function

 - Add support for specifying the number of serial shift bits in the
   device tree for the BCM63138 family

 - Implement multicolor brightness control in the lp5562 driver

 - Add a device tree property to override the default LED pin polarity

 - Add a property to specify the default brightness value when the LED
   is initially on

 - Set missing timing properties for the ktd2692 driver

 - Document the "rc-feedback" trigger for controlling LEDs based on
   remote control activity

 - Convert text bindings to YAML for the pca955x driver to enable device
   tree validation

 - Remove redundant checks for invalid channel numbers in the lp55xx
   driver

 - Update the MAINTAINERS file with current contact information

* tag 'leds-next-6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (46 commits)
  leds: ss4200: Fix the wrong format specifier for 'blinking'
  leds: pwm: Add optional DT property default-brightness
  dt-bindings: leds: pwm: Add default-brightness property
  leds: class: Protect brightness_show() with led_cdev->led_access mutex
  leds: ktd2692: Set missing timing properties
  leds: max5970: Fix unreleased fwnode_handle in probe function
  leds: Introduce ordered workqueue for LEDs events instead of system_wq
  MAINTAINERS: Replace Siemens IPC related bouncing maintainers
  leds: bcm6328: Replace divide condition with comparison for shift value
  leds: lp55xx: Remove redundant test for invalid channel number
  dt-bindings: leds: pca955x: Convert text bindings to YAML
  leds: rgb: leds-mt6370-rgb: Fix uninitialized variable 'ret' in mt6370_mc_pattern_clear
  leds: lp5562: Add multicolor brightness control
  dt-bindings: leds: Add 'active-high' property
  leds: Switch back to struct platform_driver::remove()
  leds: bcm63138: Add some register defines
  leds: bcm63138: Handle shift register config
  leds: bcm63138: Use scopes and guards
  dt-bindings: leds: bcm63138: Add shift register bits
  leds: leds-gpio-register: Reorganize kerneldoc parameter names
  ...

leds: ss4200: Fix the wrong format specifier for 'blinking'

2024-11-12T14:39:26+00:00

The format specifier of "signed int" in sprintf() should be "%d", not
"%u".

Signed-off-by: Zhu Jun 
Link: https://lore.kernel.org/r/20241111065809.3814-1-zhujun2@cmss.chinamobile.com
Signed-off-by: Lee Jones

leds: pwm: Add optional DT property default-brightness

2024-11-12T12:14:00+00:00

When probing if default LED state is on then default brightness will be
applied instead of max brightness.

Signed-off-by: George Stark 
Link: https://lore.kernel.org/r/20241105185006.1380166-3-gnstark@salutedevices.com
Signed-off-by: Lee Jones