Some Fresco Logic hosts, including those found in the AUAU N533V laptop,
advertise MSI, but fail to actually generate MSI interrupts. Add a new
xHCI quirk to skip MSI enabling for the Fresco Logic host controllers.
Fresco Logic confirms that all chips with PCI vendor ID 0x1b73 and device
ID 0x1000, regardless of PCI revision ID, do not support MSI.
This should be backported to stable kernels as far back as 2.6.36, which
was the first kernel to support MSI on xHCI hosts.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Sergey Galanov <sergey.e.galanov@gmail.com>
Cc: stable@kernel.org
xHCI controllers respond to a Reset Device command when the Slot is in the
Enabled/Disabled state by returning an error. This is fine on other host
controllers, but the Etron xHCI host controller returns a vendor-specific
error code that the xHCI driver doesn't understand. The xHCI driver then
gives up on device enumeration.
Instead of issuing a command that will fail, just return. This fixes the
issue with the xhci driver not working on ASRock P67 Pro/Extreme boards.
This should be backported to stable kernels as far back as 2.6.34.
Signed-off-by: Maarten Lankhorst <m.b.lankhorst@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
This needs to be added to the stable trees back to 2.6.34 to support an
upcoming bug fix.
Signed-off-by: Maarten Lankhorst <m.b.lankhorst@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
Some of the recently-added cpu_to_leXX and leXX_to_cpu made things somewhat
messy; this patch neatens some of these areas, removing unnecessary casts
in those parts also. In some places (where Y & Z are constants) a
comparison of (leXX_to_cpu(X) & Y) == Z has been replaced with
(X & cpu_to_leXX(Y)) == cpu_to_leXX(Z). The endian reversal of the
constants should wash out at compile time.
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Commit 834cb0fc47 "xhci: Fix memory leak
bug when dropping endpoints" added a small endian bug. This patch fixes
xhci_check_bandwidth() to read add/drop_flags LE.
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Commit 926008c938 "USB: xhci: simplify logic
of skipping missed isoc TDs" added a small endian bug. This patch
fixes skip_isoc_td() to read the DMA pointer correctly.
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* 'for-usb-next' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci:
Intel xhci: Limit number of active endpoints to 64.
Intel xhci: Ignore spurious successful event.
Intel xhci: Support EHCI/xHCI port switching.
Intel xhci: Add PCI id for Panther Point xHCI host.
xhci: STFU: Be quieter during URB submission and completion.
xhci: STFU: Don't print event ring dequeue pointer.
xhci: STFU: Remove function tracing.
xhci: Don't submit commands when the host is dead.
xhci: Clear stopped_td when Stop Endpoint command completes.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The xHCI host controller in the Panther Point chipset sometimes produces
spurious events on the event ring. If it receives a short packet, it
first puts a Transfer Event with a short transfer completion code on the
event ring. Then it puts a Transfer Event with a successful completion
code on the ring for the same TD. The xHCI driver correctly processes the
short transfer completion code, gives the URB back to the driver, and then
prints a warning in dmesg about the spurious event. These warning
messages really fill up dmesg when an HD webcam is plugged into xHCI.
This spurious successful event behavior isn't technically disallowed by
the xHCI specification, so make the xHCI driver just ignore the spurious
completion event.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The Intel Panther Point chipsets contain an EHCI and xHCI host controller
that shares some number of skew-dependent ports. These ports can be
switched from the EHCI to the xHCI host (and vice versa) by a hardware MUX
that is controlled by registers in the xHCI PCI configuration space. The
USB 3.0 SuperSpeed terminations on the xHCI ports can be controlled
separately from the USB 2.0 data wires.
This switchover mechanism is there to support users who do a custom
install of certain non-Linux operating systems that don't have official
USB 3.0 support. By default, the ports are under EHCI, SuperSpeed
terminations are off, and USB 3.0 devices will show up under the EHCI
controller at reduced speeds. (This was more palatable for the marketing
folks than having completely dead USB 3.0 ports if no xHCI drivers are
available.) Users should be able to turn on xHCI by default through a
BIOS option, but users are happiest when they don't have to change random
BIOS settings.
This patch introduces a driver method to switchover the ports from EHCI to
xHCI before the EHCI driver finishes PCI enumeration. We want to switch
the ports over before the USB core has the chance to enumerate devices
under EHCI, or boot from USB mass storage will fail if the boot device
connects under EHCI first, and then gets disconnected when the port
switches over to xHCI.
Add code to the xHCI PCI quirk to switch the ports from EHCI to xHCI. The
PCI quirks code will run before any other PCI probe function is called, so
this avoids the issue with boot devices.
Another issue is with BIOS behavior during system resume from hibernate.
If the BIOS doesn't support xHCI, it may switch the devices under EHCI to
allow use of the USB keyboard, mice, and mass storage devices. It's
supposed to remember the value of the port routing registers and switch
them back when the OS attempts to take control of the xHCI host controller,
but we all know not to trust BIOS writers.
Make both the xHCI driver and the EHCI driver attempt to switchover the
ports in their PCI resume functions. We can't guarantee which PCI device
will be resumed first, so this avoids any race conditions. Writing a '1'
to an already set port switchover bit or a '0' to a cleared port switchover
bit should have no effect.
The xHCI PCI configuration registers will be documented in the EDS-level
chipset spec, which is not public yet. I have permission from legal and
the Intel chipset group to release this patch early to allow good Linux
support at product launch. I've tried to document the registers as much
as possible, so please let me know if anything is unclear.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Unsurprisingly, URBs get submitted and completed a lot in the xHCI
driver. If we have to print 10 lines of debug for every URB submitted
or completed, then that can cause the whole system to stay in the
interrupt handler too long, and can cause Missed Service completion
codes for isochronous transfers.
Cut down the debugging in the URB submission and completion paths:
- Don't squawk about successful transfers, only unsuccessful ones.
- Only print the number of bytes transferred if this was a short
transfer.
- Don't print the endpoint index for successful transfers (will add
more debug to failed transfers to show endpoint index there later).
- Stop printing MMIO writes. This debugging shows up when the endpoint
doorbell is rung a to start a transfer (basically for every URB).
- Don't print out the ring enqueue and dequeue pointers
- Stop printing when we're pointing to a link TRB.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Stop printing out the event ring dequeue pointer and status register in
the operational register set. The host will report an OK status 99% of
the time the interrupt handler is called, and usually when it's really
hosed, a host controller won't even call the interrupt handler. So the
line is really useless.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Remove unnecessary debugging from the xHCI driver. We don't need to
know what function we're calling or returning from. Now I know how to
use markup-oops.pl to de-mystify stack dumps of crashes.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
When the xHCI host controller dies, the USB core may attempt to reset the
devices to their default configuration before disconnecting them. This
causes calls into the xHCI bandwidth allocation functions. Don't allow
those functions to submit commands or work on xHCI structures if the host
controller is marked as dying.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
When an URB is cancelled, the xHCI driver issues a Stop Endpoint command
so that it can manipulate the ring and remove the transfer. The xHC
hardware then places a transfer event with the completion code "Stopped"
or "Stopped Invalid" to let the driver know what TD it was in the middle
of processing. This TD and TRB is stored in ep->stopped_td and
ep->stopped_trb. These pointers are also used in handling stalled
endpoints.
By design, the Stop Endpoint command can race with URB completion. By
the time the Stop Endpoint command is handled, the URBs to be cancelled
may have been given back to the driver. Unfortunately, the stopped_td
and stopped_trb pointers were not getting cleared in this case.
The USB core unconditionally tries to reset the toggle bits on any
endpoints when a new alternate interface setting is installed. When the
xHCI driver saw that ep->stopped_td was still set from the Stop Endpoint
command, xhci_reset_endpoint assumed the endpoint was actually stalled,
and attempted to clean up the endpoint rings. This would manifest
itself in a failed Reset Endpoint command and failed Set TR dequeue
Pointer command after a successful Configure Endpoint command. It may
have also been causing driver oops when the stopped_td was accessed.
This patch should be backported to stable kernels since 2.6.31. Before
2.6.33, stopped_td was found in the xhci_endpoint_ring, not the
xhci_virt_ep.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* git://git.kernel.org/pub/scm/linux/kernel/git/brodo/pcmcia-2.6:
pcmcia: Make struct pcmcia_device_id const, sound drivers edition
staging: pcmcia: Convert pcmcia_device_id declarations to const
pcmcia: Convert pcmcia_device_id declarations to const
pcmcia: Make declaration and uses of struct pcmcia_device_id const
pcmcia/sa1100: put sa11x0_pcmcia_hw_init[] to .devinit.data
* 'usb-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6: (205 commits)
USB: EHCI: Remove SPARC_LEON {read,write}_be definitions from ehci.h
USB: UHCI: Support big endian GRUSBHC HC
sparc: add {read,write}*_be routines
USB: UHCI: Add support for big endian descriptors
USB: UHCI: Use ACCESS_ONCE rather than using a full compiler barrier
USB: UHCI: Add support for big endian mmio
usb-storage: Correct adjust_quirks to include latest flags
usb/isp1760: Fix possible unlink problems
usb/isp1760: Move function isp1760_endpoint_disable() within file.
USB: remove remaining usages of hcd->state from usbcore and fix regression
usb: musb: ux500: add configuration and build options for ux500 dma
usb: musb: ux500: add dma glue layer for ux500
usb: musb: ux500: add dma name for ux500
usb: musb: ux500: add ux500 specific code for gadget side
usb: musb: fix compile error
usb-storage: fix up the unusual_realtek device list
USB: gadget: f_audio: Fix invalid dereference of initdata
EHCI: don't rescan interrupt QHs needlessly
OHCI: fix regression caused by nVidia shutdown workaround
USB: OTG: msm: Free VCCCX regulator even if we can't set the voltage
...
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (39 commits)
b43: fix comment typo reqest -> request
Haavard Skinnemoen has left Atmel
cris: typo in mach-fs Makefile
Kconfig: fix copy/paste-ism for dell-wmi-aio driver
doc: timers-howto: fix a typo ("unsgined")
perf: Only include annotate.h once in tools/perf/util/ui/browsers/annotate.c
md, raid5: Fix spelling error in comment ('Ofcourse' --> 'Of course').
treewide: fix a few typos in comments
regulator: change debug statement be consistent with the style of the rest
Revert "arm: mach-u300/gpio: Fix mem_region resource size miscalculations"
audit: acquire creds selectively to reduce atomic op overhead
rtlwifi: don't touch with treewide double semicolon removal
treewide: cleanup continuations and remove logging message whitespace
ath9k_hw: don't touch with treewide double semicolon removal
include/linux/leds-regulator.h: fix syntax in example code
tty: fix typo in descripton of tty_termios_encode_baud_rate
xtensa: remove obsolete BKL kernel option from defconfig
m68k: fix comment typo 'occcured'
arch:Kconfig.locks Remove unused config option.
treewide: remove extra semicolons
...
Commit e66eed651f ("list: remove prefetching from regular list
iterators") removed the include of prefetch.h from list.h, which
uncovered several cases that had apparently relied on that rather
obscure header file dependency.
So this fixes things up a bit, using
grep -L linux/prefetch.h $(git grep -l '[^a-z_]prefetchw*(' -- '*.[ch]')
grep -L 'prefetchw*(' $(git grep -l 'linux/prefetch.h' -- '*.[ch]')
to guide us in finding files that either need <linux/prefetch.h>
inclusion, or have it despite not needing it.
There are more of them around (mostly network drivers), but this gets
many core ones.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
{read,write}l_be are now defined for SPARC and do not need to be
defined for SPARC_LEON in ehci.h. This patch fixes the following
warnings:
CC drivers/usb/host/ehci-hcd.o
In file included from drivers/usb/host/ehci-hcd.c:119:
drivers/usb/host/ehci.h:631:1: warning: "readl_be" redefined
...
drivers/usb/host/ehci-hcd.c:119:
drivers/usb/host/ehci.h:632:1: warning: "writel_be" redefined
...
Signed-off-by: Jan Andersson <jan@gaisler.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch adds support for big endian GRUSBHC UHCI controllers.
The HCD bus glue will probe the register interface to determine
the endianness of the controller.
Tested on GR-LEON4-ITX board which has a controller with little endian
interface and on custom LEON3 board with a BE controller.
Signed-off-by: Jan Andersson <jan@gaisler.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch adds support for universal host controllers that use
big endian descriptors. Support for BE descriptors requires a non-PCI
host controller. For kernels with PCI-only UHCI there should be no
change in behaviour.
This patch tries to replicate the technique used to support BE descriptors
in the EHCI HCD. Parts added to uhci-hcd.h are basically copy'n'paste from
ehci.h.
Signed-off-by: Jan Andersson <jan@gaisler.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1462) updates the special accessor functions defined in
uhci-hcd.h. Rather than using a full compiler barrier, all we really
need is the ACCESS_ONCE() mechanism, because the idea is to force the
compiler to store a fixed copy of a possibly changing value.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch adds support for big endian mmio to the UHCI HCD. Big endian
mmio is supported by adding a flag bit to the UHCI HCD replicating the
solution used in the EHCI HCD.
When adding big endian support this patch also adds a check to see if we
need to support HCs with PCI I/O registers when we support HCs with MMIO.
This patch also adds 'const' to the register access functions' uhci_hcd
argument.
Signed-off-by: Jan Andersson <jan@gaisler.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Use skip map to avoid spurious interrupts from unlinked transfers.
Also changes to urb_dequeue() and endpoint_disable() to avoid
release of spinlock in uncertain state.
Signed-off-by: Arvid Brodin <arvid.brodin@enea.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Preparation for patch #2. The function isp1760_endpoint_disable() does almost
the same thing as urb_dequeue(). In patch #2 I change these to use a common
helper function instead of calling each other - for clarity but also to
avoid releasing the spinlock while in a "questionable" state. It seemed
proper to have these functions close to each other in the code.
Signed-off-by: Arvid Brodin <arvid.brodin@enea.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1467) removes the last usages of hcd->state from
usbcore. We no longer check to see if an interrupt handler finds that
a controller has died; instead we rely on host controller drivers to
make an explicit call to usb_hc_died().
This fixes a regression introduced by commit
9b37596a2e (USB: move usbcore away from
hcd->state). It used to be that when a controller shared an IRQ with
another device and an interrupt arrived while hcd->state was set to
HC_STATE_HALT, the interrupt handler would be skipped. The commit
removed that test; as a result the current code doesn't skip calling
the handler and ends up believing the controller has died, even though
it's only temporarily stopped. The solution is to ignore HC_STATE_HALT
following the handler's return.
As a consequence of this change, several of the host controller
drivers need to be modified. They can no longer implicitly rely on
usbcore realizing that a controller has died because of hcd->state.
The patch adds calls to usb_hc_died() in the appropriate places.
The patch also changes a few of the interrupt handlers. They don't
expect to be called when hcd->state is equal to HC_STATE_HALT, even if
the controller is still alive. Early returns were added to avoid any
confusion.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Manuel Lauss <manuel.lauss@googlemail.com>
CC: Rodolfo Giometti <giometti@linux.it>
CC: Olav Kongas <ok@artecdesign.ee>
CC: <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1466) speeds up processing of ehci-hcd's periodic list.
The existing code will pointlessly rescan an interrupt endpoint queue
each time it encounters the queue's QH in the periodic list, which can
happen quite a few times if the endpoint's period is low. On some
embedded systems, this useless overhead can waste so much time that
the driver falls hopelessly behind and loses events.
The patch introduces a "periodic_stamp" variable, which gets
incremented each time scan_periodic() runs and each time the scan
advances to a new frame. If the corresponding stamp in an interrupt
QH is equal to the current periodic_stamp, we assume the QH has
already been scanned and skip over it. Otherwise we scan the QH as
usual, and if none of its URBs have completed then we store the
current periodic_stamp in the QH's stamp, preventing it from being
scanned again.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1463) fixes a regression caused by commit
3df7169e73 (OHCI: work around for nVidia
shutdown problem).
The original problem encountered by people using NVIDIA chipsets was
that USB devices were not turning off when the system shut down. For
example, the LED on an optical mouse would remain on, draining a
laptop's battery. The problem was caused by a bug in the chipset; an
OHCI controller in the Reset state would continue to drive a bus reset
signal even after system shutdown. The workaround was to put the
controllers into the Suspend state instead.
It turns out that later NVIDIA chipsets do not suffer from this bug.
Instead some have the opposite bug: If a system is shut down while an
OHCI controller is in the Suspend state, USB devices remain powered!
On other systems, shutting down with a Suspended controller causes the
system to reboot immediately. Thus, working around the original bug
on some machines exposes other bugs on other machines.
The best solution seems to be to limit the workaround to OHCI
controllers with a low-numbered PCI product ID. I don't know exactly
at what point NVIDIA changed their chipsets; the value used here is a
guess. So far it was worked out okay for all the people who have
tested it.
This fixes Bugzilla #35032.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Andre "Osku" Schmidt <andre.osku.schmidt@googlemail.com>
Tested-by: Yury Siamashka <yurand2@gmail.com>
CC: <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When the USB core wants to change to an alternate interface setting that
doesn't include an active endpoint, or de-configuring the device, the xHCI
driver needs to issue a Configure Endpoint command to tell the host to
drop some endpoints from the schedule. After the command completes, the
xHCI driver needs to free rings for any endpoints that were dropped.
Unfortunately, the xHCI driver wasn't actually freeing the endpoint rings
for dropped endpoints. The rings would be freed if the endpoint's
information was simply changed (and a new ring was installed), but dropped
endpoints never had their rings freed. This caused errors when the ring
segment DMA pool was freed when the xHCI driver was unloaded:
[ 5582.883995] xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff88003371d000 busy
[ 5582.884002] xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff880033716000 busy
[ 5582.884011] xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff880033455000 busy
[ 5582.884018] xhci_hcd 0000:06:00.0: Freed segment pool
[ 5582.884026] xhci_hcd 0000:06:00.0: Freed device context pool
[ 5582.884033] xhci_hcd 0000:06:00.0: Freed small stream array pool
[ 5582.884038] xhci_hcd 0000:06:00.0: Freed medium stream array pool
[ 5582.884048] xhci_hcd 0000:06:00.0: xhci_stop completed - status = 1
[ 5582.884061] xhci_hcd 0000:06:00.0: USB bus 3 deregistered
[ 5582.884193] xhci_hcd 0000:06:00.0: PCI INT A disabled
Fix this issue and free endpoint rings when their endpoints are
successfully dropped.
This patch should be backported to kernels as old as 2.6.31.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
When an endpoint ring is freed, it is either cached in a per-device ring
cache, or simply freed if the ring cache is full. If the ring was added
to the cache, then virt_dev->num_rings_cached is incremented. The cache
is designed to hold up to 31 endpoint rings, in array indexes 0 to 30.
When the device is freed (when the slot was disabled),
xhci_free_virt_device() is called, it would free the cached rings in
array indexes 0 to virt_dev->num_rings_cached.
Unfortunately, the original code in xhci_free_or_cache_endpoint_ring()
would put the first entry into the ring cache in array index 1, instead of
array index 0. This was caused by the second assignment to rings_cached:
rings_cached = virt_dev->num_rings_cached;
if (rings_cached < XHCI_MAX_RINGS_CACHED) {
virt_dev->num_rings_cached++;
rings_cached = virt_dev->num_rings_cached;
virt_dev->ring_cache[rings_cached] =
virt_dev->eps[ep_index].ring;
This meant that when the device was freed, cached rings with indexes 0 to
N would be freed, and the last cached ring in index N+1 would not be
freed. When the driver was unloaded, this caused interesting messages
like:
xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff880063040000 busy
This should be queued to stable kernels back to 2.6.33.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
Dmitry's patch
dfa49c4ad1 USB: xhci - fix math in xhci_get_endpoint_interval()
introduced a bug. The USB 2.0 spec says that full speed isochronous endpoints'
bInterval must be decoded as an exponent to a power of two (e.g. interval =
2^(bInterval - 1)). Full speed interrupt endpoints, on the other hand, don't
use exponents, and the interval in frames is encoded straight into bInterval.
Dmitry's patch was supposed to fix up the full speed isochronous to parse
bInterval as an exponent, but instead it changed the *interrupt* endpoint
bInterval decoding. The isochronous endpoint encoding was the same.
This caused full speed devices with interrupt endpoints (including mice, hubs,
and USB to ethernet devices) to fail under NEC 0.96 xHCI host controllers:
[ 100.909818] xhci_hcd 0000:06:00.0: add ep 0x83, slot id 1, new drop flags = 0x0, new add flags = 0x99, new slot info = 0x38100000
[ 100.909821] xhci_hcd 0000:06:00.0: xhci_check_bandwidth called for udev ffff88011f0ea000
...
[ 100.910187] xhci_hcd 0000:06:00.0: ERROR: unexpected command completion code 0x11.
[ 100.910190] xhci_hcd 0000:06:00.0: xhci_reset_bandwidth called for udev ffff88011f0ea000
When the interrupt endpoint was added and a Configure Endpoint command was
issued to the host, the host controller would return a very odd error message
(0x11 means "Slot Not Enabled", which isn't true because the slot was enabled).
Probably the host controller was getting very confused with the bad encoding.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Dmitry Torokhov <dtor@vmware.com>
Reported-by: Thomas Lindroth <thomas.lindroth@gmail.com>
Tested-by: Thomas Lindroth <thomas.lindroth@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
There are several functions using same code to get max ports and port array,
this patch moves the common code to a function in order to reuse them easily.
Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The BIOS handoff for the unused EHCI controller on the ExoPC tablet
hangs for 90 seconds on boot. Detect that device, skip negotiation
and force the handoff.
Signed-off-by: Andy Ross <andy.ross@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Factor the handoff code out from quirk_usb_disable_ehci
Signed-off-by: Andy Ross <andy.ross@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When the xHCI driver attempts to cancel a transfer, it issues a Stop
Endpoint command and waits for the host controller to indicate which TRB
it was in the middle of processing. The host will put an event TRB with
completion code COMP_STOP on the event ring if it stops on a control
transfer TRB (or other types of transfer TRBs). The ring handling code
is supposed to set ep->stopped_trb to the TRB that the host stopped on
when this happens.
Unfortunately, there is a long-standing bug in the control transfer
completion code. It doesn't actually check to see if COMP_STOP is set
before attempting to process the transfer based on which part of the
control TD completed. So when we get an event on the data phase of the
control TRB with COMP_STOP set, it thinks it's a normal completion of
the transfer and doesn't set ep->stopped_td or ep->stopped_trb.
When the ring handling code goes on to process the completion of the Stop
Endpoint command, it sees that ep->stopped_trb is not a part of the TD
it's trying to cancel. It thinks the hardware has its enqueue pointer
somewhere further up in the ring, and thinks it's safe to turn the control
TRBs into no-op TRBs. Since the hardware was in the middle of the control
TRBs to be cancelled, the proper software behavior is to issue a Set TR
dequeue pointer command.
It turns out that the NEC host controllers can handle active TRBs being
set to no-op TRBs after a stop endpoint command, but other host
controllers have issues with this out-of-spec software behavior. Fix this
behavior.
This patch should be backported to kernels as far back as 2.6.31, but it
may be a bit challenging, since process_ctrl_td() was introduced in some
refactoring done in 2.6.36, and some endian-safe patches added in 2.6.40
that touch the same lines.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: stable@kernel.org
The __devinit and __devexit macros were added to probe and remove
functions. The macros move the probe and remove functions to the
devinit and devexit sections
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* 'for-usb-next' of git+ssh://master.kernel.org/pub/scm/linux/kernel/git/sarah/xhci:
xHCI 1.0: Max Exit Latency Too Large Error
xHCI 1.0: TT_THINK_TIME set
xHCI 1.0: Block Interrupts for Isoch transfer
xHCI 1.0: Isoch endpoint CErr field set
xHCI 1.0: Control endpoint average TRB length field set
xHCI 1.0: Setup Stage TRB Transfer Type flag
This is a new TRB Completion Code of the xHCI spec 1.0.
Asserted by the Evalute Context Command if the proposed Max Exit Latency would
not allow the periodic endpoints of the Device Slot to be scheduled.
Signed-off-by: Alex He <alex.he@amd.com>
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
xHCI 1.0 spec says the TT Think Time field shall be set to zero if the device
is not a High-speed hub.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Currently an isoc URB is divided into multiple TDs, and every TD will
trigger an interrupt when it's processed. However, software can schedule
multiple TDs at a time, and it only needs an interrupt every URB.
xHCI 1.0 introduces the Block Event Interrupt(BEI) flag which allows Normal
and Isoch Transfer TRBs to place an Event TRB on an Event Ring but not
assert an intrrupt to the host, and the interrupt rate is significantly
reduced and the system performance is improved.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
xHCI 1.0 specification specifies that CErr does not apply to Isoch endpoints
and shall be set to '0' for Isoch endpoints.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
xHCI 1.0 specification indicates that software should set Average TRB Length
to '8' for control endpoints.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Setup Stage Transfer Type field is added to indicate the presence and the
direction of the Data Stage TD, and determines the direction of the Status
Stage TD so the wLength length field should be ignored by the xHC.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch adds support for the UHCI part of the GRLIB GRUSBHC controller
found on some LEON/GRLIB SoCs.
The UHCI HCD previously only supported controllers connected over PCI.
This patch adds support for the first non-PCI UHCI HC. I have tried to
replicate the solution used in ehci-hcd.c.
Tested on GR-LEON4-ITX board (LEON4/GRLIB with GRUSBHC) and x86 with Intel
UHCI HC.
Signed-off-by: Jan Andersson <jan@gaisler.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch is part of a series that extend the UHCI HCD to support
non-PCI host controllers.
This patch also extends the uhci_{read,write}* functions to allow accesses
to registers not mapped into PCI I/O space. This extension also includes
the addition of a void __iomem pointer to the uhci structure.
A new Kconfig option is added to signal that the system has a non-PCI HC.
If this Kconfig option is set, uhci-hcd.c will include generic reset functions
for systems that do not make use of keyboard and mouse legacy support. PCI
controllers will still always use the reset functions from pci-quirks
This patch is followed by a patch that adds bus glue for the first non-PCI
UHCI HC.
Signed-off-by: Jan Andersson <jan@gaisler.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch is part of a series that extend the UHCI HCD to support
non-PCI controllers.
This patch replaces in{b,w,l} and out{b,wl} with calls to local inline
functions. This is done so that the register access functions can be
extended to support register areas not mapped in PCI I/O space.
Signed-off-by: Jan Andersson <jan@gaisler.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch is part of a series that extend the UHCI HCD to support
non-PCI controllers.
This patch moves PCI specific functions to uhci-pci.c and includes
this file in uhci-hcd.c. It also renames the function uhci_init to
uhci_pci_init.
uhci_init/uhci_pci_init is modified so that the port-detection logic
is kept in a new separate function uhci_count_ports() in uhci-hcd.c.
Signed-off-by: Jan Andersson <jan@gaisler.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch is part of a series that extend the UHCI HCD to support
non-PCI host controllers.
This patch fixes the following warnings from checkpatch:
ERROR: switch and case should be at the same indent
+ switch (to_pci_dev(uhci_dev(uhci))->vendor) {
+ default:
[...]
+ case PCI_VENDOR_ID_GENESYS:
[...]
+ case PCI_VENDOR_ID_INTEL:
WARNING: static char array declaration should probably be static const char
+ static char bad_Asus_board[] = "A7V8X";
WARNING: Use DEFINE_PCI_DEVICE_TABLE for struct pci_device_id
+static const struct pci_device_id uhci_pci_ids[] = { {
Signed-off-by: Jan Andersson <jan@gaisler.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch is part of a series that extend the UHCI HCD to support
non-PCI controllers.
This patch changes calls to uhci_reset_hc, uhci_check_and_reset_hc,
configure_hc, resume_detect_interrupts_are_broken and
global_suspend_mode_is_broken so that they are made through pointers
in the uhci hcd struct. This will allow these functions to be replaced
with bus/arch specific functions.
Signed-off-by: Jan Andersson <jan@gaisler.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch is part of a series that extend the UHCI HCD to support
non-PCI host controllers.
uhci-hub.c contained two PCI vendor checks for silicon quirks. Move
these checks into uhci-hcd.c and use bits in uhci_hcd structure to
mark that we need to use the quirks.
This patch is followed by other patches that will remove PCI
dependencies from uhci-hcd.c as well.
Signed-off-by: Jan Andersson <jan@gaisler.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch fixes the checkpatch errors ans warnings listed below:
ERROR: do not use assignment in if condition
WARNING: line over 80 characters
WARNING: braces {} are not necessary for single statement blocks
WARNING: space prohibited between function name and open parenthesis '('
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Remove a stray 'return 0' at the top of the suspend callback,
and move au1xxx_stop_ehc() out of the ehci spinlock since it takes
some time to complete.
Signed-off-by: Manuel Lauss <manuel.lauss@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Saves about 50KB of data.
Old/new size of all objects:
text data bss dec hex filename
563015 80096 130684 773795 bcea3 (TOTALS)
610916 32256 130632 773804 bceac (TOTALS)
Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Kurt Van Dijck <kurt.van.dijck@eia.be> (for drivers/net/can/softing/softing_cs.c)
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
This patch adds support for the GRLIB GRUSBHC EHCI controller from
Aeroflex Gaisler. The controller is typically found on LEON/GRLIB
SoCs.
Tested on GR-LEON4-ITX with with little endian interface and on
LEON3 system on GR-PCI-XC5V development board for big endian
controller.
Signed-off-by: Jan Andersson <jan@gaisler.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The two first HC capability registers (CAPLENGTH and HCIVERSION)
are defined as one 8-bit and one 16-bit register. Most HC
implementations have selected to treat these registers as part
of a 32-bit register, giving the same layout for both big and
small endian systems.
This patch adds a new quirk, big_endian_capbase, to support
controllers with big endian register interfaces that treat
HCIVERSION and CAPLENGTH as individual registers.
Signed-off-by: Jan Andersson <jan@gaisler.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch clears PORT_PLC if xhci_bus_resume() resumes a previous suspended
port, because if a port transition from U3 to U0 state, it will report a
port link state change, and software should clear the corresponding PLC bit.
It also uses hcd->speed to check if a port is a USB2 protocol port.
The patch fixes the issue that USB keyboard can not wakeup system from
hibernation.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The reset value of the uSOF cycle period is incorrect. Set it to
60,000 bits. Without this, several commercial USB flash memory
devices and hubs fail to work properly.
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The UCTL clock initialization will cause the ehci and ohci blocks to
become inoperable if the clocks are reinitialized.
Check to see if the clocks have already been initialized.
Also use a mutex to protect the clock initialization code so that
there can be no attempt to use the clocks before they are fully
configured.
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This fixes a bug in my previous (2.6.38) patch series which caused
urb->status value to be wrong after unlink (broke usbtest 11, 12).
Signed-off-by: Arvid Brodin <arvid.brodin@enea.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* 'for-usb-next' of git+ssh://master.kernel.org/pub/scm/linux/kernel/git/sarah/xhci:
xhci 1.0: Set transfer burst last packet count field.
xhci 1.0: Set transfer burst count field.
xhci 1.0: Update TD size field format.
xhci 1.0: Only interrupt on short packet for IN EPs.
xhci: Remove sparse warning about cmd_status.
usbcore: warm reset USB3 port in SS.Inactive state
usbcore: Refine USB3.0 device suspend and resume
xHCI: report USB3.0 portstatus comply with USB3.0 specification
xHCI: Set link state support
xHCI: Clear link state change support
xHCI: warm reset support
usb/ch9: use proper endianess for wBytesPerInterval
xhci: Remove recursive call to xhci_handle_event
xhci: Add an assertion to check for virt_dev=0 bug.
xhci: Add rmb() between reading event validity & event data access.
xhci: Make xHCI driver endian-safe
This patch replaces the code that handles qtds. Intead of directly allocating
chip mem and chip slot, enqueue the transfer in a list of queue heads. Use
a centralized function enqueue_qtds() to prioritize and enqueue transfers.
This removes all of the interrupt context BUG() calls when out of chip
mem or transfer slots. It also makes it possible to efficiently use the
dual-port mem on the chip for double-buffered transfers, which improve
transfer times to/from/between usb sticks by about 40 % on my HW.
With this patch it should also be possible to handle qtd scheduling outside
of the interrupt handler, for significantly improved kernel latency. I have
not implemented this since there are some locking issues which I haven't
had time to look at.
Signed-off-by: Arvid Brodin <arvid.brodin@enea.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This fixes a bug in my previous (2.6.38) patch series which caused
urb->status value to be wrong after unlink (broke usbtest 11, 12).
Signed-off-by: Arvid Brodin <arvid.brodin@enea.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Since we always set the OR flag for each transfer, we can just as well set all
these bits to 1 at init and be done with it. Also, HcBufferStatus can be set
at init as per the ISP1761 datasheet page 47 with no loss of performance.
Signed-off-by: Arvid Brodin <arvid.brodin@enea.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This collects urb enqueue code that was spread out all over the place
into a couple of more readable functions.
Signed-off-by: Arvid Brodin <arvid.brodin@enea.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This removes the "qh is 0" printout. qh == NULL if the urb has
been unlinked, so this condition is normal.
Signed-off-by: Arvid Brodin <arvid.brodin@enea.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The xHCI 1.0 specification defines a new isochronous TRB field, called
transfer burst last packet count (TBLPC). This field defines the number
of packets in the last "burst" of packets in a TD. Only SuperSpeed
endpoints can handle more than one burst, so this is set to the number for
packets in a TD for all non-SuperSpeed devices (minus one, since the field
is zero based).
This patch should have no effect on host controllers that don't advertise
the xHCI 1.0 (0x100) version number in their hci_version field.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The xHCI 1.0 specification adds a new field to the fourth dword in an
isochronous TRB: the transfer burst count (TBC). This field is only
non-zero for SuperSpeed devices. Each SS endpoint sets the bMaxBurst
field in the SuperSpeed endpoint companion descriptor, which indicates how
many max-packet-sized "bursts" it can handle in one service interval. The
device driver may choose to burst less max packet sized chunks each
service interval (which is defined by one TD). The xHCI driver indicates
to the host controller how many bursts it needs to schedule through the
transfer burst count field.
This patch will only effect xHCI hosts that advertise 1.0 support (0x100)
in the HCI version field of their capabilities register.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The xHCI 1.0 specification changes the format of the TD size field in
Normal and Isochronous TRBs. The field in control TRBs is still set to
reserved zero. Instead of representing the number of bytes left to
transfer in the TD (including the current TRB's buffer), it now represents
the number of packets left to transfer (*not* including this TRB).
See section 4.11.2.4 of the xHCI 1.0 specification for details. The math
is basically copied straight from there.
Create a new function, xhci_v1_0_td_remainder(), that should be called for
all xHCI 1.0 host controllers. The field location and maximum value is
still the same, so reuse the old function, xhci_td_remainder(), to handle
the bit shifting.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
It doesn't make sense to set the interrupt on short packet (TRB_ISP) flag
for TRBs queued to endpoints that only receive packets from the host
controller (i.e. OUT endpoints). Packets can only be short when they are
sent from a USB device. Plus, the xHCI 1.0 specification forbids setting
the flag for anything but IN endpoints.
While we're at it, remove some of my snide remarks about the inefficiency
of event data TRBs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Sparse complains about the arguments to xhci_evaluate_context_result() and
xhci_configure_endpoint_result():
CHECK drivers/usb/host/xhci.c
drivers/usb/host/xhci.c:1647:53: warning: incorrect type in argument 3 (different signedness)
drivers/usb/host/xhci.c:1647:53: expected int *cmd_status
drivers/usb/host/xhci.c:1647:53: got unsigned int [usertype] *[assigned] cmd_status
drivers/usb/host/xhci.c:1648:50: warning: incorrect type in argument 3 (different signedness)
drivers/usb/host/xhci.c:1648:50: expected int *cmd_status
drivers/usb/host/xhci.c:1648:50: got unsigned int [usertype] *[assigned] cmd_status
The command status is taken from the command completion event TRB, and
will always be a positive number. Change the signature of
xhci_evaluate_context_result() and xhci_configure_endpoint_result() to
take a u32 for cmd_status.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
In the past, we use USB2.0 request to suspend and resume a USB3.0 device.
Actually, USB3.0 hub does not support Set/Clear PORT_SUSPEND request,
instead, it uses Set PORT_LINK_STATE request. This patch makes USB3.0 device
suspend/resume comply with USB3.0 specification.
This patch fixes the issue that USB3.0 device can not be suspended when
connected to a USB3.0 external hub.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
USB3.0 specification has different wPortStatus and wPortChange definitions
from USB2.0 specification. Since USB3 root hub and USB2 root hub are split
now and USB3 hub only has USB3 protocol ports, we should modify the
portstatus and portchange report of USB3 ports to comply with USB3.0
specification.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch adds support for Set Port Feature(PORT_LINK_STATE) request.
The most significant byte (bits 15..8) of the wIndex field specifies
the U state the host software wants to put the link connected to the
port into. This request is only valid when the PORT_ENABLE bit is set
and the PORT_LINK_STATE should not be above value '5' (Rx.Detect).
This request will be later used to replace the set/clear suspend USB3
protocol ports in hub driver.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch adds support for Clear Port Feature(C_PORT_LINK_STATE)
request from usbcore.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch adds warm reset support to xhci hub control.
It handles Set Port Feature(BH_PORT_RESET) and Clear Port Feature
(C_BH_PORT_RESET) request from usbcore.
Note warm reset is called BH reset some places in USB3.0 specification.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
while going through Tatyana's changes for the gadget framework I noticed
that this type is not defined as __le16.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Make the caller loop while there are events to handle, instead.
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
During a "plug-unplug" stress test on an NEC xHCI card, a null pointer
dereference was observed. xhci_address_device() dereferenced a null
virt_dev (possibly an erroneous udev->slot_id?); this patch adds a WARN_ON &
message to aid debug if it can be recreated.
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
On weakly-ordered systems, the reading of an event's content must occur
after reading the event's validity.
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch changes the struct members defining access to xHCI device-visible
memory to use __le32/__le64 where appropriate, and then adds swaps where
required. Checked with sparse that all accesses are correct.
MMIO accesses use readl/writel so already are performed LE, but prototypes
now reflect this with __le*.
There were a couple of (debug) instances of DMA pointers being truncated to
32bits which have been fixed too.
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
in case of ehci phy mode; regulator of phy
should be enabled before initializing the
usbhs core driver.
Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
Tested-by: Steve Calfee <stevecalfee@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Commit b02d0ed677 ('xhci: Change
hcd_priv into a pointer') added calls to kzalloc() and kfree() in
xhci-pci.c. On most architectures <linux/slab.h> is indirectly
included, but on some it is not.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>,
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tegra USB1 port needs to issue Port Reset twice internally, otherwise it
fails to enumerate devices attached to it
Signed-off-by: Jim Lin <jilin@nvidia.com>
Signed-off-by: Olof Johansson <olofj@chromium.org>
[ squash two patches into one and minor style cleanups ]
Signed-off-by: Mike Rapoport <mike@compulab.co.il>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch uses the resource_size help function instead of
manually calculating the resource size. It can reduce the chance
of introducing off-by-one errors.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The __devinit and __devexit macros were added to probe and remove
functions. The macros move the probe and remove functions to the
devinit and devexit sections.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Using C line continuation inside format strings is error prone.
Clean up the unintended whitespace introduced by misuse of \.
Neaten correctly used line continations as well for consistency.
drivers/scsi/arcmsr/arcmsr_hba.c has these errors as well,
but arcmsr needs a lot more work and the driver should likely be
moved to staging instead.
Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This reverts commit 5808544690.
To quote Richard:
I don't think this should be mainlined. It was a
misunderstanding on my part. If you see all the other hdc
drivers in the same location, they all do the same thing (i.e.
clear the interrupt status first, then do the work) that
"glitch" I think I saw was actually two back-to-back
interrupts.
Sebastian (the original author of isp1760) explained it to me a
few days after my submission.
sorry for the confusion
Cc: Richard Retanubun <RichardRetanubun@ruggedcom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The Atheros AR71XX/AR7240 SoCs have a built-in OHCI controller.
This patch adds the necessary glue code to make the generic OHCI
driver usable for them.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Imre Kaloz <kaloz@openwrt.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
A Synopsys USB core used in various SoCs has a bug which might cause
that the host controller not issuing ping.
When software uses the Doorbell mechanism to remove queue heads, the
host controller still has references to the removed queue head even
after indicating an Interrupt on Async Advance. This happens if the last
executed queue head's Next Link queue head is removed.
Consequences of the defect:
The Host controller fetches the removed queue head, using memory that
would otherwise be deallocated.This results in incorrect transactions on
both the USB and system memory. This may result in undefined behavior.
Workarounds:
1) If no queue head is active (no Status field's Active bit is set)
after removing the queue heads, the software can write one of the valid
queue head addresses to the ASYNCLISTADDR register and deallocate the
removed queue head's memory after 2 microframes.
If one or more of the queue heads is active (the Active bit is set in
the Status field) after removing the queue heads, the software can delay
memory deallocation after time X, where X is the time required for the
Host Controller to go through all the queue heads once. X varies with
the number of queue heads and the time required to process periodic
transactions: if more periodic transactions must be performed, the Host
Controller has less time to process asynchronous transaction processing.
2) Do not use the Doorbell mechanism to remove the queue heads. Disable
the Asynchronous Schedule Enable bit instead.
The bug has been discussed on the linux-usb-devel mailing-list
four years ago, the original thread can be found here:
http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg45345.html
This patch implements the first workaround as suggested by David Brownell.
The built-in USB host controller of the Atheros AR7130/AR7141/AR7161 SoCs
requires this to work properly.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The Atheros AR71XX/AR91XX SoCs have a built-in EHCI controller.
This patch adds the necessary glue code to make the generic EHCI
driver usable for them.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Imre Kaloz <kaloz@openwrt.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch disable the optional PM feature inside the Hudson3 platform under
the following conditions:
1. If an isochronous device is connected to xHCI port and is active;
2. Optional PM feature that powers down the internal Bus PLL when the link is
in low power state is enabled.
The PM feature needs to be disabled to eliminate PLL startup delays when the
link comes out of low power state. The performance of DMA data transfer could
be impacted if system delay were encountered and in addition to the PLL start
up delays. Disabling the PM would leave room for unpredictable system delays
in order to guarantee uninterrupted data transfer to isochronous audio or
video stream devices that require time sensitive information. If data in an
audio/video stream was interrupted then erratic audio or video performance
may be encountered.
AMD PLL quirk is already implemented in OHCI/EHCI driver. After moving the
quirk code to pci-quirks.c and export them, xHCI driver can call it directly
without having the quirk implementation in itself.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
On a resume, when the power is lost during hibernate, the USB core will
call hub_reset_resume for the xHCI USB 2.0 roothub, but not for the USB
3.0 roothub:
[ 164.748310] usb usb1: root hub lost power or was reset
[ 164.748353] usb usb2: root hub lost power or was reset
[ 164.748487] usb usb3: root hub lost power or was reset
[ 164.748488] xhci_hcd 0000:01:00.0: Stop HCD
...
[ 164.870039] hub 4-0:1.0: hub_resume
...
[ 164.870054] hub 3-0:1.0: hub_reset_resume
This causes issues later, because the USB core assumes the USB 3.0 hub
attached to the USB 3.0 roothub is still active. It attempts to queue a
control URB for the external hub, which fails because all the device
slot contexts were released when the USB 3.0 roothub lost power:
[ 164.980044] hub 4-1:1.0: hub_resume
[ 164.980047] xhci_hcd 0000:01:00.0: Get port status returned 0x10101
[ 164.980049] xHCI xhci_urb_enqueue called with unaddressed device
[ 164.980053] hub 3-0:1.0: port 1: status 0101 change 0001
[ 164.980056] hub 4-1:1.0: hub_port_status failed (err = -22)
[ 164.980060] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 32'hffffc90008948440, 32'h202e1, 4'hf);
[ 164.980062] xHCI xhci_urb_enqueue called with unaddressed device
[ 164.980066] xhci_hcd 0000:01:00.0: clear port connect change, actual port 0 status = 0x2e1
[ 164.980069] hub 4-1:1.0: hub_port_status failed (err = -22)
[ 164.980072] xhci_hcd 0000:01:00.0: get port status, actual port 1 status = 0x2a0
[ 164.980074] xHCI xhci_urb_enqueue called with unaddressed device
[ 164.980077] xhci_hcd 0000:01:00.0: Get port status returned 0x100
[ 164.980079] hub 4-1:1.0: hub_port_status failed (err = -22)
[ 164.980082] xHCI xhci_urb_enqueue called with unaddressed device
[ 164.980085] hub 4-1:1.0: hub_port_status failed (err = -22)
[ 164.980088] hub 4-1:1.0: port 4: status 0000 change 0000
[ 164.980091] xHCI xhci_urb_enqueue called with unaddressed device
[ 164.980094] hub 4-1:1.0: activate --> -22
[ 164.980113] xHCI xhci_urb_enqueue called with unaddressed device
[ 164.980117] hub 4-1:1.0: hub_port_status failed (err = -22)
[ 164.980119] xHCI xhci_urb_enqueue called with unaddressed device
[ 164.980123] hub 4-1:1.0: can't resume port 4, status -22
[ 164.980126] hub 4-1:1.0: port 4 status ffff.ffff after resume, -22
[ 164.980129] usb 4-1.4: can't resume, status -22
[ 164.980131] hub 4-1:1.0: logical disconnect on port 4
This causes issues when a USB 3.0 hard drive is attached to the external
USB 3.0 hub when the system is hibernated:
[ 6249.849653] sd 8:0:0:0: [sdb] Unhandled error code
[ 6249.849659] sd 8:0:0:0: [sdb] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
[ 6249.849663] sd 8:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 2a 08 00 00 02 00
[ 6249.849671] end_request: I/O error, dev sdb, sector 10760
Make sure to inform the USB core that *both* xHCI roothubs lost power.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Sarah Sharp
Maarten Lankhorst
Matt Evans
Linus Torvalds
Jan Andersson
Alan Stern
Arvid Brodin
huajun li
Andy Ross
Jingoo Han
Greg Kroah-Hartman
Justin P. Mattock
Alex He
Andiry Xu
Manuel Lauss
Joe Perches
David Daney
Anatolij Gustschin
Sebastian Andrzej Siewior
Keshava Munegowda
Ben Hutchings
Jim Lin
Gabor Juhos