linux-stable.git/drivers/usb/host, branch v3.12.22 Linux kernel stable tree USB: OHCI: fix problem with global suspend on ATI controllers 2014-06-06T10:38:20+00:00 Alan Stern stern@rowland.harvard.edu 2014-05-01T19:21:42+00:00 ccc5443b40dfe652e86edd421e2164179b5da959 commit c1db30a2a79eb59997b13b8cabf2a50bea9f04e1 upstream. Some OHCI controllers from ATI/AMD seem to have difficulty with "global" USB suspend, that is, suspending an entire USB bus without setting the suspend feature for each port connected to a device. When we try to resume the child devices, the controller gives timeout errors on the unsuspended ports, requiring resets, and can even cause ohci-hcd to hang; see http://marc.info/?l=linux-usb&m=139514332820398&w=2 and the following messages. This patch fixes the problem by adding a new quirk flag to ohci-hcd. The flag causes the ohci_rh_suspend() routine to suspend each unsuspended, enabled port before suspending the root hub. This effectively converts the "global" suspend to an ordinary root-hub suspend. There is no need to unsuspend these ports when the root hub is resumed, because the child devices will be resumed anyway in the course of a normal system resume ("global" suspend is never used for runtime PM). This patch should be applied to all stable kernels which include commit 0aa2832dd0d9 (USB: use "global suspend" for system sleep on USB-2 buses) or a backported version thereof. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Peter Münster <pmlists@free.fr> Tested-by: Peter Münster <pmlists@free.fr> Signed-off-by: Jiri Slaby <jslaby@suse.cz> 
commit c1db30a2a79eb59997b13b8cabf2a50bea9f04e1 upstream.

Some OHCI controllers from ATI/AMD seem to have difficulty with
"global" USB suspend, that is, suspending an entire USB bus without
setting the suspend feature for each port connected to a device.  When
we try to resume the child devices, the controller gives timeout
errors on the unsuspended ports, requiring resets, and can even cause
ohci-hcd to hang; see

	http://marc.info/?l=linux-usb&m=139514332820398&w=2

and the following messages.

This patch fixes the problem by adding a new quirk flag to ohci-hcd.
The flag causes the ohci_rh_suspend() routine to suspend each
unsuspended, enabled port before suspending the root hub.  This
effectively converts the "global" suspend to an ordinary root-hub
suspend.  There is no need to unsuspend these ports when the root hub
is resumed, because the child devices will be resumed anyway in the
course of a normal system resume ("global" suspend is never used for
runtime PM).

This patch should be applied to all stable kernels which include
commit 0aa2832dd0d9 (USB: use "global suspend" for system sleep on
USB-2 buses) or a backported version thereof.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Peter Münster <pmlists@free.fr>
Tested-by: Peter Münster <pmlists@free.fr>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
fsl-usb: do not test for PHY_CLK_VALID bit on controller version 1.6 2014-06-06T10:38:19+00:00 Nikita Yushchenko nyushchenko@dev.rtsoft.ru 2014-04-28T15:23:44+00:00 9c7d0b459c3d169fd4fbe2f831444c1669cef8c2 commit d183c81929beeba842b74422f754446ef2b8b49c upstream. Per reference manuals of Freescale P1020 and P2020 SoCs, USB controller present in these SoCs has bit 17 of USBx_CONTROL register marked as Reserved - there is no PHY_CLK_VALID bit there. Testing for this bit in ehci_fsl_setup_phy() behaves differently on two P1020RDB boards available here - on one board test passes and fsl-usb init succeeds, but on other board test fails, causing fsl-usb init to fail. This patch changes ehci_fsl_setup_phy() not to test PHY_CLK_VALID on controller version 1.6 that (per manual) does not have this bit. Signed-off-by: Nikita Yushchenko <nyushchenko@dev.rtsoft.ru> Signed-off-by: Jiri Slaby <jslaby@suse.cz> 
commit d183c81929beeba842b74422f754446ef2b8b49c upstream.

Per reference manuals of Freescale P1020 and P2020 SoCs, USB controller
present in these SoCs has bit 17 of USBx_CONTROL register marked as
Reserved - there is no PHY_CLK_VALID bit there.

Testing for this bit in ehci_fsl_setup_phy() behaves differently on two
P1020RDB boards available here - on one board test passes and fsl-usb
init succeeds, but on other board test fails, causing fsl-usb init to
fail.

This patch changes ehci_fsl_setup_phy() not to test PHY_CLK_VALID on
controller version 1.6 that (per manual) does not have this bit.

Signed-off-by: Nikita Yushchenko <nyushchenko@dev.rtsoft.ru>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
xhci: For streams the css flag most be read from the stream-ctx on ep stop 2014-05-23T08:35:19+00:00 Hans de Goede hdegoede@redhat.com 2013-10-03T22:29:47+00:00 0da837ca84b26c3c4f560788a6e62b12d345e49f commit c4bedb77ec4cb42f37cae4cbfddda8283161f7c8 upstream. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> 
commit c4bedb77ec4cb42f37cae4cbfddda8283161f7c8 upstream.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
usb: xhci: Prefer endpoint context dequeue pointer over stopped_trb 2014-05-15T07:55:44+00:00 Julius Werner jwerner@chromium.org 2014-04-25T16:20:13+00:00 29b56e8cf0da4e00cd7eda99ca352c67ae394d4d 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 <jwerner@chromium.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> 
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 <jwerner@chromium.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
usb/xhci: fix compilation warning when !CONFIG_PCI && !CONFIG_PM 2014-05-15T07:55:24+00:00 David Cohen david.a.cohen@linux.intel.com 2014-04-25T16:20:16+00:00 0cb7ed574a6111675fc616edbed1b9e3d4c6d48d 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 <david.a.cohen@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> 
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 <david.a.cohen@linux.intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
xhci: Switch Intel Lynx Point ports to EHCI on shutdown. 2014-05-15T07:55:23+00:00 Denis Turischev denis.turischev@compulab.co.il 2014-04-25T16:20:14+00:00 ed6e3e1b433b74a67478e749b94e08bde40c4279 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 <denis@compulab.co.il> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> 
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 <denis@compulab.co.il>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
xhci: Prevent runtime pm from autosuspending during initialization 2014-05-15T07:55:23+00:00 Mathias Nyman mathias.nyman@linux.intel.com 2014-03-03T17:30:17+00:00 5c412cc900b94dfa0a5700ed622693c0a6b8e378 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 <mathias.nyman@linux.intel.com> Acked-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> 
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 <mathias.nyman@linux.intel.com>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
xhci: Fix resume issues on Renesas chips in Samsung laptops 2014-03-31T12:22:34+00:00 Sarah Sharp sarah.a.sharp@linux.intel.com 2014-01-17T23:38:12+00:00 1e716a5e78cb28cb004ccb58d904191f0d1cbba3 commit 1aa9578c1a9450fb21501c4f549f5b1edb557e6d upstream. Don Zickus <dzickus@redhat.com> writes: Some co-workers of mine bought Samsung laptops that had mostly usb3 ports. Those ports did not resume correctly (the driver would timeout communicating and fail). This led to frustration as suspend/resume is a common use for laptops. Poking around, I applied the reset on resume quirk to this chipset and the resume started working. Reloading the xhci_hcd module had been the temporary workaround. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Don Zickus <dzickus@redhat.com> Tested-by: Prarit Bhargava <prarit@redhat.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> 
commit 1aa9578c1a9450fb21501c4f549f5b1edb557e6d upstream.

Don Zickus <dzickus@redhat.com> writes:

Some co-workers of mine bought Samsung laptops that had mostly usb3 ports.
Those ports did not resume correctly (the driver would timeout communicating
and fail).  This led to frustration as suspend/resume is a common use for
laptops.

Poking around, I applied the reset on resume quirk to this chipset and the
resume started working.  Reloading the xhci_hcd module had been the temporary
workaround.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Don Zickus <dzickus@redhat.com>
Tested-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Revert "xhci 1.0: Limit arbitrarily-aligned scatter gather." 2014-03-22T21:01:55+00:00 Mathias Nyman mathias.nyman@linux.intel.com 2014-03-07T15:06:57+00:00 c4b97b0abae4950f772647dcf964d0fad6782515 commit e2ed511400d41e0d136089d5a55ceab57c6a2426 upstream. This reverts commit 247bf557273dd775505fb9240d2d152f4f20d304. This commit, together with commit 3804fad45411b48233b48003e33a78f290d227c8 "USBNET: ax88179_178a: enable tso if usb host supports sg dma" were origially added to get xHCI 1.0 hosts and usb ethernet ax88179_178a devices working together with scatter gather. xHCI 1.0 hosts pose some requirement on how transfer buffers are aligned, setting this requirement for 1.0 hosts caused USB 3.0 mass storage devices to fail more frequently. USB 3.0 mass storage devices used to work before 3.14-rc1. Theoretically, the TD fragment rules could have caused an occasional disk glitch. Now the devices *will* fail, instead of theoretically failing. >From a user perspective, this looks like a regression; the USB device obviously fails on 3.14-rc1, and may sometimes silently fail on prior kernels. The proper soluition is to implement the TD fragment rules required, but for now this patch needs to be reverted to get USB 3.0 mass storage devices working at the level they used to. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> 
commit e2ed511400d41e0d136089d5a55ceab57c6a2426 upstream.

This reverts commit 247bf557273dd775505fb9240d2d152f4f20d304.

This commit, together with commit 3804fad45411b48233b48003e33a78f290d227c8
"USBNET: ax88179_178a: enable tso if usb host supports sg dma" were
origially added to get xHCI 1.0 hosts and usb ethernet ax88179_178a devices
working together with scatter gather. xHCI 1.0 hosts pose some requirement on how transfer
buffers are aligned, setting this requirement for 1.0 hosts caused USB 3.0 mass
storage devices to fail more frequently.

USB 3.0 mass storage devices used to work before 3.14-rc1.  Theoretically,
the TD fragment rules could have caused an occasional disk glitch.
Now the devices *will* fail, instead of theoretically failing.
>From a user perspective, this looks like a regression; the USB device obviously
fails on 3.14-rc1, and may sometimes silently fail on prior kernels.

The proper soluition is to implement the TD fragment rules required, but for now
this patch needs to be reverted to get USB 3.0 mass storage devices working at the
level they used to.

Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
usb: ohci: use amd_chipset_type to filter for SB800 prefetch 2014-03-12T12:25:33+00:00 Huang Rui ray.huang@amd.com 2013-10-03T15:37:13+00:00 e89b9f7e760aa33822346d27dd43792e59d373cf commit 02c123ee99c793f65af2dbda17d5fe87d448f808 upstream. Commit "usb: pci-quirks: refactor AMD quirk to abstract AMD chipset types" introduced a new AMD chipset type to filter AMD platforms with different chipsets. According to a recent thread [1], this patch updates SB800 prefetch routine in AMD PLL quirk. And make it use the new chipset type to represent SB800 generation. [1] http://marc.info/?l=linux-usb&m=138012321616452&w=2 Signed-off-by: Huang Rui <ray.huang@amd.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jiri Slaby <jslaby@suse.cz> 
commit 02c123ee99c793f65af2dbda17d5fe87d448f808 upstream.

Commit "usb: pci-quirks: refactor AMD quirk to abstract AMD chipset types"
introduced a new AMD chipset type to filter AMD platforms with different
chipsets.

According to a recent thread [1], this patch updates SB800 prefetch routine
in AMD PLL quirk. And make it use the new chipset type to represent SB800
generation.

[1] http://marc.info/?l=linux-usb&m=138012321616452&w=2

Signed-off-by: Huang Rui <ray.huang@amd.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>