linux-kernel - Re: [PATCH 2/2] platform/x86: panasonic-laptop: allow to use all hotkeys

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <d80789bc-a8fc-de5f-164a-75adf7097311@message-id.googlemail.com>
Date:   Wed, 15 Jun 2022 19:10:12 +0200
From:   Stefan Seyfried <stefan.seyfried@...glemail.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Kenneth Chan <kenneth.t.chan@...il.com>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Stefan Seyfried <seife+kernel@...systems.com>
Subject: Re: [PATCH 2/2] platform/x86: panasonic-laptop: allow to use all
 hotkeys

Hi Andy,

On 15.06.22 13:24, Andy Shevchenko wrote:
> On Wed, Jun 15, 2022 at 1:21 PM Andy Shevchenko
> <andy.shevchenko@...il.com> wrote:
>> On Sun, Jun 12, 2022 at 3:54 PM <stefan.seyfried@...glemail.com> wrote:
> 
>> We usually add module options in very bad cases where it's very useful
>> for debugging or when some devices require the opposite settings while
>> can't be distinguished automatically. Here I do not see either of such
>> cases. Hence, I would prefer to see a DMI based quirk as it's done a
>> lot in the PDx86 drivers. Can you do that?

I can do that, but... below ;-)

> Looking into the code of the culprit patch, have you tried to add a
> debug pr_info() and see what value is in the result? Perhaps you may
> just sort out by correcting that.

The driver is working fine, it's just that Kenneth's machine is getting 
most of the hotkey events (I'd guess all but sleep, hibernate, battery) 
twice. That's why he disabled the key generation from the panasonic_acpi 
driver for them. (My guess is that on his CF-W5, they are also coming in 
via normal keyboard input path). My CF-51 does only generate them via 
acpi, so if they are not generated, I get nothing.
Hence the module parameter so that the two known users of this module 
(Kenneth and me) can adjust this to their needs.

Now about the DMI match: I can do that.
But let's face it: the panasonic laptops are pretty rare in the wild, so 
even if I'm "whitelisting" the CF-51, then probably other models will 
need the same treatment and we have no real way of finding out which 
ones, unless people complain. (For example my CF-51 is about 17 years 
old now and I just pulled it out and updated it to the latest and 
greatest "because I can". That's also why it has taken me so long to 
even notice the driver was broken for me. So people not complaining will 
not mean "nothing is broken" but rather "this code has not many users").
So even if I add the DMI match (which is a good idea anyhow because then 
"my" model will work out of the box, while right now I need to add a 
module parameter or switch it on later), I'd still vote for having a 
possibility for overriding the DMI results.
Would that be OK?

Best regards,

	Stefan
-- 
Stefan Seyfried

"For a successful technology, reality must take precedence over
  public relations, for nature cannot be fooled." -- Richard Feynman