linux-stable.git/drivers/usb, branch v3.12.20

USB: pl2303: add ids for Hewlett-Packard HP POS pole displays

2014-05-15T07:55:45+00:00

commit b16c02fbfb963fa2941b7517ebf1f8a21946775e upstream.

Add device ids to pl2303 for the Hewlett-Packard HP POS pole displays:

LD960: 03f0:0B39
LCM220: 03f0:3139
LCM960: 03f0:3239

[ Johan: fix indentation and sort PIDs numerically ]

Signed-off-by: Aaron Sanders 
Signed-off-by: Johan Hovold 
Signed-off-by: Jiri Slaby

usb: xhci: Prefer endpoint context dequeue pointer over stopped_trb

2014-05-15T07:55:44+00:00

commit 1f81b6d22a5980955b01e08cf27fb745dc9b686f upstream.

We have observed a rare cycle state desync bug after Set TR Dequeue
Pointer commands on Intel LynxPoint xHCs (resulting in an endpoint that
doesn't fetch new TRBs and thus an unresponsive USB device). It always
triggers when a previous Set TR Dequeue Pointer command has set the
pointer to the final Link TRB of a segment, and then another URB gets
enqueued and cancelled again before it can be completed. Further
investigation showed that the xHC had returned the Link TRB in the TRB
Pointer field of the Transfer Event (CC == Stopped -- Length Invalid),
but when xhci_find_new_dequeue_state() later accesses the Endpoint
Context's TR Dequeue Pointer field it is set to the first TRB of the
next segment.

The driver expects those two values to be the same in this situation,
and uses the cycle state of the latter together with the address of the
former. This should be fine according to the XHCI specification, since
the endpoint ring should be stopped when returning the Transfer Event
and thus should not advance over the Link TRB before it gets restarted.
However, real-world XHCI implementations apparently don't really care
that much about these details, so the driver should follow a more
defensive approach to try to work around HC spec violations.

This patch removes the stopped_trb variable that had been used to store
the TRB Pointer from the last Transfer Event of a stopped TRB. Instead,
xhci_find_new_dequeue_state() now relies only on the Endpoint Context,
requiring a small amount of additional processing to find the virtual
address corresponding to the TR Dequeue Pointer. Some other parts of the
function were slightly rearranged to better fit into this model.

This patch should be backported to kernels as old as 2.6.31 that contain
the commit ae636747146ea97efa18e04576acd3416e2514f5 "USB: xhci: URB
cancellation support."

Signed-off-by: Julius Werner 
Signed-off-by: Mathias Nyman 
Signed-off-by: Jiri Slaby

USB: unbind all interfaces before rebinding any

2014-05-15T07:55:34+00:00

commit 6aec044cc2f5670cf3b143c151c8be846499bd15 upstream.

When a driver doesn't have pre_reset, post_reset, or reset_resume
methods, the USB core unbinds that driver when its device undergoes a
reset or a reset-resume, and then rebinds it afterward.

The existing straightforward implementation can lead to problems,
because each interface gets unbound and rebound before the next
interface is handled.  If a driver claims additional interfaces, the
claim may fail because the old binding instance may still own the
additional interface when the new instance tries to claim it.

This patch fixes the problem by first unbinding all the interfaces
that are marked (i.e., their needs_binding flag is set) and then
rebinding all of them.

The patch also makes the helper functions in driver.c a little more
uniform and adjusts some out-of-date comments.

Signed-off-by: Alan Stern 
Reported-and-tested-by: "Poulain, Loic" 
Signed-off-by: Jiri Slaby

usb: phy: Add ulpi IDs for SMSC USB3320 and TI TUSB1210

2014-05-15T07:55:33+00:00

commit ead5178bf442dbae4008ee54bf4f66a1f6a317c9 upstream.

Add new ulpi IDs which are available on Xilinx Zynq boards.

Signed-off-by: Michal Simek 
Signed-off-by: Jiri Slaby

usb: musb: avoid NULL pointer dereference

2014-05-15T07:55:32+00:00

commit eee3f15d5f1f4f0c283dd4db67dc1b874a2852d1 upstream.

instead of relying on the otg pointer, which
can be NULL in certain cases, we can use the
gadget and host pointers we already hold inside
struct musb.

Tested-by: Tony Lindgren 
Signed-off-by: Felipe Balbi 
Signed-off-by: Jiri Slaby

usb: dwc3: fix randconfig build errors

2014-05-15T07:55:32+00:00

commit 610183051d8f9421f138c4203ca894387f9f8839 upstream.

commit 388e5c5 (usb: dwc3: remove dwc3 dependency
on host AND gadget.) created the possibility for
host-only and peripheral-only dwc3 builds but
left a possible randconfig build error when host-only
builds are selected.

Reported-by: Jim Davis 
Signed-off-by: Felipe Balbi 
Signed-off-by: Jiri Slaby

usb: dwc3: fix wrong bit mask in dwc3_event_devt

2014-05-15T07:55:31+00:00

commit 06f9b6e59661cee510b04513b13ea7927727d758 upstream.

Around DWC USB3 2.30a release another bit has been added to the
Device-Specific Event (DEVT) Event Information (EvtInfo) bitfield.

Because of that, what used to be 8 bits long, has become 9 bits long.

Per dwc3 2.30a+ spec in the Device-Specific Event (DEVT), the field of
Event Information Bits(EvtInfo) uses [24:16] bits, and it has 9 bits
not 8 bits. And the following reserved field uses [31:25] bits not
[31:24] bits, and it has 7 bits.

So in dwc3_event_devt, the bit mask should be:
event_info	[24:16]		9 bits
reserved31_25	[31:25]		7 bits

This patch makes sure that newer core releases will work fine with
Linux and that we will decode the event information properly on new
core releases.

[ balbi@ti.com : improve commit log a bit ]

Signed-off-by: Huang Rui 
Signed-off-by: Felipe Balbi 
Signed-off-by: Jiri Slaby

usb/xhci: fix compilation warning when !CONFIG_PCI && !CONFIG_PM

2014-05-15T07:55:24+00:00

commit 01bb59ebffdec314da8da66266edf29529372f9b upstream.

When CONFIG_PCI and CONFIG_PM are not selected, xhci.c gets this
warning:
drivers/usb/host/xhci.c:409:13: warning: ‘xhci_msix_sync_irqs’ defined
but not used [-Wunused-function]

Instead of creating nested #ifdefs, this patch fixes it by defining the
xHCI PCI stubs as inline.

This warning has been in since 3.2 kernel and was
caused by commit 421aa841a134f6a743111cf44d0c6d3b45e3cf8c
"usb/xhci: hide MSI code behind PCI bars", but wasn't noticed
until 3.13 when a configuration with these options was tried

Signed-off-by: David Cohen 
Signed-off-by: Mathias Nyman 
Signed-off-by: Jiri Slaby

xhci: Switch Intel Lynx Point ports to EHCI on shutdown.

2014-05-15T07:55:23+00:00

commit c09ec25d3684cad74d851c0f028a495999591279 upstream.

The same issue like with Panther Point chipsets. If the USB ports are
switched to xHCI on shutdown, the xHCI host will send a spurious interrupt,
which will wake the system. Some BIOS have work around for this, but not all.
One example is Compulab's mini-desktop, the Intense-PC2.

The bug can be avoided if the USB ports are switched back to EHCI on
shutdown.

This patch should be backported to stable kernels as old as 3.12,
that contain the commit 638298dc66ea36623dbc2757a24fc2c4ab41b016
"xhci: Fix spurious wakeups after S5 on Haswell"

Signed-off-by: Denis Turischev 
Signed-off-by: Mathias Nyman 
Signed-off-by: Jiri Slaby

xhci: Prevent runtime pm from autosuspending during initialization

2014-05-15T07:55:23+00:00

commit bcffae7708eb8352f44dc510b326541fe43a02a4 upstream.

xHCI driver has its own pci probe function that will call usb_hcd_pci_probe
to register its usb-2 bus, and then continue to manually register the
usb-3 bus. usb_hcd_pci_probe does a pm_runtime_put_noidle at the end and
might thus trigger a runtime suspend before the usb-3 bus is ready.

Prevent the runtime suspend by increasing the usage count in the
beginning of xhci_pci_probe, and decrease it once the usb-3 bus is
ready.

xhci-platform driver is not using usb_hcd_pci_probe to set up
busses and should not need to have it's usage count increased during probe.

Signed-off-by: Mathias Nyman 
Acked-by: Dan Williams 
Acked-by: Alan Stern 
Signed-off-by: Sarah Sharp 
Signed-off-by: Jiri Slaby