linux-kernel - Re: [PATCH 2/3] platform/x86: dell-wmi: add new keymap type 0x0012

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: <18ead8db-eb6f-8492-f5a4-4175de51e659@paritcher.com>
Date:   Mon, 8 Jun 2020 16:12:50 -0400
From:   Y Paritcher <y.linux@...itcher.com>
To:     Pali Rohár <pali@...nel.org>
Cc:     linux-kernel@...r.kernel.org, platform-driver-x86@...r.kernel.org,
        Matthew Garrett <mjg59@...f.ucam.org>
Subject: Re: [PATCH 2/3] platform/x86: dell-wmi: add new keymap type 0x0012

On 6/8/20 4:50 AM, Pali Rohár wrote:
> Hello!
> 
> On Monday 08 June 2020 00:22:25 Y Paritcher wrote:
>> Ignore events with a type of 0x0012 and a code of 0xe035,
>> this silences the following messages being logged when
>> pressing the Fn-lock key on a Dell Inspiron 5593:
> 
> Could you please explain why to ignore these events instead of sending
> them to userspace via input layer? I think that userspace can be
> interested in knowing when Fn lock key was pressed and I can imagine
> that some it can use it for some purposes.
> 

I followed what was already done for the Fn lock key on other models.
The Fn lock key toggle is adjusted by the keyboard controller so there is 
nothing userspace should do with it.

If this is wrong the behavior should be changed for all Fn lock key entries.
>> dell_wmi: Unknown WMI event type 0x12
>> dell_wmi: Unknown key with type 0x0012 and code 0xe035 pressed
> 
> These messages are printed to inform about fact that some events were
> not processed. And they should not be silenced without reason. If for
> some reasons it is needed to completely ignore some kind of events then
> this reason should be documented (e.g. in commit message) so other
> developers would know why that code is there. Not all Linux developers
> have all those Dell machines for testing so they do not know all
> hardware details.
> 

I could be wrong, but i understood these messages to inform about a unknown event.
once the event is identified there should be no reason for them.
>> Signed-off-by: Y Paritcher <y.linux@...itcher.com>
>> ---
>>  drivers/platform/x86/dell-wmi.c | 17 +++++++++++++++++
>>  1 file changed, 17 insertions(+)
>>
>> diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
>> index 0b4f72f923cd..f37e7e9093c2 100644
>> --- a/drivers/platform/x86/dell-wmi.c
>> +++ b/drivers/platform/x86/dell-wmi.c
>> @@ -334,6 +334,14 @@ static const struct key_entry dell_wmi_keymap_type_0011[] = {
>>  	{ KE_IGNORE, KBD_LED_AUTO_100_TOKEN, { KEY_RESERVED } },
>>  };
>>  
>> +/*
>> + * Keymap for WMI events of type 0x0012
>> + */
>> +static const struct key_entry dell_wmi_keymap_type_0012[] = {
>> +	/* Fn-lock button pressed */
>> +	{ KE_IGNORE, 0xe035, { KEY_RESERVED } },
>> +};
>> +
>>  static void dell_wmi_process_key(struct wmi_device *wdev, int type, int code)
>>  {
>>  	struct dell_wmi_priv *priv = dev_get_drvdata(&wdev->dev);
>> @@ -425,6 +433,7 @@ static void dell_wmi_notify(struct wmi_device *wdev,
>>  			break;
>>  		case 0x0010: /* Sequence of keys pressed */
>>  		case 0x0011: /* Sequence of events occurred */
>> +		case 0x0012: /* Sequence of events occurred */
> 
> It is really sequence of events? Because you wrote that Fn-lock key was
> pressed (and not generic event). Also it is really sequence? And not
> just one event/key-press (with possibility of some additional details in
> buffer)? It would be nice to put documentation for this type of events
> to check and review that implementation is correct.
> 

see Mario Limonciello's answer
>>  			for (i = 2; i < len; ++i)
>>  				dell_wmi_process_key(wdev, buffer_entry[1],
>>  						     buffer_entry[i]);
>> @@ -556,6 +565,7 @@ static int dell_wmi_input_setup(struct wmi_device *wdev)
>>  			 ARRAY_SIZE(dell_wmi_keymap_type_0000) +
>>  			 ARRAY_SIZE(dell_wmi_keymap_type_0010) +
>>  			 ARRAY_SIZE(dell_wmi_keymap_type_0011) +
>> +			 ARRAY_SIZE(dell_wmi_keymap_type_0012) +
>>  			 1,
>>  			 sizeof(struct key_entry), GFP_KERNEL);
>>  	if (!keymap) {
>> @@ -600,6 +610,13 @@ static int dell_wmi_input_setup(struct wmi_device *wdev)
>>  		pos++;
>>  	}
>>  
>> +	/* Append table with events of type 0x0012 */
>> +	for (i = 0; i < ARRAY_SIZE(dell_wmi_keymap_type_0012); i++) {
>> +		keymap[pos] = dell_wmi_keymap_type_0012[i];
>> +		keymap[pos].code |= (0x0012 << 16);
>> +		pos++;
>> +	}
>> +
>>  	/*
>>  	 * Now append also table with "legacy" events of type 0x0000. Some of
>>  	 * them are reported also on laptops which have scancodes in DMI.
>> -- 
>> 2.27.0
>>