linux-stable.git/drivers/usb/core, branch v3.10.30

usb: core: get config and string descriptors for unauthorized devices

2014-02-06T19:08:17+00:00

commit 83e83ecb79a8225e79bc8e54e9aff3e0e27658a2 upstream.

There is no need to skip querying the config and string descriptors for
unauthorized WUSB devices when usb_new_device is called.  It is allowed
by WUSB spec.  The only action that needs to be delayed until
authorization time is the set config.  This change allows user mode
tools to see the config and string descriptors earlier in enumeration
which is needed for some WUSB devices to function properly on Android
systems.  It also reduces the amount of divergent code paths needed
for WUSB devices.

Signed-off-by: Thomas Pugliese 
Signed-off-by: Greg Kroah-Hartman

USB: fix race between hub_disconnect and recursively_mark_NOTATTACHED

2014-02-06T19:08:13+00:00

commit 543d7784b07ffd16cc82a9cb4e1e0323fd0040f1 upstream.

There is a race in the hub driver between hub_disconnect() and
recursively_mark_NOTATTACHED().  This race can be triggered if the
driver is unbound from a device at the same time as the bus's root hub
is removed.  When the race occurs, it can cause an oops:

BUG: unable to handle kernel NULL pointer dereference at 0000015c
IP: [] recursively_mark_NOTATTACHED+0x20/0x60
Call Trace:
 [] recursively_mark_NOTATTACHED+0x34/0x60
 [] recursively_mark_NOTATTACHED+0x34/0x60
 [] recursively_mark_NOTATTACHED+0x34/0x60
 [] recursively_mark_NOTATTACHED+0x34/0x60
 [] usb_set_device_state+0x92/0x120
 [] usb_disconnect+0x2b/0x1a0
 [] usb_remove_hcd+0xb0/0x160
 [] ? _raw_spin_unlock_irqrestore+0x26/0x50
 [] ehci_mid_remove+0x1c/0x30
 [] ehci_mid_stop_host+0x16/0x30
 [] penwell_otg_work+0xd28/0x3520
 [] ? __schedule+0x39b/0x7f0
 [] ? sub_preempt_count+0x3d/0x50
 [] process_one_work+0x11d/0x3d0
 [] ? mutex_unlock+0xd/0x10
 [] ? manage_workers.isra.24+0x1b5/0x270
 [] worker_thread+0xf9/0x320
 [] ? _raw_spin_unlock_irqrestore+0x26/0x50
 [] ? rescuer_thread+0x2b0/0x2b0
 [] kthread+0x94/0xa0
 [] ret_from_kernel_thread+0x1b/0x28
 [] ? kthread_create_on_node+0xc0/0xc0

One problem is that recursively_mark_NOTATTACHED() uses the intfdata
value and hub->hdev->maxchild while hub_disconnect() is clearing them.
Another problem is that it uses hub->ports[i] while the port device is
being released.

To fix this race, we need to hold the device_state_lock while
hub_disconnect() changes the values.  (Note that usb_disconnect()
and hub_port_connect_change() already acquire this lock at similar
critical times during a USB device's life cycle.)  We also need to
remove the port devices after maxchild has been set to 0, instead of
before.

Signed-off-by: Alan Stern 
Reported-by: "Du, Changbin" 
Tested-by: "Du, Changbin" 
Signed-off-by: Greg Kroah-Hartman

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

2013-12-20T15:45:08+00:00

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:52+00:00

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:48+00:00

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:47+00:00

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:47+00:00

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:30+00:00

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:30+00:00

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:11+00:00

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