<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/leds, branch linux-6.17.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.17.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.17.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2025-12-18T12:59:48Z</updated>
<entry>
<title>leds: rgb: leds-qcom-lpg: Don't enable TRILED when configuring PWM</title>
<updated>2025-12-18T12:59:48Z</updated>
<author>
<name>Fenglin Wu</name>
<email>fenglin.wu@oss.qualcomm.com</email>
</author>
<published>2025-11-19T06:06:43Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=65327fd5a86dcda26647c13a3fd5c3d17d3e0715'/>
<id>urn:sha1:65327fd5a86dcda26647c13a3fd5c3d17d3e0715</id>
<content type='text'>
[ Upstream commit 072cd5f458d76b9e15d89ebdaea8b5cb1312eeef ]

The PWM signal from the LPG channel can be routed to PMIC GPIOs with
proper GPIO configuration, and it is not necessary to enable the
TRILED channel in that case. This also applies to the LPG channels
that mapped to TRILED channels. Additionally, enabling the TRILED
channel unnecessarily would cause a voltage increase in its power
supply. Hence remove it.

Fixes: 24e2d05d1b68 ("leds: Add driver for Qualcomm LPG")
Signed-off-by: Fenglin Wu &lt;fenglin.wu@oss.qualcomm.com&gt;
Reviewed-by: Bjorn Andersson &lt;andersson@kernel.org&gt;
Link: https://patch.msgid.link/20251119-lpg_triled_fix-v3-2-84b6dbdc774a@oss.qualcomm.com
Signed-off-by: Lee Jones &lt;lee@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>leds: netxbig: Fix GPIO descriptor leak in error paths</title>
<updated>2025-12-18T12:59:41Z</updated>
<author>
<name>Haotian Zhang</name>
<email>vulab@iscas.ac.cn</email>
</author>
<published>2025-10-31T02:16:20Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c8306fe7a1da6df1f4a534a3b2a945003fb64e7a'/>
<id>urn:sha1:c8306fe7a1da6df1f4a534a3b2a945003fb64e7a</id>
<content type='text'>
[ Upstream commit 03865dd8af52eb16c38062df2ed30a91b604780e ]

The function netxbig_gpio_ext_get() acquires GPIO descriptors but
fails to release them when errors occur mid-way through initialization.
The cleanup callback registered by devm_add_action_or_reset() only
runs on success, leaving acquired GPIOs leaked on error paths.

Add goto-based error handling to release all acquired GPIOs before
returning errors.

Fixes: 9af512e81964 ("leds: netxbig: Convert to use GPIO descriptors")
Suggested-by: Markus Elfring &lt;Markus.Elfring@web.de&gt;
Signed-off-by: Haotian Zhang &lt;vulab@iscas.ac.cn&gt;
Link: https://patch.msgid.link/20251031021620.781-1-vulab@iscas.ac.cn
Signed-off-by: Lee Jones &lt;lee@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>leds: upboard: Fix module alias</title>
<updated>2025-12-18T12:59:23Z</updated>
<author>
<name>Thomas Richard</name>
<email>thomas.richard@bootlin.com</email>
</author>
<published>2025-10-20T15:36:25Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=93d7f654c14396c7220377cfb6fed022733308f1'/>
<id>urn:sha1:93d7f654c14396c7220377cfb6fed022733308f1</id>
<content type='text'>
[ Upstream commit c06a017439110debd335b6864bc2d69835624235 ]

The module alias does not match the cell name defined in the MFD driver,
preventing automatic loading when the driver is built as a module. So fix
the module alias to ensure proper module auto-loading.

Fixes: 0ef2929a0181 ("leds: Add AAEON UP board LED driver")
Signed-off-by: Thomas Richard &lt;thomas.richard@bootlin.com&gt;
Reviewed-by: Krzysztof Kozlowski &lt;krzysztof.kozlowski@linaro.org&gt;
Link: https://patch.msgid.link/20251020-leds-upboard-fix-module-alias-v2-1-84ac5c3a1a81@bootlin.com
Signed-off-by: Lee Jones &lt;lee@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>leds: leds-lp55xx: Use correct address for memory programming</title>
<updated>2025-10-15T10:03:23Z</updated>
<author>
<name>Andrei Lalaev</name>
<email>andrei.lalaev@anton-paar.com</email>
</author>
<published>2025-08-20T08:47:12Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=029d1324011c4b1c42a510ac16474368be9f2f44'/>
<id>urn:sha1:029d1324011c4b1c42a510ac16474368be9f2f44</id>
<content type='text'>
[ Upstream commit d6058316d16ee0d1861c0550051b2492efb54b79 ]

Memory programming doesn't work for devices without page support.
For example, LP5562 has 3 engines but doesn't support pages,
the start address is changed depending on engine number.
According to datasheet [1], the PROG MEM register addresses for each
engine are as follows:

  Engine 1: 0x10
  Engine 2: 0x30
  Engine 3: 0x50

However, the current implementation incorrectly calculates the address
of PROG MEM register using the engine index starting from 1:

  prog_mem_base = 0x10
  LP55xx_BYTES_PER_PAGE = 0x20

  Engine 1: 0x10 + 0x20 * 1 = 0x30
  Engine 2: 0x10 + 0x20 * 2 = 0x50
  Engine 3: 0x10 + 0x20 * 3 = 0x70

This results in writing to the wrong engine memory, causing pattern
programming to fail.

To correct it, the engine index should be decreased:
  Engine 1: 0x10 + 0x20 * 0 = 0x10
  Engine 2: 0x10 + 0x20 * 1 = 0x30
  Engine 3: 0x10 + 0x20 * 2 = 0x50

1 - https://www.ti.com/lit/ds/symlink/lp5562.pdf

Fixes: 31379a57cf2f ("leds: leds-lp55xx: Generalize update_program_memory function")
Signed-off-by: Andrei Lalaev &lt;andrei.lalaev@anton-paar.com&gt;
Link: https://lore.kernel.org/r/20250820-lp5562-prog-mem-address-v1-1-8569647fa71d@anton-paar.com
Signed-off-by: Lee Jones &lt;lee@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>leds: flash: leds-qcom-flash: Update torch current clamp setting</title>
<updated>2025-10-15T10:03:19Z</updated>
<author>
<name>Fenglin Wu</name>
<email>fenglin.wu@oss.qualcomm.com</email>
</author>
<published>2025-07-29T04:51:22Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c0e4490cbf5ea61e7248e71d9114bc800514bb32'/>
<id>urn:sha1:c0e4490cbf5ea61e7248e71d9114bc800514bb32</id>
<content type='text'>
[ Upstream commit 5974e8f6c3e47ab097c3dd8ece7324d1f88fe739 ]

There is a register to clamp the flash current per LED channel when
safety timer is disabled. It needs to be updated according to the
maximum torch LED current setting to ensure the torch current won't
be clamped unexpectedly.

Fixes: 96a2e242a5dc ("leds: flash: Add driver to support flash LED module in QCOM PMICs")
Signed-off-by: Fenglin Wu &lt;fenglin.wu@oss.qualcomm.com&gt;
Reviewed-by: Konrad Dybcio &lt;konrad.dybcio@oss.qualcomm.com&gt;
Link: https://lore.kernel.org/r/20250729-fix-torch-clamp-issue-v2-1-9b83816437a3@oss.qualcomm.com
Signed-off-by: Lee Jones &lt;lee@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>leds: max77705: Function return instead of variable assignment</title>
<updated>2025-10-15T10:03:19Z</updated>
<author>
<name>Len Bao</name>
<email>len.bao@gmx.us</email>
</author>
<published>2025-07-27T07:56:45Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=dee28f1a389f907e55a7bebdce8387cbd515ccd4'/>
<id>urn:sha1:dee28f1a389f907e55a7bebdce8387cbd515ccd4</id>
<content type='text'>
[ Upstream commit 6e3779e3c6f9dcc9267bf98bef70773a0b13dcbb ]

Coverity noticed that assigning value -EINVAL to 'ret' in the if
statement is useless because 'ret' is overwritten a few lines later.
However, after inspect the code, this warning reveals that we need to
return -EINVAL instead of the variable assignment. So, fix it.

Coverity-id: 1646104
Fixes: aebb5fc9a0d8 ("leds: max77705: Add LEDs support")
Signed-off-by: Len Bao &lt;len.bao@gmx.us&gt;
Link: https://lore.kernel.org/r/20250727075649.34496-1-len.bao@gmx.us
Signed-off-by: Lee Jones &lt;lee@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>treewide: rename GPIO set callbacks back to their original names</title>
<updated>2025-08-07T08:07:06Z</updated>
<author>
<name>Bartosz Golaszewski</name>
<email>bartosz.golaszewski@linaro.org</email>
</author>
<published>2025-07-17T13:21:26Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d9d87d90cc0b10cd56ae353f50b11417e7d21712'/>
<id>urn:sha1:d9d87d90cc0b10cd56ae353f50b11417e7d21712</id>
<content type='text'>
The conversion of all GPIO drivers to using the .set_rv() and
.set_multiple_rv() callbacks from struct gpio_chip (which - unlike their
predecessors - return an integer and allow the controller drivers to
indicate failures to users) is now complete and the legacy ones have
been removed. Rename the new callbacks back to their original names in
one sweeping change.

Signed-off-by: Bartosz Golaszewski &lt;bartosz.golaszewski@linaro.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'leds-next-6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds</title>
<updated>2025-07-31T18:54:01Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2025-07-31T18:54:01Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=831462ff3ec61fd2e6726b534a351a1a722bf2ab'/>
<id>urn:sha1:831462ff3ec61fd2e6726b534a351a1a722bf2ab</id>
<content type='text'>
Pull LED updates from Lee Jones:
 "Improvements &amp; Fixes:

   - A fix for QCOM Flash to prevent incorrect register access when the
     driver is re-bound. This is solved by duplicating a static register
     array during the probe function, which prevents register addresses
     from being miscalculated after multiple binds

   - The LP50xx driver now correctly handles the 'reg' property in
     device tree child nodes to ensure the multi_index is set correctly.
     This prevents issues where LEDs could be controlled incorrectly if
     the device tree nodes were processed in a different order. An error
     is returned if the reg property is missing or out of range

   - Add a Kconfig dependency on between TPS6131x and
     V4L2_FLASH_LED_CLASS to prevent a build failure when the driver is
     built-in and the V4L2 flash infrastructure is a loadable module

   - Fix a potential buffer overflow warning in PCA955x reported by
     older GCC versions by using a more precise format specifier when
     creating the default LED label.

  Cleanups &amp; Refactoring:

   - Correct the MAINTAINERS file entry for the TPS6131X flash LED
     driver to point to the correct device tree binding file name

   - Fix a comment in the Flash Class for the flash_timeout setter to
     "flash timeout" from "flash duration" for accuracy

   - The of_led_get() function is no longer exported as it has no users
     outside of its own module.

  Removals:

   - Revert the commit to configure LED blink intervals for hardware
     offload in the Netdev Trigger. This change was found to break
     existing PHY drivers by putting their LEDs into a permanent,
     unconditional blinking state.

  Device Tree Bindings Updates:

   - Update the binding for LP50xx to document that the child reg
     property is the index within the LED bank. The example was also
     updated to use correct values

   - Update the JNCP5623 binding to add 0x39 as a valid I2C address, as
     it is used by the NCP5623C variant"

* tag 'leds-next-6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds:
  dt-bindings: leds: ncp5623: Add 0x39 as a valid I2C address
  Revert "leds: trigger: netdev: Configure LED blink interval for HW offload"
  leds: pca955x: Avoid potential overflow when filling default_label (take 2)
  leds: Unexport of_led_get()
  leds: tps6131x: Add V4L2_FLASH_LED_CLASS dependency
  dt-bindings: leds: lp50xx: Document child reg, fix example
  leds: leds-lp50xx: Handle reg to get correct multi_index
  leds: led-class-flash:: Fix flash_timeout comment
  MAINTAINERS: Adjust file entry in TPS6131X FLASH LED DRIVER
  leds: flash: leds-qcom-flash: Fix registry access after re-bind
</content>
</entry>
<entry>
<title>Merge tag 'locking-core-2025-07-29' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2025-07-30T01:11:32Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2025-07-30T01:11:32Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=72b8944f147e151e845d976e7f48beff38967499'/>
<id>urn:sha1:72b8944f147e151e845d976e7f48beff38967499</id>
<content type='text'>
Pull locking updates from Ingo Molnar:
 "Locking primitives:

   - Mark devm_mutex_init() as __must_check and fix drivers that didn't
     check the return code (Thomas Weißschuh)

   - Reorganize &lt;linux/local_lock.h&gt; to better expose the internal APIs
     to local variables (Sebastian Andrzej Siewior)

   - Remove OWNER_SPINNABLE in rwsem (Jinliang Zheng)

   - Remove redundant #ifdefs in the mutex code (Ran Xiaokai)

  Lockdep:

   - Avoid returning struct in lock_stats() (Arnd Bergmann)

   - Change `static const` into enum for LOCKF_*_IRQ_* (Arnd Bergmann)

   - Temporarily use synchronize_rcu_expedited() in
     lockdep_unregister_key() to speed things up. (Breno Leitao)

  Rust runtime:

   - Add #[must_use] to Lock::try_lock() (Jason Devers)"

* tag 'locking-core-2025-07-29' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  lockdep: Speed up lockdep_unregister_key() with expedited RCU synchronization
  locking/mutex: Remove redundant #ifdefs
  locking/lockdep: Change 'static const' variables to enum values
  locking/lockdep: Avoid struct return in lock_stats()
  locking/rwsem: Use OWNER_NONSPINNABLE directly instead of OWNER_SPINNABLE
  rust: sync: Add #[must_use] to Lock::try_lock()
  locking/mutex: Mark devm_mutex_init() as __must_check
  leds: lp8860: Check return value of devm_mutex_init()
  spi: spi-nxp-fspi: Check return value of devm_mutex_init()
  local_lock: Move this_cpu_ptr() notation from internal to main header
</content>
</entry>
<entry>
<title>Revert "leds: trigger: netdev: Configure LED blink interval for HW offload"</title>
<updated>2025-07-18T13:26:32Z</updated>
<author>
<name>Daniel Golle</name>
<email>daniel@makrotopia.org</email>
</author>
<published>2025-07-12T15:39:21Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=26f732791f2bcab18f59c61915bbe35225f30136'/>
<id>urn:sha1:26f732791f2bcab18f59c61915bbe35225f30136</id>
<content type='text'>
This reverts commit c629c972b310af41e9e072febb6dae9a299edde6.

While .led_blink_set() would previously put an LED into an unconditional
permanently blinking state, the offending commit now uses same operation
to (also?) set the blink timing of the netdev trigger when offloading.

This breaks many if not all of the existing PHY drivers which offer
offloading LED operations, as those drivers would just put the LED into
blinking state after .led_blink_set() has been called.

Unfortunately the change even made it into stable kernels for unknown
reasons, so it should be reverted there as well.

Fixes: c629c972b310a ("leds: trigger: netdev: Configure LED blink interval for HW offload")
Link: https://lore.kernel.org/linux-leds/c6134e26-2e45-4121-aa15-58aaef327201@lunn.ch/T/#m9d6fe81bbcb273e59f12bbedbd633edd32118387
Suggested-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Golle &lt;daniel@makrotopia.org&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Link: https://lore.kernel.org/r/6dcc77ee1c9676891d6250d8994850f521426a0f.1752334655.git.daniel@makrotopia.org
Signed-off-by: Lee Jones &lt;lee@kernel.org&gt;
</content>
</entry>
</feed>
