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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <c5773d2f-da0d-ef73-694e-a7ae9d98610d@redhat.com>
Date:   Tue, 8 Nov 2022 16:09:42 +0100
From:   Hans de Goede <hdegoede@...hat.com>
To:     Ike Panhc <ike.pan@...onical.com>,
        "Rawat, Arnav" <arnavr3@...inois.edu>,
        "markgross@...nel.org" <markgross@...nel.org>,
        Meng Dong <whenov@...il.com>
Cc:     "platform-driver-x86@...r.kernel.org" 
        <platform-driver-x86@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] platform/x86: ideapad-laptop: Fix fn-lock LED on Yoga
 14ITL5 laptops

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