linux/drivers/usb/core, branch v3.10.25

usb: hub: Use correct reset for wedged USB3 devices that are NOTATTACHED

2013-12-20T15:45:08Z

commit 2d51f3cd11f414c56a87dc018196b85fd50b04a4 upstream. This patch adds a check for USB_STATE_NOTATTACHED to the hub_port_warm_reset_required() workaround for ports that end up in Compliance Mode in hub_events() when trying to decide which reset function to use. Trying to call usb_reset_device() with a NOTATTACHED device will just fail and leave the port broken. Signed-off-by: Julius Werner Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

usb: hub: Clear Port Reset Change during init/resume

2013-11-29T19:11:52Z

commit e92aee330837e4911553761490a8fb843f2053a6 upstream. This patch adds the Port Reset Change flag to the set of bits that are preemptively cleared on init/resume of a hub. In theory this bit should never be set unexpectedly... in practice it can still happen if BIOS, SMM or ACPI code plays around with USB devices without cleaning up correctly. This is especially dangerous for XHCI root hubs, which don't generate any more Port Status Change Events until all change bits are cleared, so this is a good precaution to have (similar to how it's already done for the Warm Port Reset Change flag). Signed-off-by: Julius Werner Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

usbcore: set lpm_capable field for LPM capable root hubs

2013-11-20T20:27:48Z

commit 9df89d85b407690afa46ddfbccc80bec6869971d upstream. This patch sets the lpm_capable field for root hubs with LPM capabilities. Signed-off-by: Xenia Ragiadakou Reported-by: Martin MOKREJS Suggested-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

usb: fail on usb_hub_create_port_device() errors

2013-11-20T20:27:47Z

commit e58547eb9561a8a72d46e2d411090a614d33ac0e upstream. Ignoring usb_hub_create_port_device() errors cause later NULL pointer deference when uninitialized hub->ports[i] entries are dereferenced after port memory allocation error. Signed-off-by: Krzysztof Mazur Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

usb: fix cleanup after failure in hub_configure()

2013-11-20T20:27:47Z

commit d0308d4b6b02597f39fc31a9bddf7bb3faad5622 upstream. If the hub_configure() fails after setting the hdev->maxchild the hub->ports might be NULL or point to uninitialized kzallocated memory causing NULL pointer dereference in hub_quiesce() during cleanup. Now after such error the hdev->maxchild is set to 0 to avoid cleanup of uninitialized ports. Signed-off-by: Krzysztof Mazur Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

USB: quirks: add touchscreen that is dazzeled by remote wakeup

2013-11-13T03:05:30Z

commit 614ced91fc6fbb5a1cdd12f0f1b6c9197d9f1350 upstream. The device descriptors are messed up after remote wakeup Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman

USB: quirks.c: add one device that cannot deal with suspension

2013-11-13T03:05:30Z

commit 4294bca7b423d1a5aa24307e3d112a04075e3763 upstream. The device is not responsive when resumed, unless it is reset. Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman

usb/core/devio.c: Don't reject control message to endpoint with wrong direction bit

2013-10-05T14:13:11Z

commit 831abf76643555a99b80a3b54adfa7e4fa0a3259 upstream. Trying to read data from the Pegasus Technologies NoteTaker (0e20:0101) [1] with the Windows App (EasyNote) works natively but fails when Windows is running under KVM (and the USB device handed to KVM). The reason is a USB control message usb 4-2.2: control urb: bRequestType=22 bRequest=09 wValue=0200 wIndex=0001 wLength=0008 This goes to endpoint address 0x01 (wIndex); however, endpoint address 0x01 does not exist. There is an endpoint 0x81 though (same number, but other direction); the app may have meant that endpoint instead. The kernel thus rejects the IO and thus we see the failure. Apparently, Linux is more strict here than Windows ... we can't change the Win app easily, so that's a problem. It seems that the Win app/driver is buggy here and the driver does not behave fully according to the USB HID class spec that it claims to belong to. The device seems to happily deal with that though (and seems to not really care about this value much). So the question is whether the Linux kernel should filter here. Rejecting has the risk that somewhat non-compliant userspace apps/ drivers (most likely in a virtual machine) are prevented from working. Not rejecting has the risk of confusing an overly sensitive device with such a transfer. Given the fact that Windows does not filter it makes this risk rather small though. The patch makes the kernel more tolerant: If the endpoint address in wIndex does not exist, but an endpoint with toggled direction bit does, it will let the transfer through. (It does NOT change the message.) With attached patch, the app in Windows in KVM works. usb 4-2.2: check_ctrlrecip: process 13073 (qemu-kvm) requesting ep 01 but needs 81 I suspect this will mostly affect apps in virtual environments; as on Linux the apps would have been adapted to the stricter handling of the kernel. I have done that for mine[2]. [1] http://www.pegatech.com/ [2] https://sourceforge.net/projects/notetakerpen/ Signed-off-by: Kurt Garloff Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

usb: don't check pm qos NO_POWER_OFF flag in usb_port_suspend()

2013-09-27T00:18:13Z

commit 98a4f1ff7bea8002ab79d6776e30d27932e88244 upstream. The pm qos NO_POWER_OFF flag is checked twice during usb device suspend to see if the usb port power off condition is met. This is redundant and also will prevent the port from being powered off if the NO_POWER_OFF flag is changed to 1 from 0 after the device was already suspended. More detail in the following link. http://marc.info/?l=linux-usb&m=136543949130865&w=2 This patch should be backported to kernels as old as 3.7, that contain the commit f7ac7787ad361e31a7972e2854ed8dc2eedfac3b "usb/acpi: Use ACPI methods to power off ports." Signed-off-by: Lan Tianyu Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman

USB: handle LPM errors during device suspend correctly

2013-09-27T00:18:13Z

commit aa5ceae24bf8dff1d6fe87c6c4b08e69c6d33550 upstream. The hub driver's usb_port_suspend() routine doesn't handle errors related to Link Power Management properly. It always returns failure, it doesn't try to clean up the wakeup setting, (in the case of system sleep) it doesn't try to go ahead with the port suspend regardless, and it doesn't try to apply the new power-off mechanism. This patch fixes these problems. Note: Sarah fixed this patch to apply against 3.11, since the original commit (4fae6f0fa86f92e6bc7429371b1e177ad0aaac66 "USB: handle LPM errors during device suspend correctly") called usb_disable_remote_wakeup, which won't be added until 3.12. This patch should be backported to kernels as old as 3.5, that contain the commit 8306095fd2c1100e8244c09bf560f97aca5a311d "USB: Disable USB 3.0 LPM in critical sections.". There will be merge conflicts, since LTM wasn't added until 3.6. Signed-off-by: Alan Stern Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman