Skip to contentSkip to conversation

Patch "usb:xhci:Add quirk for Certain failing HP keyboard on reset after resume" has been added to the 4.4-stable tree

PATCH [email protected] 1 participant 1 message Aug 14, 2017

Subsystems (3)
lore
Share & tools
lore

[email protected]

author maintainer Applied
#0 lore raw

This is a note to let you know that I've just added the patch titled

usb:xhci:Add quirk for Certain failing HP keyboard on reset after resume

to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
usb-xhci-add-quirk-for-certain-failing-hp-keyboard-on-reset-after-resume.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

Quoted 1 line

From e788787ef4f9c24aafefc480a8da5f92b914e5e6 Mon Sep 17 00:00:00 2001

From: Sandeep Singh <[email protected]>
Date: Fri, 4 Aug 2017 16:35:56 +0530
Subject: usb:xhci:Add quirk for Certain failing HP keyboard on reset after resume

From: Sandeep Singh <[email protected]>

commit e788787ef4f9c24aafefc480a8da5f92b914e5e6 upstream.

Certain HP keyboards would keep inputting a character automatically which is the wake-up key after S3 resume

On some AMD platforms USB host fails to respond (by holding resume-K) to USB device (an HP keyboard) resume request within 1ms (TURSM) and ensures that resume is signaled for at least 20 ms (TDRSMDN), which is defined in USB 2.0 spec. The result is that the keyboard is out of function.

In SNPS USB design, the host responds to the resume request only after system gets back to S0 and the host gets to functional after the internal HW restore operation that is more than 1 second after the initial resume request from the USB device.

As a workaround for specific keyboard ID(HP Keyboards), applying port reset after resume when the keyboard is plugged in.

---
 drivers/usb/core/quirks.c     |    1 +
 drivers/usb/host/pci-quirks.c |   17 ++++++++++++-----
 2 files changed, 13 insertions(+), 5 deletions(-)
drivers/usb/core/quirks.c +1 -0
@@ -252,6 +252,7 @@ static const struct usb_device_id usb_am
 	{ USB_DEVICE(0x093a, 0x2500), .driver_info = USB_QUIRK_RESET_RESUME },
 	{ USB_DEVICE(0x093a, 0x2510), .driver_info = USB_QUIRK_RESET_RESUME },
 	{ USB_DEVICE(0x093a, 0x2521), .driver_info = USB_QUIRK_RESET_RESUME },
+	{ USB_DEVICE(0x03f0, 0x2b4a), .driver_info = USB_QUIRK_RESET_RESUME },
 
 	/* Logitech Optical Mouse M90/M100 */
 	{ USB_DEVICE(0x046d, 0xc05a), .driver_info = USB_QUIRK_RESET_RESUME },
drivers/usb/host/pci-quirks.c +12 -5
@@ -89,6 +89,7 @@ enum amd_chipset_gen {
 	AMD_CHIPSET_HUDSON2,
 	AMD_CHIPSET_BOLTON,
 	AMD_CHIPSET_YANGTZE,
+	AMD_CHIPSET_TAISHAN,
 	AMD_CHIPSET_UNKNOWN,
 };
 
@@ -132,6 +133,11 @@ static int amd_chipset_sb_type_init(stru
 			pinfo->sb_type.gen = AMD_CHIPSET_SB700;
 		else if (rev >= 0x40 && rev <= 0x4f)
 			pinfo->sb_type.gen = AMD_CHIPSET_SB800;
+	}
+	pinfo->smbus_dev = pci_get_device(PCI_VENDOR_ID_AMD,
+					  0x145c, NULL);
+	if (pinfo->smbus_dev) {
+		pinfo->sb_type.gen = AMD_CHIPSET_TAISHAN;
 	} else {
 		pinfo->smbus_dev = pci_get_device(PCI_VENDOR_ID_AMD,
 				PCI_DEVICE_ID_AMD_HUDSON2_SMBUS, NULL);
@@ -251,11 +257,12 @@ int usb_hcd_amd_remote_wakeup_quirk(stru
 {
 	/* Make sure amd chipset type has already been initialized */
 	usb_amd_find_chipset_info();
-	if (amd_chipset.sb_type.gen != AMD_CHIPSET_YANGTZE)
-		return 0;
-
-	dev_dbg(&pdev->dev, "QUIRK: Enable AMD remote wakeup fix\n");
-	return 1;
+	if (amd_chipset.sb_type.gen == AMD_CHIPSET_YANGTZE ||
+	    amd_chipset.sb_type.gen == AMD_CHIPSET_TAISHAN) {
+		dev_dbg(&pdev->dev, "QUIRK: Enable AMD remote wakeup fix\n");
+		return 1;
+	}
+	return 0;
 }
 EXPORT_SYMBOL_GPL(usb_hcd_amd_remote_wakeup_quirk);
 

Patches currently in stable-queue which might be from [email protected] are

queue-4.4/usb-xhci-add-quirk-for-certain-failing-hp-keyboard-on-reset-after-resume.patch