[PATCH] platform/x86: ideapad-laptop: Fix fn-lock LED on Yoga 14ITL5 laptops

[PATCH] platform/x86: ideapad-laptop: Fix fn-lock LED on Yoga 14ITL5 laptops

[Rawat, Arnav]

From 5bce4f5860d54e125715d896f144add831d19483 Mon Sep 17 00:00:00 2001
From: Arnav Rawat <arnavr3@illinois.edu>
Date: Mon, 7 Nov 2022 17:12:41 -0600
Subject: [PATCH] platform/x86: ideapad-laptop: Fix fn-lock LED on Yoga 14ITL5
 laptops

The commit 3ae86d2d4704796ee658a34245cb86e68c40c5d7: Fix Legion 5 Fnlock LED
set the WMI id for the fn-lock event on some Legion 5 laptops. However,
the same WMI ID is also sent on some Yoga laptops. Here, setting the fn-lock
state is not valid behavior, and causes the ec to spam interrupts until the
laptop is rebooted, so include a check for this line of laptops.

Signed-off-by: Arnav Rawat <arnavr3@illinois.edu>
---
 drivers/platform/x86/ideapad-laptop.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/x86/ideapad-laptop.c b/drivers/platform/x86/
ideapad-laptop.c
index abd0c81d62c4..f529410d7015 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -1501,7 +1501,7 @@ static void ideapad_wmi_notify(u32 value, void *context)
 		ideapad_input_report(priv, value);
 		break;
 	case 208:
-		if (!eval_hals(priv->adev->handle, &result)) {
+		if (!eval_hals(priv->adev->handle, &result) && 
strcmp(dmi_get_system_info(DMI_PRODUCT_NAME), "82BG")) {
 			bool state = test_bit(HALS_FNLOCK_STATE_BIT, 
&result);
 
 			exec_sals(priv->adev->handle, state ? 
SALS_FNLOCK_ON : SALS_FNLOCK_OFF);
-- 
2.37.3

Re: [PATCH] platform/x86: ideapad-laptop: Fix fn-lock LED on Yoga 14ITL5 laptops

[Ike Panhc]

On 11/8/22 07:25, Rawat, Arnav wrote:
> From 5bce4f5860d54e125715d896f144add831d19483 Mon Sep 17 00:00:00 2001
> From: Arnav Rawat <arnavr3@illinois.edu>
> Date: Mon, 7 Nov 2022 17:12:41 -0600
> Subject: [PATCH] platform/x86: ideapad-laptop: Fix fn-lock LED on Yoga 14ITL5
>  laptops
> 
> The commit 3ae86d2d4704796ee658a34245cb86e68c40c5d7: Fix Legion 5 Fnlock LED
> set the WMI id for the fn-lock event on some Legion 5 laptops. However,
> the same WMI ID is also sent on some Yoga laptops. Here, setting the fn-lock
> state is not valid behavior, and causes the ec to spam interrupts until the
> laptop is rebooted, so include a check for this line of laptops.
> 
> Signed-off-by: Arnav Rawat <arnavr3@illinois.edu>

Thanks.

But I will be more comfortable if we also check DMI_BOARD_NAME or
DMI_PRODUCT_VERSION, not just DMI_PRODUCT_NAME.

and it will be good to create a table like ideapad_dytc_v4_allow_table.
I have a feeling that your ideapad is not the only one has this issue.

--
Ike

Re: [PATCH] platform/x86: ideapad-laptop: Fix fn-lock LED on Yoga 14ITL5 laptops

[Hans de Goede]

Hi,

On 11/8/22 06:58, Ike Panhc wrote:
> On 11/8/22 07:25, Rawat, Arnav wrote:
>> From 5bce4f5860d54e125715d896f144add831d19483 Mon Sep 17 00:00:00 2001
>> From: Arnav Rawat <arnavr3@illinois.edu>
>> Date: Mon, 7 Nov 2022 17:12:41 -0600
>> Subject: [PATCH] platform/x86: ideapad-laptop: Fix fn-lock LED on Yoga 14ITL5
>>  laptops
>>
>> The commit 3ae86d2d4704796ee658a34245cb86e68c40c5d7: Fix Legion 5 Fnlock LED
>> set the WMI id for the fn-lock event on some Legion 5 laptops. However,
>> the same WMI ID is also sent on some Yoga laptops. Here, setting the fn-lock
>> state is not valid behavior, and causes the ec to spam interrupts until the
>> laptop is rebooted, so include a check for this line of laptops.
>>
>> Signed-off-by: Arnav Rawat <arnavr3@illinois.edu>
> 
> Thanks.
> 
> But I will be more comfortable if we also check DMI_BOARD_NAME or
> DMI_PRODUCT_VERSION, not just DMI_PRODUCT_NAME.
> 
> and it will be good to create a table like ideapad_dytc_v4_allow_table.
> I have a feeling that your ideapad is not the only one has this issue.

I agree IMHO it would be better to find out the DMI strings of the
laptop for which this fix was added and then only do the:

	exec_sals(priv->adev->handle, state ? SALS_FNLOCK_ON : SALS_FNLOCK_OFF);

call on that model. So move to an allow-list model, rather then using
a deny-list model.

Especially also since the behavior without the call is a LED not turning on,
which is something we can live with.

Where as the behavior when doing the call on the wrong model is an interrupt
storm which is a much bigger problem.

I have added Meng Dong the author of the patch adding the:

	exec_sals(priv->adev->handle, state ? SALS_FNLOCK_ON : SALS_FNLOCK_OFF);

call to the To list of this email.

The commit msg of 3ae86d2d4704796 ("platform/x86: ideapad-laptop: Fix Legion 5 Fn lock LED")

mentions this bug:

https://bugzilla.kernel.org/show_bug.cgi?id=212671

So we may want to ask the reporter to test any fixes we come up with here.

The commit msg says the fix was needed on a Legion 5 (R7000P)

I have found this dmidecode for this laptop model, which should
give us enough info to start a DMI based allow-list for this:

https://github.com/linuxhw/DMI/blob/master/Notebook/Lenovo/Legion/Legion%20R7000P2020H%2082GR/D5E3FD9569F2

Regards,

Hans