commit feca7746d5d9e84b105a613b7f3b6ad00d327372 upstream. This patch (as1661) fixes a rather obscure bug in ehci-hcd. In a couple of places, the driver compares the DMA address stored in a QH's overlay region with the address of a particular qTD, in order to see whether that qTD is the one currently being processed by the hardware. (If it is then the status in the QH's overlay region is more up-to-date than the status in the qTD, and if it isn't then the overlay's value needs to be adjusted when the QH is added back to the active schedule.) However, DMA address in the overlay region isn't always valid. It sometimes will contain a stale value, which may happen by coincidence to be equal to a qTD's DMA address. Instead of checking the DMA address, we should check whether the overlay region is active and valid. The patch tests the ACTIVE bit in the overlay, and clears this bit when the overlay becomes invalid (which happens when the currently-executing URB is unlinked). This is the second part of a fix for the regression reported at: https://bugs.launchpad.net/bugs/1088733 Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Joseph Salisbury <joseph.salisbury@canonical.com> Reported-and-tested-by: Stephen Thirlwall <sdt@dr.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 221f8dfca89276d8aec54c6d07fbe20c281668f0 upstream. This patch (as1649) reverts commit 55bcdce8a8228223ec4d17d8ded8134ed265d2c5 (USB: EHCI: remove ASS/PSS polling timeout). That commit was written under the assumption that some controllers may take a very long time to turn off their async and periodic schedules. It now appears that in fact the schedules do get turned off reasonably quickly, but some controllers occasionally leave the schedules' status bits turned on and consequently ehci-hcd can't tell that the schedules are off. VIA controllers in particular have this problem. ehci-hcd tells the hardware to turn off the async schedule, the schedule does get turned off, but the status bit remains on. Since the EHCI spec requires that the schedules not be re-enabled until the previous disable has taken effect, with an unlimited timeout the async schedule never gets turned back on. The resulting symptom is that the system is unable to communicate with USB devices. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Ronald <ronald645@gmail.com> Reported-and-tested-by: Paul Hartman <paul.hartman@gmail.com> Reported-and-tested-by: Dieter Nützel <dieter@nuetzel-hh.de> Reported-and-tested-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 04753523266629b1cd0518091da1658755787198 upstream. The module alias should be "ehci-omap" and not "omap-ehci" to match the platform device name. The omap-ehci module should now autoload correctly. 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 428525f97153505e83983460a8d08a3210aa6b8a upstream. This driver does not request any gpios so don't free them. Fixes L3 bus error on multiple modprobe/rmmod of ehci_hcd with ehci-omap in use. Without this patch, EHCI will break on repeated insmod/rmmod of ehci_hcd for all OMAP2+ platforms that use EHCI and set 'phy_reset = true' in usbhs_omap_board_data. i.e. board-3430sdp.c: .phy_reset = true, board-3630sdp.c: .phy_reset = true, board-am3517crane.c: .phy_reset = true, board-am3517evm.c: .phy_reset = true, board-cm-t3517.c: .phy_reset = true, board-cm-t35.c: .phy_reset = true, board-devkit8000.c: .phy_reset = true, board-igep0020.c: .phy_reset = true, board-igep0020.c: .phy_reset = true, board-omap3beagle.c: .phy_reset = true, board-omap3evm.c: .phy_reset = true, board-omap3pandora.c: .phy_reset = true, board-omap3stalker.c: .phy_reset = true, board-omap3touchbook.c: .phy_reset = true, board-omap4panda.c: .phy_reset = false, board-overo.c: .phy_reset = true, board-zoom.c: .phy_reset = true, Signed-off-by: Roger Quadros <rogerq@ti.com> Reviewed-by: Felipe Balbi <balbi@ti.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1654) fixes a very old bug in ehci-hcd, connected with scheduling of periodic split transfers. The calculations for full/low-speed bus usage are all carried out after the correction for bit-stuffing has been applied, but the values in the max_tt_usecs array assume it hasn't been. The array should allow for allocation of up to 90% of the bus capacity, which is 900 us, not 780 us. The symptom caused by this bug is that any isochronous transfer to a full-speed device with a maxpacket size larger than about 980 bytes is always rejected with a -ENOSPC error. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1653) fixes a bug in ehci-hcd. Unlike iTD entries, an siTD entry in the periodic schedule may not complete until the frame after the one it belongs to. Consequently, when scanning the periodic schedule it is necessary to start with the frame _preceding_ the one where the previous scan ended. Not doing this properly can result in memory leaks and failures to complete isochronous URBs. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Andy Leiserson <andy@leiserson.org> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1652) fixes a long-standing bug in ehci-hcd. The driver relies on status polls to know when to stop port-resume signalling. It uses the root-hub status timer to schedule these status polls. But when the driver for the root hub is resumed, the timer is rescheduled to go off immediately -- before the port is ready. When this happens the timer does not get re-enabled, which prevents the port resume from finishing until some other event occurs. The symptom is that when a new device is plugged in, it doesn't get recognized or enumerated until lsusb is run or something else happens. The solution is to re-enable the root-hub status timer after every status poll while a port resume is in progress. This bug hasn't surfaced before now because we never used to try to suspend the root hub in the middle of a port resume (except by coincidence). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Norbert Preining <preining@logic.at> Tested-by: Ming Lei <ming.lei@canonical.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1651) adds calls to the new
usb_hcd_{start,end}_port_resume() functions to uhci-hcd. Now UHCI
root hubs won't be runtime suspended while they are sending a resume
signal to one of their ports.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1650) adds calls to the new
usb_hcd_{start,end}_port_resume() functions to ehci-hcd. Now EHCI
root hubs won't be runtime suspended while they are sending a resume
signal to one of their ports.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1648) fixes a regression affecting nVidia EHCI controllers. Evidently they don't like to have more than one async QH unlinked at a time. I can't imagine how they manage to mess it up, but at least one of them does. The patch changes the async unlink logic in two ways: Each time an IAA cycle is started, only the first QH on the async unlink list is handled (rather than all of them). Async QHs do not all get unlinked as soon as they have been empty for long enough. Instead, only the last one (i.e., the one that has been on the schedule the longest) is unlinked, and then only if no other unlinks are in progress at the time. This means that when multiple QHs are empty, they won't be unlinked as quickly as before. That's okay; it won't affect correct operation of the driver or add an excessive load. Multiple unlinks tend to be relatively rare in any case. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Piergiorgio Sartor <piergiorgio.sartor@nexgo.de> Cc: stable <stable@vger.kernel.org> # 3.6 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>