Re: [PATCH v3 7/7] platform/x86: thinkpad_acpi: Reconcile EC level on resume

["Mark Pearson" <mpearson-lenovo@squebb.ca>]

On Sun, Nov 15, 2026, at 3:20 AM, Rong Zhang wrote:
> Hi Qiling,
>
> On Sun, 2026-11-15 at 01:48 +0800, Qiling Zhu wrote:
>> The firmware does not always restore the keyboard backlight level across
>> sleep: after hibernation from auto mode the EC comes back with the
>> backlight off, without emitting a notification.  The cached level and a
>> possibly still-active auto trigger then desynchronize from the hardware
>> until the next user action.
>> 
>> Check the EC level on resume on auto-mode machines and route it through
>> the regular notification path, which also deactivates the auto trigger
>> if the firmware left auto mode.
>> 
>> Signed-off-by: Qiling Zhu <kmatzkaczor244@gmail.com>
>> ---
>>  drivers/platform/x86/lenovo/thinkpad_acpi.c | 11 ++++++++++-
>>  1 file changed, 10 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/platform/x86/lenovo/thinkpad_acpi.c b/drivers/platform/x86/lenovo/thinkpad_acpi.c
>> index f11e61417..802e0d53b 100644
>> --- a/drivers/platform/x86/lenovo/thinkpad_acpi.c
>> +++ b/drivers/platform/x86/lenovo/thinkpad_acpi.c
>> @@ -5395,13 +5395,22 @@ static void kbdlight_suspend(void)
>>  	led_classdev_suspend(led_cdev);
>>  }
>>  
>> +static void kbdlight_notify_change(void);
>
> Nooooo. Add it to the right position in PATCH 2.
>
>> +
>>  static void kbdlight_resume(void)
>>  {
>>  	if (!tp_features.kbdlight)
>>  		return;
>>  
>> -	if (tp_features.kbdlight_auto)
>> +	if (tp_features.kbdlight_auto) {
>> +		/*
>> +		 * The firmware may not restore auto mode: after hibernation
>> +		 * from level 3 it comes back with the backlight off.  Check
>> +		 * the EC level and reconcile.
>> +		 */
>> +		kbdlight_notify_change();
>
> If the LED core doesn't detach the trigger before hibernation, please
> restore the last hw brightness instead of notifying any change.
>
> If using led_classdev_{suspend,resume}() causes pain when it comes to hw
> control trigger, we can get rid of them completely (i.e., on all models)
> by tracking the suspend status and restoring hw brightness properly
> ourselves. With your previous changes to kbdlight_brightness, doing so
> should be easy.
>
I was wondering the same. I can bet we'll end up with FW 'bugs' where some platforms don't put it back as they should.
I'll get those fixed whenever possible....but I'm thinking maybe if we just check/set in SW anyway that's not a bad thing.

Mark