All of lore.kernel.org
 help / color / mirror / Atom feed
* [GIT PULL] LEDs for v6.17
@ 2025-07-30 15:10 Lee Jones
  2025-07-31 19:05 ` Linus Torvalds
  2025-07-31 19:07 ` pr-tracker-bot
  0 siblings, 2 replies; 4+ messages in thread
From: Lee Jones @ 2025-07-30 15:10 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List, Pavel Machek

Good afternoon Linus,

The following changes since commit 19272b37aa4f83ca52bdf9c16d5d81bdd1354494:

  Linux 6.16-rc1 (2025-06-08 13:44:43 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds.git tags/leds-next-6.17

for you to fetch changes up to 4903924ac7ef31fbbe48b3261b1bc86ce6cd7e97:

  dt-bindings: leds: ncp5623: Add 0x39 as a valid I2C address (2025-07-23 10:32:36 +0100)

----------------------------------------------------------------
LEDs for for v6.17

- Improvements & Fixes
  * A fix has been implemented in 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.
  * A Kconfig dependency on between TPS6131x and V4L2_FLASH_LED_CLASS has been
    added to prevent a build failure when the driver is built-in and the V4L2
    flash infrastructure is a loadable module.
  * A potential buffer overflow warning in PCA955x was reported by older GCC
    versions has been fixed by using a more precise format specifier when
    creating the default LED label.

- Cleanups & Refactoring
  * The MAINTAINERS file entry for the TPS6131X flash LED driver has been
    corrected to point to the correct device tree binding file name.
  * A comment in the Flash Class for the flash_timeout setter has been
    corrected 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
  * The commit to configure LED blink intervals for hardware offload in the
    Netdev Trigger has been reverted. This change was found to break existing
    PHY drivers by putting their LEDs into a permanent, unconditional blinking
    state.

- Device Tree Bindings Updates
  * The binding for LP50xx has been updated to document that the child reg
    property is the index within the LED bank. The example was also updated to
    use correct values.
  * The JNCP5623 binding has been updated to add 0x39 as a valid I2C address,
    as it is used by the NCP5623C variant.

----------------------------------------------------------------
Andy Shevchenko (2):
      leds: Unexport of_led_get()
      leds: pca955x: Avoid potential overflow when filling default_label (take 2)

Arnd Bergmann (1):
      leds: tps6131x: Add V4L2_FLASH_LED_CLASS dependency

Daniel Golle (1):
      Revert "leds: trigger: netdev: Configure LED blink interval for HW offload"

Fabio Estevam (1):
      dt-bindings: leds: ncp5623: Add 0x39 as a valid I2C address

Johan Adolfsson (2):
      leds: leds-lp50xx: Handle reg to get correct multi_index
      dt-bindings: leds: lp50xx: Document child reg, fix example

Krzysztof Kozlowski (1):
      leds: flash: leds-qcom-flash: Fix registry access after re-bind

Lukas Bulwahn (1):
      MAINTAINERS: Adjust file entry in TPS6131X FLASH LED DRIVER

Richard Leitner (1):
      leds: led-class-flash:: Fix flash_timeout comment

 .../devicetree/bindings/leds/leds-lp50xx.yaml         | 19 ++++++++++++-------
 .../devicetree/bindings/leds/onnn,ncp5623.yaml        |  4 +++-
 MAINTAINERS                                           |  2 +-
 drivers/leds/flash/Kconfig                            |  1 +
 drivers/leds/flash/leds-qcom-flash.c                  | 15 +++++++++++----
 drivers/leds/led-class.c                              |  3 +--
 drivers/leds/leds-lp50xx.c                            | 11 ++++++++++-
 drivers/leds/leds-pca955x.c                           |  4 ++--
 drivers/leds/trigger/ledtrig-netdev.c                 | 16 +++-------------
 include/linux/led-class-flash.h                       |  2 +-
 include/linux/leds.h                                  |  1 -
 11 files changed, 45 insertions(+), 33 deletions(-)

-- 
Lee Jones [李琼斯]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [GIT PULL] LEDs for v6.17
  2025-07-30 15:10 [GIT PULL] LEDs for v6.17 Lee Jones
@ 2025-07-31 19:05 ` Linus Torvalds
  2025-08-05 13:16   ` Lee Jones
  2025-07-31 19:07 ` pr-tracker-bot
  1 sibling, 1 reply; 4+ messages in thread
From: Linus Torvalds @ 2025-07-31 19:05 UTC (permalink / raw)
  To: Lee Jones; +Cc: Linux Kernel Mailing List, Pavel Machek

Just a small and unimportant nit:

On Wed, 30 Jul 2025 at 08:10, Lee Jones <lee@kernel.org> wrote:
>
>  * A potential buffer overflow warning in PCA955x was reported by older GCC
>   versions has been fixed by using a more precise format specifier when
>   creating the default LED label.

I'm trying to encourage people to use more straightforward language in
commit messages, and I ended up rewriting some of yours.

In particular, try to avoid passive voice.

So instead of "A fix has been implemented to Xyz" just say that it
contains "A fix for Xyz" (or even just "Fix Xyz").

Straight and to the point.

As an example, I edited that "was reported by gcc" and "has been
fixed", so that bullet point became

       - 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.

in my tree.

This is not a huge deal, I just wanted to point out that "simple and
to the point" is a good thing, and talking about fixes in some kind of
passive voice is just strange.

            Linus

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [GIT PULL] LEDs for v6.17
  2025-07-30 15:10 [GIT PULL] LEDs for v6.17 Lee Jones
  2025-07-31 19:05 ` Linus Torvalds
@ 2025-07-31 19:07 ` pr-tracker-bot
  1 sibling, 0 replies; 4+ messages in thread
From: pr-tracker-bot @ 2025-07-31 19:07 UTC (permalink / raw)
  To: Lee Jones; +Cc: Linus Torvalds, Linux Kernel Mailing List, Pavel Machek

The pull request you sent on Wed, 30 Jul 2025 16:10:13 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds.git tags/leds-next-6.17

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/831462ff3ec61fd2e6726b534a351a1a722bf2ab

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [GIT PULL] LEDs for v6.17
  2025-07-31 19:05 ` Linus Torvalds
@ 2025-08-05 13:16   ` Lee Jones
  0 siblings, 0 replies; 4+ messages in thread
From: Lee Jones @ 2025-08-05 13:16 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List, Pavel Machek

On Thu, 31 Jul 2025, Linus Torvalds wrote:

> Just a small and unimportant nit:
> 
> On Wed, 30 Jul 2025 at 08:10, Lee Jones <lee@kernel.org> wrote:
> >
> >  * A potential buffer overflow warning in PCA955x was reported by older GCC
> >   versions has been fixed by using a more precise format specifier when
> >   creating the default LED label.
> 
> I'm trying to encourage people to use more straightforward language in
> commit messages, and I ended up rewriting some of yours.
> 
> In particular, try to avoid passive voice.
> 
> So instead of "A fix has been implemented to Xyz" just say that it
> contains "A fix for Xyz" (or even just "Fix Xyz").
> 
> Straight and to the point.
> 
> As an example, I edited that "was reported by gcc" and "has been
> fixed", so that bullet point became
> 
>        - 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.
> 
> in my tree.
> 
> This is not a huge deal, I just wanted to point out that "simple and
> to the point" is a good thing, and talking about fixes in some kind of
> passive voice is just strange.

Thanks for fixing.

I'll try to bear it in mind in the future.

-- 
Lee Jones [李琼斯]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2025-08-05 13:16 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-07-30 15:10 [GIT PULL] LEDs for v6.17 Lee Jones
2025-07-31 19:05 ` Linus Torvalds
2025-08-05 13:16   ` Lee Jones
2025-07-31 19:07 ` pr-tracker-bot

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.