linux-toradex.git/drivers/usb/host, branch v3.10.9 Linux kernel for Apalis and Colibri modules USB: EHCI: accept very late isochronous URBs 2013-08-20T15:43:04+00:00 Alan Stern stern@rowland.harvard.edu 2013-08-07T14:58:05+00:00 c72a0e036f9d80c609e608a723751343f1f5e9fc commit 24f531371de17010f2b1b57d90e42240032e7733 upstream. Since commits 4005ad4390bf (EHCI: implement new semantics for URB_ISO_ASAP) and c75c5ab575af (ALSA: USB: adjust for changed 3.8 USB API) became widely distributed, people have been experiencing problems with audio transfers. The slightest underrun causes complete failure, requiring the audio stream to be restarted. It turns out that the current isochronous API doesn't handle underruns in the best way. The ALSA developers would much rather have transfers that are submitted too late be accepted and complete in the normal fashion, rather than being refused outright. This patch implements the requested approach. When an isochronous URB submission is so late that all its scheduled slots have already expired, a debugging message will be printed in the log and the URB will be accepted as usual. Assuming it was submitted by a completion handler (which is normally the case), it will complete shortly thereafter with all the usb_iso_packet_descriptor status fields marked -EXDEV. This fixes (for ehci-hcd) https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603 It should be applied to all kernels that include commit 4005ad4390bf. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Maksim Boyko <maksboyko@yandex.ru> CC: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 24f531371de17010f2b1b57d90e42240032e7733 upstream.

Since commits 4005ad4390bf (EHCI: implement new semantics for
URB_ISO_ASAP) and c75c5ab575af (ALSA: USB: adjust for changed 3.8 USB
API) became widely distributed, people have been experiencing problems
with audio transfers.  The slightest underrun causes complete failure,
requiring the audio stream to be restarted.

It turns out that the current isochronous API doesn't handle underruns
in the best way.  The ALSA developers would much rather have transfers
that are submitted too late be accepted and complete in the normal
fashion, rather than being refused outright.

This patch implements the requested approach.  When an isochronous URB
submission is so late that all its scheduled slots have already
expired, a debugging message will be printed in the log and the URB
will be accepted as usual.  Assuming it was submitted by a completion
handler (which is normally the case), it will complete shortly
thereafter with all the usb_iso_packet_descriptor status fields marked
-EXDEV.

This fixes (for ehci-hcd)

	https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603

It should be applied to all kernels that include commit 4005ad4390bf.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Maksim Boyko <maksboyko@yandex.ru>
CC: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: EHCI: Fix resume signalling on remote wakeup 2013-08-04T08:50:46+00:00 Roger Quadros rogerq@ti.com 2013-07-09T14:03:50+00:00 c65b5f6ade7209fc5eda9f0779de4ee254a6bb78 commit 47a64a13d54f6c669b00542848d5550be3d3310e upstream. Set the ehci->resuming flag for the port we receive a remote wakeup on so that resume signalling can be completed. Without this, the root hub timer will not fire again to check if the resume was completed and there will be a never-ending wait on on the port. This effect is only observed if the HUB IRQ IN does not come after we have initiated the port resume. Signed-off-by: Roger Quadros <rogerq@ti.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 47a64a13d54f6c669b00542848d5550be3d3310e upstream.

Set the ehci->resuming flag for the port we receive a remote
wakeup on so that resume signalling can be completed.

Without this, the root hub timer will not fire again to check
if the resume was completed and there will be a never-ending wait on
on the port.

This effect is only observed if the HUB IRQ IN does not come after we
have initiated the port resume.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
xhci: Avoid NULL pointer deref when host dies. 2013-08-04T08:50:46+00:00 Sarah Sharp sarah.a.sharp@linux.intel.com 2013-07-24T17:27:13+00:00 5dbb5d4f24bf6862a888637b7506d1e04c2d2276 commit 203a86613fb3bf2767335659513fa98563a3eb71 upstream. When the host controller fails to respond to an Enable Slot command, and the host fails to respond to the register write to abort the command ring, the xHCI driver will assume the host is dead, and call usb_hc_died(). The USB device's slot_id is still set to zero, and the pointer stored at xhci->devs[0] will always be NULL. The call to xhci_check_args in xhci_free_dev should have caught the NULL virt_dev pointer. However, xhci_free_dev is designed to free the xhci_virt_device structures, even if the host is dead, so that we don't leak kernel memory. xhci_free_dev checks the return value from the generic xhci_check_args function. If the return value is -ENODEV, it carries on trying to free the virtual device. The issue is that xhci_check_args looks at the host controller state before it looks at the xhci_virt_device pointer. It will return -ENIVAL because the host is dead, and xhci_free_dev will ignore the return value, and happily dereference the NULL xhci_virt_device pointer. The fix is to make sure that xhci_check_args checks the xhci_virt_device pointer before it checks the host state. See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1203453 for further details. This patch doesn't solve the underlying issue, but will ensure we don't see any more NULL pointer dereferences because of the issue. This patch should be backported to kernels as old as 3.1, that contain the commit 7bd89b4017f46a9b92853940fd9771319acb578a "xhci: Don't submit commands or URBs to halted hosts." Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Vincent Thiele <vincentthiele@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 203a86613fb3bf2767335659513fa98563a3eb71 upstream.

When the host controller fails to respond to an Enable Slot command, and
the host fails to respond to the register write to abort the command
ring, the xHCI driver will assume the host is dead, and call
usb_hc_died().

The USB device's slot_id is still set to zero, and the pointer stored at
xhci->devs[0] will always be NULL.  The call to xhci_check_args in
xhci_free_dev should have caught the NULL virt_dev pointer.

However, xhci_free_dev is designed to free the xhci_virt_device
structures, even if the host is dead, so that we don't leak kernel
memory.  xhci_free_dev checks the return value from the generic
xhci_check_args function.  If the return value is -ENODEV, it carries on
trying to free the virtual device.

The issue is that xhci_check_args looks at the host controller state
before it looks at the xhci_virt_device pointer.  It will return -ENIVAL
because the host is dead, and xhci_free_dev will ignore the return
value, and happily dereference the NULL xhci_virt_device pointer.

The fix is to make sure that xhci_check_args checks the xhci_virt_device
pointer before it checks the host state.

See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1203453 for
further details.  This patch doesn't solve the underlying issue, but
will ensure we don't see any more NULL pointer dereferences because of
the issue.

This patch should be backported to kernels as old as 3.1, that
contain the commit 7bd89b4017f46a9b92853940fd9771319acb578a "xhci: Don't
submit commands or URBs to halted hosts."

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Vincent Thiele <vincentthiele@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
xhci: fix null pointer dereference on ring_doorbell_for_active_rings 2013-08-04T08:50:46+00:00 Oleksij Rempel linux@rempel-privat.de 2013-07-21T13:36:19+00:00 10a1c13241f682cdc866f2aa8a0e5c5373470ecb commit d66eaf9f89502971fddcb0de550b01fa6f409d83 upstream. in some cases where device is attched to xhci port and do not responding, for example ath9k_htc with stalled firmware, kernel will crash on ring_doorbell_for_active_rings. This patch check if pointer exist before it is used. This patch should be backported to kernels as old as 2.6.35, that contain the commit e9df17eb1408cfafa3d1844bfc7f22c7237b31b8 "USB: xhci: Correct assumptions about number of rings per endpoint" Signed-off-by: Oleksij Rempel <linux@rempel-privat.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit d66eaf9f89502971fddcb0de550b01fa6f409d83 upstream.

in some cases where device is attched to xhci port and do not responding,
for example ath9k_htc with stalled firmware, kernel will
crash on ring_doorbell_for_active_rings.
This patch check if pointer exist before it is used.

This patch should be backported to kernels as old as 2.6.35, that
contain the commit e9df17eb1408cfafa3d1844bfc7f22c7237b31b8 "USB: xhci:
Correct assumptions about number of rings per endpoint"

Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: host: xhci: Enable XHCI_SPURIOUS_SUCCESS for all controllers with xhci 1.0 2013-08-04T08:50:44+00:00 George Cherian george.cherian@ti.com 2013-07-01T05:29:12+00:00 a875d82eda58712d81caf78ebb515fb072187138 commit 07f3cb7c28bf3f4dd80bfb136cf45810c46ac474 upstream. Xhci controllers with hci_version > 0.96 gives spurious success events on short packet completion. During webcam capture the "ERROR Transfer event TRB DMA ptr not part of current TD" was observed. The same application works fine with synopsis controllers hci_version 0.96. The same issue is seen with Intel Pantherpoint xhci controller. So enabling this quirk in xhci_gen_setup if controller verion is greater than 0.96. For xhci-pci move the quirk to much generic place xhci_gen_setup. Note from Sarah: The xHCI 1.0 spec changed how hardware handles short packets. The HW will notify SW of the TRB where the short packet occurred, and it will also give a successful status for the last TRB in a TD (the one with the IOC flag set). On the second successful status, that warning will be triggered in the driver. Software is now supposed to not assume the TD is not completed until it gets that last successful status. That means we have a slight race condition, although it should have little practical impact. This patch papers over that issue. It's on my long-term to-do list to fix this race condition, but it is a much more involved patch that will probably be too big for stable. This patch is needed for stable to avoid serious log spam. This patch should be backported to kernels as old as 3.0, that contain the commit ad808333d8201d53075a11bc8dd83b81f3d68f0b "Intel xhci: Ignore spurious successful event." The patch will have to be modified for kernels older than 3.2, since that kernel added the xhci_gen_setup function for xhci platform devices. The correct conflict resolution for kernels older than 3.2 is to set XHCI_SPURIOUS_SUCCESS in xhci_pci_quirks for all xHCI 1.0 hosts. Signed-off-by: George Cherian <george.cherian@ti.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 07f3cb7c28bf3f4dd80bfb136cf45810c46ac474 upstream.

Xhci controllers with hci_version > 0.96 gives spurious success
events on short packet completion. During webcam capture the
"ERROR Transfer event TRB DMA ptr not part of current TD" was observed.
The same application works fine with synopsis controllers hci_version 0.96.
The same issue is seen with Intel Pantherpoint xhci controller. So enabling
this quirk in xhci_gen_setup if controller verion is greater than 0.96.
For xhci-pci move the quirk to much generic place xhci_gen_setup.

Note from Sarah:

The xHCI 1.0 spec changed how hardware handles short packets.  The HW
will notify SW of the TRB where the short packet occurred, and it will
also give a successful status for the last TRB in a TD (the one with the
IOC flag set).  On the second successful status, that warning will be
triggered in the driver.

Software is now supposed to not assume the TD is not completed until it
gets that last successful status.  That means we have a slight race
condition, although it should have little practical impact.  This patch
papers over that issue.

It's on my long-term to-do list to fix this race condition, but it is a
much more involved patch that will probably be too big for stable.  This
patch is needed for stable to avoid serious log spam.

This patch should be backported to kernels as old as 3.0, that
contain the commit ad808333d8201d53075a11bc8dd83b81f3d68f0b "Intel xhci:
Ignore spurious successful event."

The patch will have to be modified for kernels older than 3.2, since
that kernel added the xhci_gen_setup function for xhci platform devices.
The correct conflict resolution for kernels older than 3.2 is to set
XHCI_SPURIOUS_SUCCESS in xhci_pci_quirks for all xHCI 1.0 hosts.

Signed-off-by: George Cherian <george.cherian@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: host: xhci-plat: release mem region while removing module 2013-07-22T01:21:24+00:00 George Cherian george.cherian@ti.com 2013-06-21T08:29:08+00:00 a5ea8ca0b2d24ab8beae6b218abeb771d40ae966 commit 5388a3a5faba8dfa69e5f06c3a415d373c1a4316 upstream. Do a release_mem_region of the hcd resource. Without this the subsequent insertion of module fails in request_mem_region. Signed-off-by: George Cherian <george.cherian@ti.com> Acked-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 5388a3a5faba8dfa69e5f06c3a415d373c1a4316 upstream.

Do a release_mem_region of the hcd resource. Without this the
subsequent insertion of module fails in request_mem_region.

Signed-off-by: George Cherian <george.cherian@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
xhci: check for failed dma pool allocation 2013-07-22T01:21:24+00:00 Mathias Nyman mathias.nyman@linux.intel.com 2013-06-17T16:56:33+00:00 333db1d07c454f02e008780273df44c1e3102448 commit 025f880cb2e4d7218d0422d4b07bea1a68959c38 upstream. Fail and free the container context in case dma_pool_alloc() can't allocate the raw context data part of it This patch should be backported to kernels as old as 2.6.31, that contain the commit d115b04818e57bdbc7ccde4d0660b15e33013dc8 "USB: xhci: Support for 64-byte contexts". Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: John Youn <johnyoun@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 025f880cb2e4d7218d0422d4b07bea1a68959c38 upstream.

Fail and free the container context in case dma_pool_alloc() can't allocate
the raw context data part of it

This patch should be backported to kernels as old as 2.6.31, that
contain the commit d115b04818e57bdbc7ccde4d0660b15e33013dc8 "USB: xhci:
Support for 64-byte contexts".

Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: John Youn <johnyoun@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: ehci-omap: Tweak PHY initialization sequence 2013-07-22T01:21:24+00:00 Roger Quadros rogerq@ti.com 2013-06-14T13:52:07+00:00 5b3e69eafcfc490dcdd0368f680170b24686abe5 commit 4e5c9e6fa2d232a0686d5fe45cd1508484048936 upstream. For PHY mode, the PHYs must be brought out of reset before the EHCI controller is started. This patch fixes the issue where USB devices are not found on Beagleboard/Beagle-xm if USB has been started previously by the bootloader. (e.g. by "usb start" command in u-boot) Tested on Beagleboard, Beagleboard-xm and Pandaboard. Issue present on 3.10 onwards. Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Tested-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 4e5c9e6fa2d232a0686d5fe45cd1508484048936 upstream.

For PHY mode, the PHYs must be brought out of reset
before the EHCI controller is started.

This patch fixes the issue where USB devices are not found
on Beagleboard/Beagle-xm if USB has been started previously
by the bootloader. (e.g. by "usb start" command in u-boot)

Tested on Beagleboard, Beagleboard-xm and Pandaboard.

Issue present on 3.10 onwards.

Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: EHCI: fix regression related to qh_refresh() 2013-05-30T12:20:04+00:00 Alan Stern stern@rowland.harvard.edu 2013-05-29T15:33:52+00:00 077f5f1c23b3cf1134c031677497dfb6077e6bdd This patch adds some code that inadvertently got left out of commit c1fdb68e3d73741630ca16695cf9176c233be7ed (USB: EHCI: changes related to qh_refresh()). The calls to qh_refresh() and qh_link_periodic() were taken out of qh_schedule(); therefore it is necessary to call these routines manually after calling qh_schedule(). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Oleksij Rempel <linux@rempel-privat.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This patch adds some code that inadvertently got left out of commit
c1fdb68e3d73741630ca16695cf9176c233be7ed (USB: EHCI: changes related
to qh_refresh()).  The calls to qh_refresh() and qh_link_periodic()
were taken out of qh_schedule(); therefore it is necessary to call
these routines manually after calling qh_schedule().

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: revert periodic scheduling bugfix 2013-05-29T01:41:06+00:00 Alan Stern stern@rowland.harvard.edu 2013-05-28T18:03:10+00:00 fdc03438f53a00294ed9939eb3a1f6db6f3d8963 This patch reverts commit 3e619d04159be54b3daa0b7036b0ce9e067f4b5d (USB: EHCI: fix bug in scheduling periodic split transfers). The commit was valid -- it fixed a real bug -- but the periodic scheduler in ehci-hcd is in such bad shape (especially the part that handles split transactions) that fixing one bug is very likely to cause another to surface. That's what happened in this case; the result was choppy and noisy playback on certain 24-bit audio devices. The only real fix will be to rewrite this entire section of code. My next project... This fixes https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110. Thanks to Tim Richardson for extra testing and feedback, and to Joseph Salisbury and Tyson Tan for tracking down the original source of the problem. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: Joseph Salisbury <joseph.salisbury@canonical.com> CC: Tim Richardson <tim@tim-richardson.net> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This patch reverts commit 3e619d04159be54b3daa0b7036b0ce9e067f4b5d
(USB: EHCI: fix bug in scheduling periodic split transfers).  The
commit was valid -- it fixed a real bug -- but the periodic scheduler
in ehci-hcd is in such bad shape (especially the part that handles
split transactions) that fixing one bug is very likely to cause
another to surface.  That's what happened in this case; the result was
choppy and noisy playback on certain 24-bit audio devices.

The only real fix will be to rewrite this entire section of code.  My
next project...

This fixes https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110.

Thanks to Tim Richardson for extra testing and feedback, and to Joseph
Salisbury and Tyson Tan for tracking down the original source of the
problem.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Joseph Salisbury <joseph.salisbury@canonical.com>
CC: Tim Richardson <tim@tim-richardson.net>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>