linux-toradex.git/drivers/usb, branch v3.18.13

usb: serial: silence all non-critical read errors

2015-04-27T21:13:47+00:00

[ Upstream commit aa8e22128b40590b291cd13512098bf258a7e6c5 ]

If a USB serial device is unplugged while there is an active program
using the device it may spam the logs with -EPROTO (71) messages as it
attempts to retry.

Most serial usb drivers (metro-usb, pl2303, mos7840, ...) only output
these messages for debugging.  The generic driver treats these as
errors.

Change the default output for the generic serial driver from error to
debug to silence these non-critical errors.

Signed-off-by: Jeremiah Mahler 
Signed-off-by: Johan Hovold 
Signed-off-by: Sasha Levin

usb: xhci: apply XHCI_AVOID_BEI quirk to all Intel xHCI controllers

2015-04-24T21:13:58+00:00

[ Upstream commit 227a4fd801c8a9fa2c4700ab98ec1aec06e3b44d ]

When a device with an isochronous endpoint is plugged into the Intel
xHCI host controller, and the driver submits multiple frames per URB,
the xHCI driver will set the Block Event Interrupt (BEI) flag on all
but the last TD for the URB. This causes the host controller to place
an event on the event ring, but not send an interrupt. When the last
TD for the URB completes, BEI is cleared, and we get an interrupt for
the whole URB.

However, under Intel xHCI host controllers, if the event ring is full
of events from transfers with BEI set,  an "Event Ring is Full" event
will be posted to the last entry of the event ring,  but no interrupt
is generated. Host will cease all transfer and command executions and
wait until software completes handling the pending events in the event
ring.  That means xHC stops, but event of "event ring is full" is not
notified. As the result, the xHC looks like dead to user.

This patch is to apply XHCI_AVOID_BEI quirk to Intel xHC devices. And
it should be backported to kernels as old as 3.0, that contains the
commit 69e848c2090a ("Intel xhci: Support EHCI/xHCI port switching.").

Signed-off-by: Lu Baolu 
Tested-by: Alistair Grant 
Cc: stable@vger.kernel.org
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: xhci: handle Config Error Change (CEC) in xhci driver

2015-04-24T21:13:58+00:00

[ Upstream commit 9425183d177aa4a2f09d01a74925124f0778b595 ]

Linux xHCI driver doesn't report and handle port cofig error change.
If Port Configure Error for root hub port occurs, CEC bit in PORTSC
would be set by xHC and remains 1. This happends when the root port
fails to configure its link partner, e.g. the port fails to exchange
port capabilities information using Port Capability LMPs.

Then the Port Status Change Events will be blocked until all status
change bits(CEC is one of the change bits) are cleared('0') (refer to
xHCI spec 4.19.2). Otherwise, the port status change event for this
root port will not be generated anymore, then root port would look
like dead for user and can't be recovered until a Host Controller
Reset(HCRST).

This patch is to check CEC bit in PORTSC in xhci_get_port_status()
and set a Config Error in the return status if CEC is set. This will
cause a ClearPortFeature request, where CEC bit is cleared in
xhci_clear_port_change_bit().

[The commit log is based on initial Marvell patch posted at
http://marc.info/?l=linux-kernel&m=142323612321434&w=2]

Reported-by: Gregory CLEMENT 
Signed-off-by: Lu Baolu 
Cc: stable  # v3.2+
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

USB: ftdi_sio: Use jtag quirk for SNAP Connect E10

2015-04-24T21:13:48+00:00

[ Upstream commit b229a0f840f774d29d8fedbf5deb344ca36b7f1a ]

This patch uses the existing CALAO Systems ftdi_8u2232c_probe in order
to avoid attaching a TTY to the JTAG port as this board is based on the
CALAO Systems reference design and needs the same fix up.

Signed-off-by: Doug Goldstein 
CC: stable 
[johan: clean up probe logic ]
Signed-off-by: Johan Hovold 

Signed-off-by: Sasha Levin

USB: ftdi_sio: Added custom PID for Synapse Wireless product

2015-04-24T21:13:48+00:00

[ Upstream commit 4899c054a90439477b24da8977db8d738376fe90 ]

Synapse Wireless uses the FTDI VID with a custom PID of 0x9090 for their
SNAP Stick 200 product.

Signed-off-by: Doug Goldstein 
Cc: stable 
Signed-off-by: Johan Hovold 
Signed-off-by: Sasha Levin

USB: keyspan_pda: add new device id

2015-04-24T21:13:47+00:00

[ Upstream commit 5e71fc8629cefae5f3c1a4f498de3fe4f631924a ]

Add USB VID/PID for Xircom PGMFHUB USB/serial component.  (The hub and SCSI
bridge on that hardware are recognized out of the box by existing drivers.)
Tested VID/PID using new_id and loopback connection and was met with
success, but that's all the testing done.

Signed-off-by: Nathaniel Wesley Filardo 
Cc: stable 
Signed-off-by: Johan Hovold 
Signed-off-by: Sasha Levin

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

2015-04-17T00:11:40+00:00

[ Upstream commit a886bd92267c9e3d5c912860c6fb5a68479a7643 ]

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.
Cc:  # v3.16+
Signed-off-by: Peter Chen 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

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

2015-04-17T00:11:40+00:00

[ Upstream commit d20f7807996c69537e07443ef8dec4e01a28b099 ]

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

Cc: stable 
Acked-by: Peter Chen 
Signed-off-by: Li Jun 
Signed-off-by: Peter Chen 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

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

2015-04-17T00:11:39+00:00

[ Upstream commit d0f347d62814ec0f599a05c61c5619d5e999e4ae ]

This fixes a potential null pointer dereference.

Cc:  # v3.16+
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: Sasha Levin

uas: Add US_FL_NO_ATA_1X for Initio Corporation controllers / devices

2015-04-17T00:11:38+00:00

[ Upstream commit bda13e35d584dabf52c9f77e0fe62683ac4d9f86 ]

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 
Cc: stable@vger.kernel.org # 3.16
Signed-off-by: Hans de Goede 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin