dell platform driver tweaks v2

It's currently hard to follow what maps to what, and it's hard to edit the array. Redo it as a C99-style array.

I generated this using emacs regexes and a python one-liner. objdump says this didn't change the table.

Acked-by Pali Rohár <[email protected]>

Signed-off-by Andy Lutomirski <[email protected]>

Quoted 3 lines · Andy Lutomirski

It's currently hard to follow what maps to what, and it's hard to edit the array. Redo it as a C99-style array.

Quoted 5 lines

I generated this using emacs regexes and a python one-liner. objdump says this didn't change the table.

Acked-by Pali Rohár <[email protected]>

Signed-off-by Andy Lutomirski <[email protected]>

I already have this one in next and I don't see a per-patch changelog for this one - has it changed?

Quoted 10 lines · Darren Hart

Quoted 8 lines · Andy Lutomirski

It's currently hard to follow what maps to what, and it's hard to edit the array. Redo it as a C99-style array.

I generated this using emacs regexes and a python one-liner. objdump says this didn't change the table.

Acked-by Pali Rohár <[email protected]>

Signed-off-by Andy Lutomirski <[email protected]>

Quoted 3 lines

I already have this one in next and I don't see a per-patch changelog for this one - has it changed?

No, it hasn't. I didn't actually mean to include it in the series. Whoops! Please just pretend that I only sent patch 2 onward.

The XPS 13 9350 sends WMI keypress events that aren't enumerated in the DMI table. Add a table listing them. To avoid breaking things that worked before, these un-enumerated hotkeys won't be used if the DMI table maps them to something else.

FWIW, it appears that the DMI table may be a legacy thing and we might want to rethink how we handle events in general. As an example, a whole lot of things map to KEY_PROG3 via the DMI table.

So far, this doesn't send keypress events for any of the new events. Depnding on whether we figure out exactly what needs to happen to get the wireless button working in time for Linux 4.5, we might want to temporarily handle it in dell-wmi.

Signed-off-by Andy Lutomirski <[email protected]>

---
 drivers/platform/x86/dell-wmi.c | 59 ++++++++++++++++++++++++++++++++++++-----
 1 file changed, 52 insertions(+), 7 deletions(-)

drivers/platform/x86/dell-wmi.c +48 -6

index ad6e965c5862..baff658a3621 100644
@@ -161,6 +161,27 @@ static const u16 bios_to_linux_keycode[256] __initconst = {
 	[255]	= KEY_PROG3,
 };
 
+/* These are applied if the hk table is present and doesn't override them. */
+static const struct key_entry dell_wmi_extra_keymap[] __initconst = {
+	/* Fn-lock */
+	{ KE_IGNORE, 0x151, { KEY_RESERVED } },
+
+	/* Change keyboard illumination */
+	{ KE_IGNORE, 0x152, { KEY_KBDILLUMTOGGLE } },
+
+	/*
+	 * Radio disable (notify only -- there is no model for which the
+	 * WMI event is supposed to trigger an action.
+	 */
+	{ KE_IGNORE, 0x153, { KEY_RFKILL } },
+
+	/* RGB keyboard backlight control */
+	{ KE_IGNORE, 0x154, { KEY_RESERVED } },
+
+	/* Stealth mode toggle */
+	{ KE_IGNORE, 0x155, { KEY_RESERVED } },
+};
+
 static struct input_dev *dell_wmi_input_dev;
 
 static void dell_wmi_process_key(int reported_key)

@@ -319,9 +340,10 @@ static const struct key_entry * __init dell_wmi_prepare_new_keymap(void)
 	int hotkey_num = (dell_bios_hotkey_table->header.length - 4) /
 				sizeof(struct dell_bios_keymap_entry);
 	struct key_entry *keymap;
-	int i;
+	int i, pos = 0, num_bios_keys;
 
-	keymap = kcalloc(hotkey_num + 1, sizeof(struct key_entry), GFP_KERNEL);
+	keymap = kcalloc(hotkey_num + ARRAY_SIZE(dell_wmi_extra_keymap),
+			 sizeof(struct key_entry), GFP_KERNEL);
 	if (!keymap)
 		return NULL;
 

@@ -333,14 +355,37 @@ static const struct key_entry * __init dell_wmi_prepare_new_keymap(void)
 				    KEY_RESERVED;
 
 		if (keycode == KEY_KBDILLUMTOGGLE)
-			keymap[i].type = KE_IGNORE;
+			keymap[pos].type = KE_IGNORE;
 		else
-			keymap[i].type = KE_KEY;
-		keymap[i].code = bios_entry->scancode;
-		keymap[i].keycode = keycode;
+			keymap[pos].type = KE_KEY;
+		keymap[pos].code = bios_entry->scancode;
+		keymap[pos].keycode = keycode;
+
+		pos++;
+	}
+
+	num_bios_keys = pos;
+
+	for (i = 0; i < ARRAY_SIZE(dell_wmi_extra_keymap); i++) {
+		int j;
+
+		/*
+		 * Check if we've already found this scancode.  This takes
+		 * quadratic time, but it doesn't matter unless the list
+		 * of extra keys gets very long.
+		 */
+		for (j = 0; j < num_bios_keys; j++)
+			if (keymap[j].code == dell_wmi_extra_keymap[i].code)
+				goto skip;
+
+		keymap[pos] = dell_wmi_extra_keymap[i];
+		pos++;

The XPS 13 9350 sends WMI keypress events that aren't enumerated in the DMI table. Add a table listing them. To avoid breaking things that worked before, these un-enumerated hotkeys won't be used if the DMI table maps them to something else.

FWIW, it appears that the DMI table may be a legacy thing and we might want to rethink how we handle events in general. As an example, a whole lot of things map to KEY_PROG3 via the DMI table.

So far, this doesn't send keypress events for any of the new events. Depnding on whether we figure out exactly what needs to happen to get the wireless button working in time for Linux 4.5, we might want to temporarily handle it in dell-wmi.

Signed-off-by Andy Lutomirski <[email protected]>

---
 drivers/platform/x86/dell-wmi.c | 59 ++++++++++++++++++++++++++++++++++++-----
 1 file changed, 52 insertions(+), 7 deletions(-)

drivers/platform/x86/dell-wmi.c +0 -0

index ad6e965c5862..baff658a3621 100644

drivers/platform/x86/dell-wmi.c +20 -0

+static const struct key_entry dell_wmi_extra_keymap[] __initconst = {
+	/* Fn-lock */
+	{ KE_IGNORE, 0x151, { KEY_RESERVED } },
+
+	/* Change keyboard illumination */
+	{ KE_IGNORE, 0x152, { KEY_KBDILLUMTOGGLE } },
+
+	/*
+	 * Radio disable (notify only -- there is no model for which the
+	 * WMI event is supposed to trigger an action.
+	 */
+	{ KE_IGNORE, 0x153, { KEY_RFKILL } },
+
+	/* RGB keyboard backlight control */
+	{ KE_IGNORE, 0x154, { KEY_RESERVED } },
+
+	/* Stealth mode toggle */
+	{ KE_IGNORE, 0x155, { KEY_RESERVED } },
+};
+
 static struct input_dev *dell_wmi_input_dev;
 
 static void dell_wmi_process_key(int reported_key)

drivers/platform/x86/dell-wmi.c +28 -5

 	if (!keymap)
 		return NULL;
 

@@ -333,14 +355,37 @@ static const struct key_entry * __init dell_wmi_prepare_new_keymap(void)
 				    KEY_RESERVED;
 
 		if (keycode == KEY_KBDILLUMTOGGLE)
-			keymap[i].type = KE_IGNORE;
+			keymap[pos].type = KE_IGNORE;
 		else
-			keymap[i].type = KE_KEY;
-		keymap[i].code = bios_entry->scancode;
-		keymap[i].keycode = keycode;
+			keymap[pos].type = KE_KEY;
+		keymap[pos].code = bios_entry->scancode;
+		keymap[pos].keycode = keycode;
+
+		pos++;
+	}
+
+	num_bios_keys = pos;
+
+	for (i = 0; i < ARRAY_SIZE(dell_wmi_extra_keymap); i++) {
+		int j;
+
+		/*
+		 * Check if we've already found this scancode.  This takes
+		 * quadratic time, but it doesn't matter unless the list
+		 * of extra keys gets very long.
+		 */
+		for (j = 0; j < num_bios_keys; j++)
+			if (keymap[j].code == dell_wmi_extra_keymap[i].code)
+				goto skip;
+
+		keymap[pos] = dell_wmi_extra_keymap[i];
+		pos++;
+
+skip:
+		;
 	}
 
-	keymap[hotkey_num].type = KE_END;
+	keymap[pos].type = KE_END;
 
 	return keymap;
 }

Signature · 1 line

2.5.0

Quoted 27 lines · Andy Lutomirski

The XPS 13 9350 sends WMI keypress events that aren't enumerated in the DMI table. Add a table listing them. To avoid breaking things that worked before, these un-enumerated hotkeys won't be used if the DMI table maps them to something else.

FWIW, it appears that the DMI table may be a legacy thing and we might want to rethink how we handle events in general. As an example, a whole lot of things map to KEY_PROG3 via the DMI table.

So far, this doesn't send keypress events for any of the new events. Depnding on whether we figure out exactly what needs to happen to get the wireless button working in time for Linux 4.5, we might want to temporarily handle it in dell-wmi.

Signed-off-by Andy Lutomirski <[email protected]>

---
 drivers/platform/x86/dell-wmi.c | 59 ++++++++++++++++++++++++++++++++++++-----
 1 file changed, 52 insertions(+), 7 deletions(-)

drivers/platform/x86/dell-wmi.c +0 -0

index ad6e965c5862..baff658a3621 100644
@@ -161,6 +161,27 @@ static const u16 bios_to_linux_keycode[256] __initconst = {
      [255]   = KEY_PROG3,
 };
 

drivers/platform/x86/dell-wmi.c static const u16 bios_to_linux_keycode[256] __initconst = { · line 164

Quoted 1 line

drivers/platform/x86/dell-wmi.c +1 -0

+/* These are applied if the hk table is present and doesn't override them. */

Please do not abbreviate in comments.

Quoted 32 lines

drivers/platform/x86/dell-wmi.c +21 -1

+static const struct key_entry dell_wmi_extra_keymap[] __initconst = {
+     /* Fn-lock */
+     { KE_IGNORE, 0x151, { KEY_RESERVED } },
+
+     /* Change keyboard illumination */
+     { KE_IGNORE, 0x152, { KEY_KBDILLUMTOGGLE } },
+
+     /*
+      * Radio disable (notify only -- there is no model for which the
+      * WMI event is supposed to trigger an action.
+      */
+     { KE_IGNORE, 0x153, { KEY_RFKILL } },
+
+     /* RGB keyboard backlight control */
+     { KE_IGNORE, 0x154, { KEY_RESERVED } },
+
+     /* Stealth mode toggle */
+     { KE_IGNORE, 0x155, { KEY_RESERVED } },
+};
+
 static struct input_dev *dell_wmi_input_dev;
 
 static void dell_wmi_process_key(int reported_key)

@@ -319,9 +340,10 @@ static const struct key_entry * __init dell_wmi_prepare_new_keymap(void)
      int hotkey_num = (dell_bios_hotkey_table->header.length - 4) /
                              sizeof(struct dell_bios_keymap_entry);
      struct key_entry *keymap;
-     int i;
+     int i, pos = 0, num_bios_keys;
 

drivers/platform/x86/dell-wmi.c static const struct key_entry * __init dell_wmi_prepare_new_keymap(void) · line 346

Quoted 3 lines

drivers/platform/x86/dell-wmi.c +2 -1

-     keymap = kcalloc(hotkey_num + 1, sizeof(struct key_entry), GFP_KERNEL);
+     keymap = kcalloc(hotkey_num + ARRAY_SIZE(dell_wmi_extra_keymap),
+                      sizeof(struct key_entry), GFP_KERNEL);

Did something change since our last round of review making the +1 for KE_END no longer necessary? It looks like it should be possible to use all the bios hotkey keymap and all the extra keymap, so we would still need +1 for KE_END.

drivers/platform/x86/dell-wmi.c +5 -0

+		keymap[pos] = dell_wmi_extra_keymap[i];
+		pos++;
+
+skip:
+		;
 	}

drivers/platform/x86/dell-wmi.c static const struct key_entry * __init dell_wmi_prepare_new_keymap(void) · line 380

Quoted 9 lines · On Monday 30 November 2015 17:02:00 Andy Lutomirski wrote:

drivers/platform/x86/dell-wmi.c +9 -0

+             /*
+              * Check if we've already found this scancode.  This takes
+              * quadratic time, but it doesn't matter unless the list
+              * of extra keys gets very long.
+              */
+             for (j = 0; j < num_bios_keys; j++)
+                     if (keymap[j].code == dell_wmi_extra_keymap[i].code)
+                             goto skip;
+

Still, my comment about moving this loop into function is valid...

If DMI lists a hotkey that we don't recognize, log and ignore it instead of trying to map it to keycode 0. I haven't seen this happen, but it will help maintain the key map in the future and it will help avoid sending bogus events.

This also improves the message that we log when we get an unknown key event.

Signed-off-by Andy Lutomirski <[email protected]>

---

 drivers/platform/x86/dell-wmi.c | 25 +++++++++++++++++++++----
 1 file changed, 21 insertions(+), 4 deletions(-)

drivers/platform/x86/dell-wmi.c +21 -4

index baff658a3621..7c3ebda811ca 100644
@@ -118,6 +118,7 @@ struct dell_bios_hotkey_table {
 
 static const struct dell_bios_hotkey_table *dell_bios_hotkey_table;
 
+/* Uninitialized entries here are KEY_RESERVED == 0. */
 static const u16 bios_to_linux_keycode[256] __initconst = {
 	[0]	= KEY_MEDIA,
 	[1]	= KEY_NEXTSONG,

@@ -191,7 +192,8 @@ static void dell_wmi_process_key(int reported_key)
 	key = sparse_keymap_entry_from_scancode(dell_wmi_input_dev,
 						reported_key);
 	if (!key) {
-		pr_info("Unknown key %x pressed\n", reported_key);
+		pr_info("Unknown key with scancode 0x%x pressed\n",
+			reported_key);
 		return;
 	}
 

@@ -350,9 +352,24 @@ static const struct key_entry * __init dell_wmi_prepare_new_keymap(void)
 	for (i = 0; i < hotkey_num; i++) {
 		const struct dell_bios_keymap_entry *bios_entry =
 					&dell_bios_hotkey_table->keymap[i];
-		u16 keycode = bios_entry->keycode < 256 ?
-				    bios_to_linux_keycode[bios_entry->keycode] :
-				    KEY_RESERVED;
+
+		/* Uninitialized entries are 0 aka KEY_RESERVED. */
+		u16 keycode = (bios_entry->keycode <
+			       ARRAY_SIZE(bios_to_linux_keycode)) ?
+			bios_to_linux_keycode[bios_entry->keycode] :
+			KEY_RESERVED;
+		BUILD_BUG_ON(KEY_RESERVED != 0);
+
+		/*
+		 * Log if we find an entry in the DMI table that we don't
+		 * understand.  If this happens, we should figure out what
+		 * the entry means and add it to bios_to_linux_keycode.
+		 */
+		if (keycode == KEY_RESERVED) {
+			pr_info("firmware scancode 0x%x maps to unrecognized keycode 0x%x\n",
+				bios_entry->scancode, bios_entry->keycode);
+			continue;
+		}
 
 		if (keycode == KEY_KBDILLUMTOGGLE)
 			keymap[pos].type = KE_IGNORE;

Signature · 1 line

2.5.0

Quoted 8 lines · Andy Lutomirski

If DMI lists a hotkey that we don't recognize, log and ignore it instead of trying to map it to keycode 0. I haven't seen this happen, but it will help maintain the key map in the future and it will help avoid sending bogus events.

This also improves the message that we log when we get an unknown key event.

Quoted 2 lines

Signed-off-by Andy Lutomirski <[email protected]>

---

Please include the individual patch changelogs here under --- in the patch itself - this helps me build confidence that I am indeed looking at the right patch and the expected changes are here.

Quoted 12 lines · Darren Hart

Quoted 10 lines · Andy Lutomirski

If DMI lists a hotkey that we don't recognize, log and ignore it instead of trying to map it to keycode 0. I haven't seen this happen, but it will help maintain the key map in the future and it will help avoid sending bogus events.

This also improves the message that we log when we get an unknown key event.

Signed-off-by Andy Lutomirski <[email protected]>

---

Quoted 3 lines

Please include the individual patch changelogs here under --- in the patch itself - this helps me build confidence that I am indeed looking at the right patch and the expected changes are here.

Will do in the future -- different maintainers have different preferences here, I think.

Quoted 17 lines · Andy Lutomirski

Quoted 15 lines · Darren Hart

Quoted 10 lines · Andy Lutomirski

If DMI lists a hotkey that we don't recognize, log and ignore it instead of trying to map it to keycode 0. I haven't seen this happen, but it will help maintain the key map in the future and it will help avoid sending bogus events.

This also improves the message that we log when we get an unknown key event.

Signed-off-by Andy Lutomirski <[email protected]>

---

Please include the individual patch changelogs here under --- in the patch itself - this helps me build confidence that I am indeed looking at the right patch and the expected changes are here.

Quoted 2 lines

Will do in the future -- different maintainers have different preferences here, I think.

Oh really?

This is the documented process in Documentation/SubmittingPatches Section 14) The canonical patch format...

Quoted 21 lines · Darren Hart

Quoted 19 lines · Andy Lutomirski

Quoted 9 lines · Darren Hart

Quoted 8 lines · Andy Lutomirski

If DMI lists a hotkey that we don't recognize, log and ignore it instead of trying to map it to keycode 0. I haven't seen this happen, but it will help maintain the key map in the future and it will help avoid sending bogus events.

This also improves the message that we log when we get an unknown key event.

Quoted 6 lines

Quoted 2 lines

Signed-off-by Andy Lutomirski <[email protected]>

---

Please include the individual patch changelogs here under --- in the patch itself - this helps me build confidence that I am indeed looking at the right patch and the expected changes are here.

Will do in the future -- different maintainers have different preferences here, I think.

Quoted 5 lines

Oh really?

This is the documented process in Documentation/SubmittingPatches Section 14) The canonical patch format...

Ingo and the other -tip maintainers seem to like all the comments up front on the cover letter. Or at least they haven't complained yet.

Anyway, I'm giving 'git notes' a try to generate nice change comments for v3.

Pali, this appears to have the one change you asked for (0x%x instead of %d). I've added the Reviewed-by: Pali Rohár <[email protected]> you provided previously pending this change.

drivers/platform/x86/dell-wmi.c static const struct key_entry * __init dell_wmi_prepare_new_keymap(void) · line 361

Quoted 6 lines

drivers/platform/x86/dell-wmi.c +6 -0

+		/* Uninitialized entries are 0 aka KEY_RESERVED. */
+		u16 keycode = (bios_entry->keycode <
+			       ARRAY_SIZE(bios_to_linux_keycode)) ?
+			bios_to_linux_keycode[bios_entry->keycode] :
+			KEY_RESERVED;
+		BUILD_BUG_ON(KEY_RESERVED != 0);

Quoted 3 lines · On Thursday 03 December 2015 15:38:56 Darren Hart wrote:

Pali, this appears to have the one change you asked for (0x%x instead of %d). I've added the Reviewed-by: Pali Rohár <[email protected]> you provided previously pending this change.

Ok.

Quoted 6 lines

drivers/platform/x86/dell-wmi.c static const struct key_entry * __init dell_wmi_prepare_new_keymap(void) · line 361

Quoted 6 lines

drivers/platform/x86/dell-wmi.c +6 -0

+           /* Uninitialized entries are 0 aka KEY_RESERVED. */
+           u16 keycode = (bios_entry->keycode <
+                          ARRAY_SIZE(bios_to_linux_keycode)) ?
+                   bios_to_linux_keycode[bios_entry->keycode] :
+                   KEY_RESERVED;
+           BUILD_BUG_ON(KEY_RESERVED != 0);

Anyway, Darren what do you think is that BUILD_BUG_ON check needed?

Quoted 14 lines · Pali Rohár

Quoted 3 lines · On Thursday 03 December 2015 15:38:56 Darren Hart wrote:

Pali, this appears to have the one change you asked for (0x%x instead of %d). I've added the Reviewed-by: Pali Rohár <[email protected]> you provided previously pending this change.

Ok.

Quoted 6 lines

Quoted 6 lines

drivers/platform/x86/dell-wmi.c +6 -0

+           /* Uninitialized entries are 0 aka KEY_RESERVED. */
+           u16 keycode = (bios_entry->keycode <
+                          ARRAY_SIZE(bios_to_linux_keycode)) ?
+                   bios_to_linux_keycode[bios_entry->keycode] :
+                   KEY_RESERVED;
+           BUILD_BUG_ON(KEY_RESERVED != 0);

Quoted 2 lines

Anyway, Darren what do you think is that BUILD_BUG_ON check needed?

Sorry, my bad. IIRC Darren made that change, I made the other change, and then I resent and we lost this one.

Darren, want to fix it in your tree? If not, I'll include the BUILD_BUG_ON deletion in v3.