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

usb: common: otg-fsm: only signal connect after switching to peripheral

2015-04-13T12:03:53+00:00

commit a886bd92267c9e3d5c912860c6fb5a68479a7643 upstream.

We should signal connect (pull up dp) after we have already
at peripheral mode, otherwise, the dp may be toggled due to
we reset controller or do disconnect during the initialization
for peripheral, then, the host may be confused during the
enumeration, eg, it finds the reset can't succeed, but the
device is still there, see below error message.

hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: Cannot enable port 1.  Maybe the USB cable is bad?
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: Cannot enable port 1.  Maybe the USB cable is bad?
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: Cannot enable port 1.  Maybe the USB cable is bad?
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: Cannot enable port 1.  Maybe the USB cable is bad?
hub 1-0:1.0: unable to enumerate USB device on port 1

Fixes: the issue existed when the otg fsm code was added.
Signed-off-by: Peter Chen 
Signed-off-by: Greg Kroah-Hartman

usb: chipidea: otg: add a_alt_hnp_support response for B device

2015-04-13T12:03:53+00:00

commit d20f7807996c69537e07443ef8dec4e01a28b099 upstream.

This patch adds response to a_alt_hnp_support set feature request from legacy
A device, that is, B-device can provide a message to the user indicating that
the user needs to connect the B-device to an alternate port on the A-device.
A device sets this feature indicates to the B-device that it is connected
to an A-device port that is not capable of HNP, but that the A-device does have
an alternate port that is capable of HNP.

[Peter]
Without this patch, the OTG B device can't be enumerated on
non-HNP port at A device, see below log:
[    2.287464] usb 1-1: Dual-Role OTG device on non-HNP port
[    2.293105] usb 1-1: can't set HNP mode: -32
[    2.417422] usb 1-1: new high-speed USB device number 4 using ci_hdrc
[    2.460635] usb 1-1: Dual-Role OTG device on non-HNP port
[    2.466424] usb 1-1: can't set HNP mode: -32
[    2.587464] usb 1-1: new high-speed USB device number 5 using ci_hdrc
[    2.630649] usb 1-1: Dual-Role OTG device on non-HNP port
[    2.636436] usb 1-1: can't set HNP mode: -32
[    2.641003] usb usb1-port1: unable to enumerate USB device

Acked-by: Peter Chen 
Signed-off-by: Li Jun 
Signed-off-by: Peter Chen 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

usb: phy: am335x-control: check return value of bus_find_device

2015-04-13T12:03:53+00:00

commit d0f347d62814ec0f599a05c61c5619d5e999e4ae upstream.

This fixes a potential null pointer dereference.

Fixes: d4332013919a ("driver core: dev_get_drvdata: Don't check for NULL dev")
Acked-by: Sebastian Andrzej Siewior 
Signed-off-by: David Dueck 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

uas: Add US_FL_NO_ATA_1X for Initio Corporation controllers / devices

2015-04-13T12:03:53+00:00

commit bda13e35d584dabf52c9f77e0fe62683ac4d9f86 upstream.

A new uas compatible controller has shown up in some people's devices from
the manufacturer Initio Corporation, this controller needs the US_FL_NO_ATA_1X
quirk to work properly with uas, so add it to the uas quirks table.

Reported-and-tested-by: Benjamin Tissoires 
Cc: Benjamin Tissoires 
Signed-off-by: Hans de Goede 
Signed-off-by: Greg Kroah-Hartman

gadgetfs: use-after-free in ->aio_read()

2015-03-26T12:59:47+00:00

commit f01d35a15fa04162a58b95970fc01fa70ec9dacd upstream.

AIO_PREAD requests call ->aio_read() with iovec on caller's stack, so if
we are going to access it asynchronously, we'd better get ourselves
a copy - the one on kernel stack of aio_run_iocb() won't be there
anymore.  function/f_fs.c take care of doing that, legacy/inode.c
doesn't...

Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman

USB: serial: fix tty-device error handling at probe

2015-03-18T13:11:03+00:00

commit ca4383a3947a83286bc9b9c598a1f55e867871d7 upstream.

Add missing error handling when registering the tty device at port
probe. This avoids trying to remove an uninitialised character device
when the port device is removed.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: Takashi Iwai 
Signed-off-by: Johan Hovold 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

USB: serial: fix potential use-after-free after failed probe

2015-03-18T13:11:03+00:00

commit 07fdfc5e9f1c966be8722e8fa927e5ea140df5ce upstream.

Fix return value in probe error path, which could end up returning
success (0) on errors. This could in turn lead to use-after-free or
double free (e.g. in port_remove) when the port device is removed.

Fixes: c706ebdfc895 ("USB: usb-serial: call port_probe and port_remove
at the right times")
Signed-off-by: Johan Hovold 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

USB: serial: fix infinite wait_until_sent timeout

2015-03-18T13:11:02+00:00

commit f528bf4f57e43d1af4b2a5c97f09e43e0338c105 upstream.

Make sure to handle an infinite timeout (0).

Note that wait_until_sent is currently never called with a 0-timeout
argument due to a bug in tty_wait_until_sent.

Fixes: dcf010503966 ("USB: serial: add generic wait_until_sent
implementation")
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

xhci: Workaround for PME stuck issues in Intel xhci

2015-03-18T13:11:02+00:00

commit b8cb91e058cd0c0f02059c1207293c5b31d350fa upstream.

The xhci in Intel Sunrisepoint and Cherryview platforms need a driver
workaround for a Stuck PME that might either block PME events in suspend,
or create spurious PME events preventing runtime suspend.

Workaround is to clear a internal PME flag, BIT(28) in a vendor specific
PMCTRL register at offset 0x80a4, in both suspend resume callbacks

Without this, xhci connected usb devices might never be able to wake up the
system from suspend, or prevent device from going to suspend (xhci d3)

Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

xhci: fix reporting of 0-sized URBs in control endpoint

2015-03-18T13:11:02+00:00

commit 45ba2154d12fc43b70312198ec47085f10be801a upstream.

When a control transfer has a short data stage, the xHCI controller generates
two transfer events: a COMP_SHORT_TX event that specifies the untransferred
amount, and a COMP_SUCCESS event. But when the data stage is not short, only the
COMP_SUCCESS event occurs. Therefore, xhci-hcd must set urb->actual_length to
urb->transfer_buffer_length while processing the COMP_SUCCESS event, unless
urb->actual_length was set already by a previous COMP_SHORT_TX event.

The driver checks this by seeing whether urb->actual_length == 0, but this alone
is the wrong test, as it is entirely possible for a short transfer to have an
urb->actual_length = 0.

This patch changes the xhci driver to rely on a new td->urb_length_set flag,
which is set to true when a COMP_SHORT_TX event is received and the URB length
updated at that stage.

This fixes a bug which affected the HSO plugin, which relies on URBs with
urb->actual_length == 0 to halt re-submitting the RX URB in the control
endpoint.

Signed-off-by: Aleksander Morgado 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman