Re: [PATCH v7 00/13] leds: Add support for hardware-initiated hardware control trigger transition

["Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 3370 bytes --]

On Tue, 10 Nov 2026, Lee Jones wrote:

> On Mon, 09 Nov 2026, Ilpo Järvinen wrote:
> 
> > On Mon, 21 Sep 2026 03:40:14 +0800, Rong Zhang wrote:
> > 
> > > Some laptops can tune their keyboard backlight according to ambient
> > > light sensors (auto mode). This capability is essentially a hardware
> > > control trigger. Meanwhile, such laptops also offer a shrotcut for
> > > cycling through brightness levels and auto mode. For example, on
> > > ThinkBook, pressing Fn+Space ("shortcut") cycles keyboard backlight
> > > levels in the following sequence:
> > > 
> > > [...]
> > 
> > Thank you for your contribution, it has been applied to my local
> > review-ilpo-next branch. Note it will show up in the public
> > platform-drivers-x86/review-ilpo-next branch only once I've pushed my
> > local branch there, which might take a while.
> > 
> > FYI [if applicable to your patch], as per Linus' policy change, also
> > fixes are mostly routed through for-next unless the fix is for a
> > commit introduced in the most recent cycle or is clearly a regression
> > fix.
> > 
> > The list of commits applied:
> > [01/13] leds: class: Always protect brightness_show() with led_access
> >         (no commit info)
> > [02/13] leds: trigger: Move led_trigger_is_hw_controlled() to the right place
> >         (no commit info)
> > [03/13] leds: class: Remove hardware control trigger when writing brightness
> >         (no commit info)
> > [04/13] leds: trigger: Move led_trigger_group to the right place
> >         (no commit info)
> > [05/13] leds: trigger: Add hw_offloaded() callback and provide trigger_may_offload_to_hw attribute
> >         (no commit info)
> > [06/13] leds: cros_ec: Implement hw_offloaded() trigger callback
> >         (no commit info)
> > [07/13] leds: turris-omnia: Implement hw_offloaded() trigger callback and declare hw_control_trigger
> >         (no commit info)
> > [08/13] leds: trigger: netdev: Implement hw_offloaded() callback
> >         (no commit info)
> > [09/13] leds: trigger: Enforce strict checks in led_trigger_is_hw_controlled()
> >         (no commit info)
> > [10/13] leds: trigger: Add led_trigger_notify_hw_control_changed() interface
> >         (no commit info)
> 
> This is super confusing!

I know it is but it's how b4 thankyou mails appear.

> Where does this list come from?

The list comes from the original series that b4 caches somewhere.
I deleted the patches 1-10 and only applied mbox that contained patches 
11-13.

When constructing thankyou mail, b4 seems to take the cached list of 
patches the series had and does not find 1-10 applied into my tree by me 
so it says (no commit info). The rest appear as expected:

> > [11/13] platform/x86: ideapad-laptop: Serialize keyboard backlight tracking
> >         commit: d288a6f989b7b9e6a730140c601987b886af327e
> > [12/13] platform/x86: ideapad-laptop: Decouple hardware & classdev brightness for keyboard backlight
> >         commit: 7d6c073d181d7855561831cb4bba17dc9b7d4aa9
> > [13/13] platform/x86: ideapad-laptop: Fully support auto keyboard backlight
> >         commit: 5d805ca01382d63d54c9984e7f19922c4ae6f3dc

Of course it would be much less confusing if it never showed those no 
commit info entries at all but unfortunately I don't think I can control 
that, sorry.

-- 
 i.