RE: [External] Re: [PATCH] thinkpad_acpi: Allow the FnLock LED to change state

[Nitin Joshi1 <njoshi1@lenovo.com>]

Hello Enrico,

>-----Original Message-----
>From: Enrico Weigelt, metux IT consult <info@metux.net>
>Sent: Friday, March 19, 2021 8:36 PM
>To: Nitin Joshi1 <njoshi1@lenovo.com>; Mark RH Pearson
><markpearson@lenovo.com>; Hans de Goede <hdegoede@redhat.com>;
>Esteve Varela Colominas <esteve.varela@gmail.com>; Henrique de Moraes
>Holschuh <ibm-acpi@hmh.eng.br>
>Cc: ibm-acpi-devel@lists.sourceforge.net; platform-driver-
>x86@vger.kernel.org
>Subject: Re: [External] Re: [PATCH] thinkpad_acpi: Allow the FnLock LED to
>change state
>
>On 19.03.21 11:39, Nitin Joshi1 wrote:
>
>Hi,
>
>> Regarding "GMKS" method, it does not have "version" related information.
>So , its unlikely to impact any older platforms.
>> However, I got it confirmed that definition of GMKS method itself doesn't
>include any workaround feature.
>>
>> But, since its getter function , I also think its harmless and if it workaround
>some issue then I don’t see any concern.
>
>How about publishing schematics / specs, so we can confirm what it's really
>doing ?
Thank you for your comment.
I will check regarding this and feedback you later.

>
>In recent decades I've learn to mistrust vendor-provided firmware (especially
>when it comes to acpi). The reason why I'm currently bisecting AMD's AGESA
>blob, in order to completely replace it.
>
>It's a tedious job, had to write my own analysis tool, but step by step making
>progress. (and already learned they've been using a pretty inefficient compiler
>that can't even inline trivial memcpy().
>Probably some older msvc ... :p)
>
>--mtx

Thanks & Regards,
Nitin Joshi 
>
>--
>---
>Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
>werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
>GPG/PGP-Schlüssel zu.
>---
>Enrico Weigelt, metux IT consult
>Free software and Linux embedded engineering info@metux.net -- +49-151-
>27565287