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

[Lee Jones <lee@kernel.org>]

--- checkpatch.pl (27 issues) ---
Line 1: ERROR: spaces required around that ':' (ctx:VxE)
Line 3: ERROR: spaces required around that ':' (ctx:VxE)
Line 5: ERROR: spaces required around that ':' (ctx:VxE)
Line 7: ERROR: need consistent spacing around '+' (ctx:WxV)
Line 7: ERROR: spaces required around that ':' (ctx:VxE)
Line 10: WARNING: space prohibited between function name and open parenthesis '('
Line 13: WARNING: space prohibited between function name and open parenthesis '('
Line 14: ERROR: spaces required around that ':' (ctx:VxE)
Line 24: ERROR: space required before that '-' (ctx:VxV)
Line 28: ERROR: spaces required around that ':' (ctx:VxE)
Line 29: ERROR: spaces required around that ':' (ctx:VxW)
Line 31: ERROR: spaces required around that ':' (ctx:VxW)
Line 33: ERROR: spaces required around that ':' (ctx:VxW)
Line 35: ERROR: spaces required around that ':' (ctx:VxW)
Line 37: ERROR: spaces required around that ':' (ctx:VxW)
Line 39: ERROR: spaces required around that ':' (ctx:VxW)
Line 41: ERROR: spaces required around that ':' (ctx:VxW)
Line 43: ERROR: spaces required around that ':' (ctx:VxW)
Line 45: ERROR: spaces required around that ':' (ctx:VxW)
Line 47: ERROR: spaces required around that ':' (ctx:VxW)
Line 50: ERROR: space required before that '!' (ctx:VxE)
Line 57: ERROR: trailing whitespace
Line 60: ERROR: trailing whitespace
Line 61: ERROR: trailing whitespace
Line 71: ERROR: trailing whitespace
Line 72: ERROR: trailing whitespace
Line 84: ERROR: spaces required around that '?' (ctx:VxE)
----------------------------------

On Tue, 10 Nov 2026, Ilpo Järvinen wrote:

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

Take a look at my reply to the 0th patch.

For some reason my b4 doesn't do this.  It must be an option?

What command do you use?

My assumption is that you omit `b4 am`s `-P` option, so it thinks it's
working on the whole set, rather than just the sub-set?

-- 
Lee Jones