Wait for Start Of Frame interrupt, then wait 20 us, before starting
port resume. Workaround for hardware issue that can cause the SOF to
be sent out at the same time as the phy speed change.
Change-Id: I91ccbd2902448e87aa3cdf1970305de22efa1c10
Signed-off-by: Colin Cross <ccross@android.com>
The Tegra2 USB controller doesn't properly deal with misaligned DMA
buffers, causing corruption. This is especially prevalent with USB
network adapters, where skbuff alignment is often in the middle of a
4-byte dword.
To avoid this, allocate a temporary buffer for the DMA if the provided
buffer isn't sufficiently aligned.
Signed-off-by: Robert Morell <rmorell@nvidia.com>
while USB is active to eliminate all USB buffer underruns.
Change-Id: I9977224601e715e950284708958be98d37b3e6b1
Signed-off-by: Nathan Connell <w14185@motorola.com>
This fixes a regression where hubs cannot detect new devices once they
have been auto-suspended.
Change-Id: I4b3efcaa9634b9a912060e438527000bbc83dc32
Signed-off-by: Benoit Goby <benoit@android.com>
To prevent USB glitch.
Also only program PTC bits when resume from LP0
Change-Id: Iced668e33f986828d3a483b411055948b5b257e1
Signed-off-by: Jay Cheng <jacheng@nvidia.com>
Reschedule rh_timer may cause usb device resume fail, as rh_timer may be
timeout and send USB_REQ_GET_STATUS SETUP control transfer by the time when
the device is handling clear suspend feature, which in turn the device may
drop clear suspend feature request.
Actually on port resume case, the host driver don't need to reschedule
rh_timer to check port status. The host driver will check port status right
after suspend feature is cleared.
Change-Id: I6205e97af49ed4349b6215b851f6b5f1394258d8
Signed-off-by: Jay Cheng <jacheng@nvidia.com>
commit f8bbeabc34 upstream.
Fix two bugs with the port array setup.
The first bug will only show up with broken xHCI hosts with Extended
Capabilities registers that have duplicate port speed entries for the same
port. The idea with the original code was to set the port_array entry to
-1 if the duplicate port speed entry said the port was a different speed
than the original port speed entry. That would mean that later, the port
would not be exposed to the USB core. Unfortunately, I forgot a continue
statement, and the port_array entry would just be overwritten in the next
line.
The second bug would happen if there are conflicting port speed registers
(so that some entry in port_array is -1), or one of the hardware port
registers was not described in the port speed registers (so that some
entry in port_array is 0). The code that sets up the usb2_ports array
would accidentally claim those ports. That wouldn't really cause any
user-visible issues, but it is a bug.
This patch should go into the stable trees that have the port array and
USB 3.0 port disabling prevention patches.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Fix enumeration when a device is plugged while the host is in lp0 state.
Change-Id: Idb491f347172daac8a5603ed098b422b15cc534e
Signed-off-by: Benoit Goby <benoit@android.com>
usbcore will reenable usb interrupts later once the bus has been
resumed.
Change-Id: If78088bc86710f50293d84234d764655f4bba979
Signed-off-by: Benoit Goby <benoit@android.com>
usbcore will change it once the bus has been resumed. This fixes
the "hub 3-0:1.0: activate --> -22" error on resume.
Change-Id: Icff283a60634b4d003e77aafb5a5127d415cbd3f
Signed-off-by: Benoit Goby <benoit@android.com>
PORT_SUSPEND bit will be cleared by the host controller when PORT_RESUME
change to 0.
Change-Id: I94a72f51be1cebee414f11ace89a7e8b3249278d
Signed-off-by: Jay Cheng <jacheng@nvidia.com>
commit a85b4e7f44 upstream.
Tested on MacBookAir3,1. Without this, we get EPROTO errors when
fetching device config descriptors.
Signed-off-by: Brian Tarricone <brian@tarricone.org>
Reported-by: Benoit Gschwind <gschwind@gnu-log.net>
Tested-by: Edgar Hucek <gimli@dark-green.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 02e2c51ba3 upstream.
This patch (as1435) fixes an obscure and unlikely race in ehci-hcd.
When an async URB is unlinked, the corresponding QH is removed from
the async list. If the QH's endpoint is then disabled while the URB
is being given back, ehci_endpoint_disable() won't find the QH on the
async list, causing it to believe that the QH has been lost. This
will lead to a memory leak at best and quite possibly to an oops.
The solution is to trust usbcore not to lose track of endpoints. If
the QH isn't on the async list then it doesn't need to be taken off
the list, but the driver should still wait for the QH to become IDLE
before disabling it.
In theory this fixes Bugzilla #20182. In fact the race is so rare
that it's not possible to tell whether the bug is still present.
However, adding delays and making other changes to force the race
seems to show that the patch works.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
CC: David Brownell <david-b@pacbell.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 723b991a62 upstream.
The permissions for the lpm debugfs file is incorrect, this fixes it.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Alek Du <alek.du@intel.com>
Cc: Jacob Pan <jacob.jun.pan@intel.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 6dd0a3a7e0 upstream.
Disabling SuperSpeed ports is a Very Bad Thing (TM). It disables
SuperSpeed terminations, which means that devices will never connect at
SuperSpeed on that port. For USB 2.0/1.1 ports, disabling the port meant
that the USB core could always get a connect status change later. That's
not true with USB 3.0 ports.
Do not let the USB core disable SuperSpeed ports. We can't rely on the
device speed in the port status registers, since that isn't valid until
there's a USB device connected to the port. Instead, we use the port
speed array that's created from the Extended Capabilities registers.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit da6699ce4a upstream.
An xHCI host controller contains USB 2.0 and USB 3.0 ports, which can
occur in any order in the PORTSC registers. We cannot read the port speed
bits in the PORTSC registers at init time to determine the port speed,
since those bits are only valid when a USB device is plugged into the
port.
Instead, we read the "Supported Protocol Capability" registers in the xHC
Extended Capabilities space. Those describe the protocol, port offset in
the PORTSC registers, and port count. We use those registers to create
two arrays of pointers to the PORTSC registers, one for USB 3.0 ports, and
another for USB 2.0 ports. A third array keeps track of the port protocol
major revision, and is indexed with the internal xHCI port number.
This commit is a bit big, but it should be queued for stable because the "Don't
let the USB core disable SuperSpeed ports" patch depends on it. There is no
other way to determine which ports are SuperSpeed ports without this patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 7a3783efff upstream.
We have been having problems with the USB-IF Gold Tree tests when plugging
and unplugging devices from the tree. I have seen that the reset-device
and configure-endpoint commands, which are invoked from
xhci_discover_or_reset_device() and xhci_configure_endpoint(), will sometimes
time out.
After much debugging, I determined that the commands themselves do not actually
time out, but rather their completion events do not get delivered to the right
place.
This happens when the command ring has just wrapped around, and it's enqueue
pointer is left pointing to the link TRB. xhci_discover_or_reset_device() and
xhci_configure_endpoint() use the enqueue pointer directly as their command
TRB pointer, without checking whether it's pointing to the link TRB.
When the completion event arrives, if the command TRB is pointing to the link
TRB, the check against the command ring dequeue pointer in
handle_cmd_in_cmd_wait_list() fails, so the completion inside the command does
not get signaled.
The patch below fixes the timeout problem for me.
This should be queued for the 2.6.35 and 2.6.36 stable trees.
Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit dc07c91b9b upstream.
USB2.0 spec 9.6.6 says: For all endpoints, bit 10..0 specify the maximum
packet size(in bytes).
So the wMaxPacketSize mask should be 0x7ff rather than 0x3ff.
This patch should be queued for the stable tree. The bug in
xhci_endpoint_init() was present as far back as 2.6.31, and the bug in
xhci_get_max_esit_payload() was present when the function was introduced
in 2.6.34.
Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 241b652f19 upstream.
If the xHCI host controller shares an interrupt line with another device,
the xHCI driver needs to check if the interrupt was generated by its
hardware. Unfortunately, the user will see a ton of "Spurious interrupt."
lines if the other hardware interrupts often. Lawrence found his dmesg
output cluttered with this output when the xHCI host shared an interrupt
with his i915 hardware.
Remove the warning, as sharing an interrupt is a normal thing.
This should be applied to the 2.6.36 stable tree.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Lawrence Rust <lvr@softsystem.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
scan_periodic is called with irq disabled. Merged Alan Stern's patch
to reduce the overhead of scan_periodic:
http://article.gmane.org/gmane.linux.usb.general/37441
Here is a patch which ought to reduce the overhead of the loop. It
avoids doing the expensive call to qh_completions() more than once
for each qh.
Change-Id: I218c75a1ce21edd3d58c7e8abd3e7f75880b6ad0
Signed-off-by: Benoit Goby <benoit@android.com>
Protect the bus suspend/resume functions behind #ifdef CONFIG_PM.
This prevents a compile error if CONFIG_PM is turned off.
Signed-off-by: Allen Martin <amartin@nvidia.com>
Signed-off-by: Colin Cross <ccross@android.com>
Tegra host controller will time the resume operation to clear the bit
when the port control state switches to HS or FS Idle. This behavior
is different from EHCI where the host controller driver is required
to set this bit to a zero after the resume duration is timed in the
driver.
Poll PORT_SUSPEND bit till the suspend is completed. Write PORT_RESUME to 0
to clear PORT_SUSPEND bit.
Disable disconnect detection during resume.
Change-Id: I30a45dc7e7a87773a93c128877d0f0827e5d44b7
Signed-off-by: Jay Cheng <jacheng@nvidia.com>
commit ac9dfe9cdd upstream.
Some functions changed by 1c98347e61.
However, There was a change mistake of the function (outsw).
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
CC: Paul Mundt <lethal@linux-sh.org>
Acked-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Program PTC bits as NORMAL_OP is enough when resume.
Change-Id: I229eb3ef2ebaff72d023179502ec7a8904e87682
Signed-off-by: Jay Cheng <jacheng@nvidia.com>
There is one wmb missing in the usb host controller driver after the queue head
update. Due to this data transaction is not happening on the bus after urb
submission by the hcd driver. Register updates/queue heads data in the memory
is not reflected on the AHB bus. After adding the wmb after queue head update
data transaction the USB bus started with out any delay.
originally fixed by Venkat Moganty <vmoganty@nvidia.com>
Change-Id: Ic834df5172ac2f2eb3bced317d38b4a2e7a44801
Signed-off-by: Jay Cheng <jacheng@nvidia.com>
There is no need to poweroff the phy and disable the clocks on shutdown.
This interferes with autopm that may try to disable the clocks after
shutdown.
Change-Id: I3aee19abe6dd11685b3be348e25fc3e195a2a416
Signed-off-by: Benoit Goby <benoit@android.com>
If the device connected to a port has out-of-band wakeup
signaling, the phy and controller may be powered off on bus suspend.
Change-Id: Ia206f05d01160411b97aefa83045cd759d35b66d
Signed-off-by: Benoit Goby <benoit@android.com>
There is no need anymore to check the OTG state on every interrupts and
use a work thread.
Moved the suspend code from usb_phy.c as this is ehci specific.
Change-Id: I523baab1476323a35360b1d802088370e42d0fd7
Signed-off-by: Benoit Goby <benoit@android.com>
Tegra quirk: The PORT_RESET bit in PORTSC1 does not need to be cleared
and there is no need to wait for it to clear. The bit will automatically
change to 0 when the bus-reset sequence is done and an interrupt will be
generated.
Change-Id: I645417013af46785a249096ebc06a1f688228d94
Signed-off-by: Benoit Goby <benoit@android.com>
only reset the controller when doing so won't also reset the phy (Tegra quirk)
Change-Id: I549a18977d0d5ebfa12c32016aa9e6bffaa8643c
Signed-off-by: Gary King <gking@nvidia.com>
On suspend, use phy_suspend save the phy registers so that there is
no need to reset the controller and re-enumerate devices on resume.
Change-Id: I00fe5b87a1b319044724494b8e635b540088a38b
Signed-off-by: Benoit Goby <benoit@android.com>
We have to do so due to HW limitation.
Signed-off-by: Alek Du <alek.du@intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The iounmap(ehci->ohci_hcctrl_reg); should be the first thing we do
because the ioremap() was the last thing we did. Also if we hit any of
the goto statements in the original code then it would have led to a
NULL dereference of "ehci". This bug was introduced in: 796bcae736
"USB: powerpc: Workaround for the PPC440EPX USBH_23 errata [take 3]"
I modified the few lines in front a little so that my code didn't
obscure the return success code path.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Reviewed-by: Grant Likely <grant.likely@secretlab.ca>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch fixes a isoc transfer bug reported by Sander Eikelenboom.
When ep->skip is set, endpoint ring dequeue pointer should be updated
when processed every missed td. Although ring dequeue pointer will also
be updated when ep->skip is clear, leave it intact during missed tds
processing may cause two issues:
1). If the very next valid transfer following missed tds is a short
transfer, its actual_length will be miscalculated;
2). If there are too many missed tds during transfer, new inserted tds
may found the transfer ring full and urb enqueue fails.
Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
