linux.git/drivers/usb/host, branch v3.12-rc5

USB: fsl/ehci: fix failure of checking PHY_CLK_VALID during reinitialization

2013-09-26T23:22:29+00:00

In case of usb phy reinitialization:
e.g. insmod usb-module(usb works well) -> rmmod usb-module -> insmod usb-module
It found the PHY_CLK_VALID bit didn't work if it's not with the power-on reset.
So we just check PHY_CLK_VALID bit during the stage with POR, this can be met
by the tricky of checking FSL_SOC_USB_PRICTRL register.

Signed-off-by: Shengzhou Liu 
Signed-off-by: Greg Kroah-Hartman

fsl/usb: Resolve PHY_CLK_VLD instability issue for ULPI phy

2013-09-26T18:59:57+00:00

For controller versions greater than 1.6, setting ULPI_PHY_CLK_SEL
bit when USB_EN bit is already set causes instability issues with
PHY_CLK_VLD bit. So USB_EN is set only for IP controller version
below 1.6 before setting ULPI_PHY_CLK_SEL bit

Signed-off-by: Ramneek Mehresh 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

USB: fix PM config symbol in uhci-hcd, ehci-hcd, and xhci-hcd

2013-09-26T00:05:35+00:00

Since uhci-hcd, ehci-hcd, and xhci-hcd support runtime PM, the .pm
field in their pci_driver structures should be protected by CONFIG_PM
rather than CONFIG_PM_SLEEP.  The corresponding change has already
been made for ohci-hcd.

Without this change, controllers won't do runtime suspend if system
suspend or hibernation isn't enabled.

Signed-off-by: Alan Stern 
CC: Sarah Sharp 
CC: 
Signed-off-by: Greg Kroah-Hartman

USB: OHCI: accept very late isochronous URBs

2013-09-26T00:05:35+00:00

Commit 24f531371de1 (USB: EHCI: accept very late isochronous URBs)
changed the isochronous API provided by ehci-hcd.  URBs submitted too
late, so that the time slots for all their packets have already
expired, are no longer rejected outright.  Instead the submission is
accepted, and the URB completes normally with a -EXDEV error for each
packet.  This is what client drivers expect.

This patch implements the same policy in ohci-hcd.  The change is more
complicated than it was in ehci-hcd, because ohci-hcd doesn't scan for
isochronous completions in the same way as ehci-hcd does.  Rather, it
depends on the hardware adding completed TDs to a "done queue".  Some
OHCI controller don't handle this properly when a TD's time slot has
already expired, so we have to avoid adding such TDs to the schedule
in the first place.  As a result, if the URB was submitted too late
then none of its TDs will get put on the schedule, so none of them
will end up on the done queue, so the driver will never realize that
the URB should be completed.

To solve this problem, the patch adds one to urb_priv->td_cnt for such
URBs, making it larger than urb_priv->length (td_cnt already gets set
to the number of TD's that had to be skipped because their slots have
expired).  Each time an URB is given back, the finish_urb() routine
looks to see if urb_priv->td_cnt for the next URB on the same endpoint
is marked in this way.  If so, it gives back the next URB right away.

This should be applied to all kernels containing commit 815fa7b91761
(USB: OHCI: fix logic for scheduling isochronous URBs).

Signed-off-by: Alan Stern 
CC: 
Signed-off-by: Greg Kroah-Hartman

USB: UHCI: accept very late isochronous URBs

2013-09-26T00:05:34+00:00

Commit 24f531371de1 (USB: EHCI: accept very late isochronous URBs)
changed the isochronous API provided by ehci-hcd.  URBs submitted too
late, so that the time slots for all their packets have already
expired, are no longer rejected outright.  Instead the submission is
accepted, and the URB completes normally with a -EXDEV error for each
packet.  This is what client drivers expect.

This patch implements the same policy in uhci-hcd.  It should be
applied to all kernels containing commit c44b225077bb (UHCI: implement
new semantics for URB_ISO_ASAP).

Signed-off-by: Alan Stern 
CC: 
Signed-off-by: Greg Kroah-Hartman

USB: iMX21: accept very late isochronous URBs

2013-09-26T00:05:34+00:00

Commit 24f531371de1 (USB: EHCI: accept very late isochronous URBs)
changed the isochronous API provided by ehci-hcd.  URBs submitted too
late, so that the time slots for all their packets have already
expired, are no longer rejected outright.  Instead the submission is
accepted, and the URB completes normally with a -EXDEV error for each
packet.  This is what client drivers expect.

The same policy should be implemented in imx21-hcd, but I don't know
enough about the hardware to do it.  As a second-best substitute, this
patch treats very late isochronous submissions as though the
URB_ISO_ASAP flag were set.  I don't have any way to test this change,
unfortunately.

Signed-off-by: Alan Stern 
CC: Sascha Hauer 
CC: Martin Fuzzey 
Signed-off-by: Greg Kroah-Hartman

xhci: Fix race between ep halt and URB cancellation

2013-09-23T22:43:31+00:00

The halted state of a endpoint cannot be cleared over CLEAR_HALT from a
user process, because the stopped_td variable was overwritten in the
handle_stopped_endpoint() function. So the xhci_endpoint_reset() function will
refuse the reset and communication with device can not run over this endpoint.
https://bugzilla.kernel.org/show_bug.cgi?id=60699

Signed-off-by: Florian Wolter 
Signed-off-by: Sarah Sharp

usb: Fix xHCI host issues on remote wakeup.

2013-09-23T22:43:31+00:00

When a device signals remote wakeup on a roothub, and the suspend change
bit is set, the host controller driver must not give control back to the
USB core until the port goes back into the active state.

EHCI accomplishes this by waiting in the get port status function until
the PORT_RESUME bit is cleared:

                        /* stop resume signaling */
                        temp &= ~(PORT_RWC_BITS | PORT_SUSPEND | PORT_RESUME);
                        ehci_writel(ehci, temp, status_reg);
                        clear_bit(wIndex, &ehci->resuming_ports);
                        retval = ehci_handshake(ehci, status_reg,
                                        PORT_RESUME, 0, 2000 /* 2msec */);

Similarly, the xHCI host should wait until the port goes into U0, before
passing control up to the USB core.  When the port transitions from the
RExit state to U0, the xHCI driver will get a port status change event.
We need to wait for that event before passing control up to the USB
core.

After the port transitions to the active state, the USB core should time
a recovery interval before it talks to the device.  The length of that
recovery interval is TRSMRCY, 10 ms, mentioned in the USB 2.0 spec,
section 7.1.7.7.  The previous xHCI code (which did not wait for the
port to go into U0) would cause the USB core to violate that recovery
interval.

This bug caused numerous USB device disconnects on remote wakeup under
ChromeOS and a Lynx Point LP xHCI host that takes up to 20 ms to move
from RExit to U0.  ChromeOS is very aggressive about power savings, and
sets the autosuspend_delay to 100 ms, and disables USB persist.

I attempted to replicate this bug with Ubuntu 12.04, but could not.  I
used Ubuntu 12.04 on the same platform, with the same BIOS that the bug
was triggered on ChromeOS with.  I also changed the USB sysfs settings
as described above, but still could not reproduce the bug under Ubuntu.
It may be that ChromeOS userspace triggers this bug through additional
settings.

Signed-off-by: Sarah Sharp

xhci: Ensure a command structure points to the correct trb on the command ring

2013-09-23T22:43:30+00:00

If a command on the command ring needs to be cancelled before it is handled
it can be turned to a no-op operation when the ring is stopped.
We want to store the command ring enqueue pointer in the command structure
when the command in enqueued for the cancellation case.

Some commands used to store the command ring dequeue pointers instead of enqueue
(these often worked because enqueue happends to equal dequeue quite often)

Other commands correctly used the enqueue pointer but did not check if it pointed
to a valid trb or a link trb, this caused for example stop endpoint command to timeout in
xhci_stop_device() in about 2% of suspend/resume cases.

This should also solve some weird behavior happening in command cancellation cases.

This patch is based on a patch submitted by Sarah Sharp to linux-usb, but
then forgotten:
    http://marc.info/?l=linux-usb&m=136269803207465&w=2

This patch should be backported to kernels as old as 3.7, that contain
the commit b92cc66c047ff7cf587b318fe377061a353c120f "xHCI: add aborting
command ring function"

Signed-off-by: Mathias Nyman 
Signed-off-by: Sarah Sharp 
Cc: stable@vger.kernel.org

xhci: Fix oops happening after address device timeout

2013-09-23T22:43:30+00:00

When a command times out, the command ring is first aborted,
and then stopped. If the command ring is empty when it is stopped
the stop event will point to next command which is not yet set.
xHCI tries to handle this next event often causing an oops.

Don't handle command completion events on stopped cmd ring if ring is
empty.

This patch should be backported to kernels as old as 3.7, that contain
the commit b92cc66c047ff7cf587b318fe377061a353c120f "xHCI: add aborting
command ring function"

Signed-off-by: Mathias Nyman 
Reported-by: Giovanni 
Signed-off-by: Sarah Sharp 
Cc: stable@vger.kernel.org