Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <c5773d2f-da0d-ef73-694e-a7ae9d98610d@redhat.com>
Date:   Tue, 8 Nov 2022 16:09:42 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.1
Subject: Re: [PATCH] platform/x86: ideapad-laptop: Fix fn-lock LED on Yoga
 14ITL5 laptops
Content-Language: en-US, nl
To:     Ike Panhc <ike.pan@canonical.com>,
        "Rawat, Arnav" <arnavr3@illinois.edu>,
        "markgross@kernel.org" <markgross@kernel.org>,
        Meng Dong <whenov@gmail.com>
Cc:     "platform-driver-x86@vger.kernel.org" 
        <platform-driver-x86@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
References: <4785687.31r3eYUQgx@fedora>
 <0bbca08c-6caf-e830-ca3d-105cf72015d5@canonical.com>
From:   Hans de Goede <hdegoede@redhat.com>
In-Reply-To: <0bbca08c-6caf-e830-ca3d-105cf72015d5@canonical.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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