When a host controller gives a bad event TRB, we should print out the
contents of the TRB as a warning so that users don't have to recompile
their kernel to get information about what went wrong.  Also, print out
the event ring if they have xHCI debugging turned on, since previous
events can often explain what happened before the bad TRB occurred.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

With devices that can need up to 128 segments (with 64 TRBs per
segment), we can't afford to print out the entire endpoint ring every
time an URB is canceled.  Instead, print the offset of the TRB, along
with device pathname and endpoint number.

Only print DMA addresses, since virtual addresses of internal structures
are not useful.  Change the cancellation code to be more clear about
what steps of the cancellation it is in the process of doing (queueing
the request, handling the stop endpoint command, turning the TDs into
no-ops, or moving the dequeue pointers).
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Debuggers only really care what the xHCI driver sets the ring dequeue
pointer to, so make the driver stop babbling about the memory addresses
of internal ring structures.  This makes wading through the output of
allocating and freeing 256 stream rings much easier by reducing the
number of output lines per ring from 9 to 1.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The code for toggling the cycle bits when the ring wraps around has
worked for years.  The print statement alone is not enough to indicate
there's something wrong with that code.  Now that full transfer tracing
has been ripped out, the print statement or lack thereof won't help
without context of where the enqueue pointer is.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Users can trace the submission of URBs through USBmon, so it makes no
sense to have duplicate debugging in the xHCI driver.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Remove verbose debugging about scatter-gather lists, as we haven't had
an issue with scatter gather list math for about a year now.  The
debugging didn't help before, and just clutters up the log file when
trying to debug other issues.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

xHCI host controllers may not be capable of MSI, but they should be able
to be used in legacy PCI interrupt mode.  Similarly, some xHCI host
controllers will have MSI support but not MSI-X support.  Lower the
dmesg log level from an error to debug.  The message won't appear unless
CONFIG_USB_XHCI_HCD_DEBUGGING is turned on.

If we need to find out whether the device can support MSI or MSI-X and
it's not being enabled by the driver, it's easy to ask the user to run
lspci.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Getting a short packet or a babble error is usually a recoverable error,
so stop scaring users with warnings in dmesg when xHCI debugging is turned
off.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The xHCI driver will create an xhci_hcd structure, not an ehci_hci
structure.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

This patch adds support for EHCI compliant HSUSB Host controller found
on Marvell Socs.

It fits both OTG and SPH controller on marvell Socs, including
PXA9xx/MMP2/MMP3/MGx.
Signed-off-by: NNeil Zhang <zhangwm@marvell.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

After commit c430131a (Support
controllers with big endian capability regs), HC_LENGTH takes
two arguments. This patch fixes following compilation error:

In file included from drivers/usb/host/ehci-hcd.c:1323:
drivers/usb/host/ehci-pxa168.c:302:54: error: macro "HC_LENGTH" requires 2 arguments, but only 1 given
In file included from drivers/usb/host/ehci-hcd.c:1323:
drivers/usb/host/ehci-pxa168.c: In function 'ehci_pxa168_drv_probe':
drivers/usb/host/ehci-pxa168.c:302: error: 'HC_LENGTH' undeclared (first use in this function)
drivers/usb/host/ehci-pxa168.c:302: error: (Each undeclared identifier is reported only once
drivers/usb/host/ehci-pxa168.c:302: error: for each function it appears in.)
Signed-off-by: NTanmay Upadhyay <tanmay.upadhyay@einfochips.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add a new field num_mapped_sgs to struct urb so that we have a place to
store the number of mapped entries and can also retain the original
value of entries in num_sgs.  Previously, usb_hcd_map_urb_for_dma()
would overwrite this with the number of mapped entries, which would
break dma_unmap_sg() because it requires the original number of entries.

This fixes warnings like the following when using USB storage devices:
 ------------[ cut here ]------------
 WARNING: at lib/dma-debug.c:902 check_unmap+0x4e4/0x695()
 ehci_hcd 0000:00:12.2: DMA-API: device driver frees DMA sg list with different entry count [map count=4] [unmap count=1]
 Modules linked in: ohci_hcd ehci_hcd
 Pid: 0, comm: kworker/0:1 Not tainted 3.2.0-rc2+ #319
 Call Trace:
  <IRQ>  [<ffffffff81036d3b>] warn_slowpath_common+0x80/0x98
  [<ffffffff81036de7>] warn_slowpath_fmt+0x41/0x43
  [<ffffffff811fa5ae>] check_unmap+0x4e4/0x695
  [<ffffffff8105e92c>] ? trace_hardirqs_off+0xd/0xf
  [<ffffffff8147208b>] ? _raw_spin_unlock_irqrestore+0x33/0x50
  [<ffffffff811fa84a>] debug_dma_unmap_sg+0xeb/0x117
  [<ffffffff8137b02f>] usb_hcd_unmap_urb_for_dma+0x71/0x188
  [<ffffffff8137b166>] unmap_urb_for_dma+0x20/0x22
  [<ffffffff8137b1c5>] usb_hcd_giveback_urb+0x5d/0xc0
  [<ffffffffa0000d02>] ehci_urb_done+0xf7/0x10c [ehci_hcd]
  [<ffffffffa0001140>] qh_completions+0x429/0x4bd [ehci_hcd]
  [<ffffffffa000340a>] ehci_work+0x95/0x9c0 [ehci_hcd]
  ...
 ---[ end trace f29ac88a5a48c580 ]---
 Mapped at:
  [<ffffffff811faac4>] debug_dma_map_sg+0x45/0x139
  [<ffffffff8137bc0b>] usb_hcd_map_urb_for_dma+0x22e/0x478
  [<ffffffff8137c494>] usb_hcd_submit_urb+0x63f/0x6fa
  [<ffffffff8137d01c>] usb_submit_urb+0x2c7/0x2de
  [<ffffffff8137dcd4>] usb_sg_wait+0x55/0x161
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Data read direct from device tree properties will be in the device
tree's native endianness (i.e., big-endian).

This patch uses of_property_read_u32() to read the bus-width
property in host byte order instead.
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NPawel Moll <pawel.moll@arm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

PS3 EHCI HC errata fix 244.  The SCC EHCI HC will not correctly perform QH
reads that occur near or span a micro-frame boundry.  This is due to a problem
in the Nak Count Reload Control logic (EHCI Specification 1.0 Section 4.9.1).

The work-around for this problem is for the HC driver to set I=1 (inactive) for
QHs with H=1 (list head).
Signed-off-by: NGeoff Levand <geoff@infradead.org>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>

The EHCI USB controller of the Cell Super Companion Chip used in the PS3
will stop the root hub after all root hub ports are suspended.  When in
this condition the ehci-hcd handshake routine will return -ETIMEDOUT and
the USB runtime suspend sequence will fail.  The STS_HLT bit will not be
set, so inspection of the frame index is used to test for the condition.

Add a new routine handshake_for_broken_root_hub() that is called after
an unsuccessful -ETIMEDOUT handshake.  On PS3 handshake_for_broken_root_hub()
will test for the condition, and if found will return success to allow the
USB suspend to complete.  For all other platforms
handshake_for_broken_root_hub() will return -ETIMEDOUT
Signed-off-by: NGeoff Levand <geoff@infradead.org>
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>

PS3 EHCI HC errata fix 316 - The PS3 EHCI HC will reset its
internal INSNREGXX setup regs back to the chip default values
on Host Controller Reset (CMD_RESET) or Light Host Controller
Reset (CMD_LRESET).  The work-around for this is for the HC
driver to re-initialise these regs when ever the HC is reset.

Adds a new helper routine ps3_ehci_setup_insnreg() which is
called from ps3_ehci_hc_reset().
Signed-off-by: NGeoff Levand <geoff@infradead.org>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>

Remove the ehci_reset() call done in the ehci_run() routine of the
USB EHCI host controller driver and add an ehci_reset() call to the
probe processing of all EHCI platform drivers that do not already call
ehci_reset().

The call to ehci_reset() from ehci_run() was problematic for several
platform drivers, and unnecessary for others.  This change moves the
decision to call ehci_reset() at driver startup to the platform
driver code.
Signed-off-by: NGeoff Levand <geoff@infradead.org>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>

This reverts commit df711fc9.

The commit added a reset-on-resume quirk because the NEC chipset stopped
responding to commands about 30 minutes after a system resume from
suspend.  We thought it was a chipset issue, but it turns out that the
xHCI driver was zeroing out the link TRB after a successful context
restore during resume.  The host controller would fall off the command
ring sometime later, causing it to not respond to new commands.

The link TRB issue has been fixed with commit
158886cd "xHCI: fix bug in
xhci_clear_command_ring()", so revert the reset-on-resume quirk, as it's
not necessary.

Commit df711fc9 was marked for stable
trees back to 2.6.37, but according to my mail, it has not made it into
Linus' tree or the stable trees yet.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: NJulian Sikorski <belegdol@gmail.com>
Cc: Andiry Xu <andiry.xu@amd.com>

When system enters suspend, xHCI driver clears command ring by writing zero
to all the TRBs. However, this also writes zero to the Link TRB, and the ring
is mangled. This may cause driver accesses wrong memory address and the
result is unpredicted.

When clear the command ring, keep the last Link TRB intact, only clear its
cycle bit. This should fix the "command ring full" issue reported by Oliver
Neukum.

This should be backported to stable kernels as old as 2.6.37, since the
commit 89821320 "xhci: Fix command ring replay after resume" is merged.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: NOliver Neukum <oneukum@suse.de>

This patch adds power management support such as suspend and resume
functions.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Fix a regression that was introduced by commit
811c926c (USB: EHCI: fix HUB TT scheduling
issue with iso transfer).

We detect an error if next == start, but this means uframe 0 can't be allocated
anymore for iso transfer...
Reported-by: NSander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: NMatthieu CASTET <castet.matthieu@free.fr>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Julian Sikorski reports NEC uPD720200 does not work stable after suspend
and resume. Re-initialize the host in xhci_resume().

This should be backported to stable kernels as old as 2.6.37.  The
kernel will need to include
commit c877b3b2
"xhci: Add reset on resume quirk for asrock p67 host"
for this patch to work.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Reported-by: NJulian Sikorski <belegdol@gmail.com>
Tested-by: NJulian Sikorski <belegdol@gmail.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

This patch converts the drivers in drivers/usb/* to use the
module_platform_driver() macro which makes the code smaller and a bit
simpler.

Cc: Felipe Balbi <balbi@ti.com>
Cc: Li Yang <leoli@freescale.com>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Lucas De Marchi <lucas.demarchi@profusion.mobi>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Acked-by: NPeter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This fixes a memory leak reported by Catalin Marinas:

schedule_ptds() is called from isp1760_irq() and removes the qh from the
controlqhs queue but ep->hcpriv still points to the qh and therefore it is not
freed.

Shortly after this, the isp1760_endpoint_disable() function sets ep->hcpriv to
NULL and calls schedule_ptds() but since the corresponding qh is no longer in
the queue, it is simply forgotten and reported by kmemleak.

With this patch, the qh is always freed at endpoint_disable, instead, and the
corresponding entry removed from the queue head list.

While I was at it, I also replaced the lines in isp1760_endpoint_disable()
that removed remaining qtds from the qh with a WARN_ON check for non-empty qh,
in line with earlier comments from Alan Stern (linux-usb list, 2011-07-20).
Signed-off-by: NArvid Brodin <arvid.brodin@enea.com>
Tested-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Small code refactoring to ease the real fix in patch #2.
Signed-off-by: NArvid Brodin <arvid.brodin@enea.com>
Tested-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

xhci-hub used some numerical values for initialisation of root hub
descriptors. #define values are addded in usb 2.0 hub specification
file and these values are used for root hub characteristics
initialisation.

Also use some #defines in places where magic numbers are being used.
Signed-off-by: NAman Deep <amandeep3986@gmail.com>
Acked-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

qset->qh.link is an __le64 field and we should be using cpu_to_le64()
to fill it.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Problems with NVIDIA's OHCI host controllers persist.  After looking
carefully through the spec, I finally realized that when a controller
is reset it then automatically goes into a SUSPEND state in which it
is completely quiescent (no DMA and no IRQs) and from which it will
not awaken until the system puts it into the OPERATIONAL state.

Therefore there's no need to worry about controllers being in the
RESET state for extended periods, or remaining in the OPERATIONAL
state during system shutdown.  The proper action for device
initialization is to put the controller into the RESET state (if it's
not there already) and then to issue a software reset.  Similarly, the
proper action for device shutdown is simply to do a software reset.

This patch (as1499) implements such an approach.  It simplifies
initialization and shutdown, and allows the NVIDIA shutdown-quirk code
to be removed.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NAndre "Osku" Schmidt <andre.osku.schmidt@googlemail.com>
Tested-by: NArno Augustin <Arno.Augustin@web.de>
Cc: stable <stable@vger.kernel.org> [after tested in 3.2 for a while]
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Fix compile error, HC_LENGTH now takes two parameters and ehci
needs to be passed as the first parameter.
Signed-off-by: NJayachandran C <jayachandranc@netlogicmicro.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Use CONFIG_CPU_XLR instead of CONFIG_NLM_XLR, the NLM_XLR config
option is redundant and is being removed.
Signed-off-by: NJayachandran C <jayachandranc@netlogicmicro.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1500) removes all uses of the objectionable hcd->state
variable from the ohci-hcd family of drivers.  It is replaced by a
private ohci->rh_state field, just as in uhci-hcd and ehci-hcd.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Use resource_size function on resource object
instead of explicit computation.

The semantic patch that makes this change is available
in scripts/coccinelle/api/resource_size.cocci.
Signed-off-by: NThomas Meyer <thomas@m3y3r.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Data Buffer Error as per spec section 4.15.1.1.2
results when there is Underrun or Overrun condition.

This error is considered non-fatal and never gets reported.
Its a very good indication on things going wrong at system level,
like running memory at much slower speed.

This is a good error to flag allowing system level corrections.

An issue was found with OMAP4460 board where DDR had to be run
at full speed and this logging helped.
Signed-off-by: NVikram Pandita <vikram.pandita@ti.com>
Reviewed-by: NMarek Vasut <marek.vasut@gmail.com>
Signed-off-by: NVikram Pandita <vikram.pandita@ti.com>
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The HCD_FLAG_SAW_IRQ flag was introduced in order to catch IRQ routing
errors: If an URB was unlinked and the host controller hadn't gotten
any IRQs, it seemed likely that the IRQs were directed to the wrong
vector.

This warning hasn't come up in many years, as far as I know; interrupt
routing now seems to be well under control.  Therefore there's no
reason to keep the flag around any more.  This patch (as1495) finally
removes it.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Remove unnecessary headers from the file.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

in commit aa6e52a3 we introduce the support of overcurrent notification
but the set and get of the power without checking if the gpio is valid or not
Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The current TT scheduling doesn't allow to play and then record on a
full-speed device connected to a high speed hub.

The IN iso stream can only start on the first uframe (0-2 for a 165 us)
because of CSPLIT transactions.
For the OUT iso stream there no such restriction. uframe 0-5 are possible.

The idea of this patch is that the first uframe are precious (for IN TT iso
stream) and we should allocate the last uframes first if possible.

For that we reverse the order of uframe allocation (last uframe first).

Here an example :

hid interrupt stream
----------------------------------------------------------------------
uframe                |  0  |  1  |  2  |  3  |  4  |  5  |  6  |  7  |
----------------------------------------------------------------------
max_tt_usecs          | 125 | 125 | 125 | 125 | 125 | 125 | 30  |  0  |
----------------------------------------------------------------------
used usecs on a frame | 13  |  0  |  0  |  0  |  0  |  0  |  0  |  0  |
----------------------------------------------------------------------

iso OUT stream
----------------------------------------------------------------------
uframe                |  0  |  1  |  2  |  3  |  4  |  5  |  6  |  7  |
----------------------------------------------------------------------
max_tt_usecs          | 125 | 125 | 125 | 125 | 125 | 125 | 30  |  0  |
----------------------------------------------------------------------
used usecs on a frame | 13  | 125 |  39 |  0  |  0  |  0  |  0  |  0  |
----------------------------------------------------------------------

There no place for iso IN stream  (uframe 0-2 are used) and we got "cannot
submit datapipe for urb 0, error -28: not enough bandwidth" error.

With the patch this become.

iso OUT stream
----------------------------------------------------------------------
uframe                |  0  |  1  |  2  |  3  |  4  |  5  |  6  |  7  |
----------------------------------------------------------------------
max_tt_usecs          | 125 | 125 | 125 | 125 | 125 | 125 | 30  |  0  |
----------------------------------------------------------------------
used usecs on a frame |  13 |  0  |  0  |  0  | 125 |  39 |  0  |  0  |
----------------------------------------------------------------------

iso IN stream
----------------------------------------------------------------------
uframe                |  0  |  1  |  2  |  3  |  4  |  5  |  6  |  7  |
----------------------------------------------------------------------
max_tt_usecs          | 125 | 125 | 125 | 125 | 125 | 125 | 30  |  0  |
----------------------------------------------------------------------
used usecs on a frame |  13 |  0  | 125 | 40  | 125 |  39 |  0  |  0  |
----------------------------------------------------------------------
Signed-off-by: NMatthieu Castet <matthieu.castet@parrot.com>
Signed-off-by: NThomas Poussevin <thomas.poussevin@parrot.com>
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1494) fixes a problem in xhci-hcd's resume routine.
When the controller is runtime-resumed, this can only mean that one of
the two root hubs has made a wakeup request and therefore needs to be
resumed as well.  Rather than try to determine which root hub requires
attention (which might be difficult in the case where a new
non-SuperSpeed device has been plugged in), the patch simply resumes
both root hubs.

Without this change, there is a race: The controller might be put back
to sleep before it can activate its IRQ line, and the wakeup condition
might never get handled.

The patch also simplifies the logic in xhci_resume a little, combining
some repeated flag settings into a single pair of statements.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Tested-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1491) works around a bug in GCC-3.4.6, which is still
supposed to be supported.  The number of microseconds in the udelay()
call in quirk_usb_disable_ehci() is fixed at 100, but the compiler
doesn't understand this and generates a link-time error.  So we
replace the otherwise unused variable "delta" with a simple constant
100.  This same pattern is already used in other delay loops in that
source file.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NKonrad Rzepecki <krzepecki@dentonet.pl>
Tested-by: NKonrad Rzepecki <krzepecki@dentonet.pl>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Matt's AsMedia xHCI host controller was responding with a Context Error
to an address device command after a configured device reset.  Some
sequence of events leads both the slot and endpoint zero add flags
cleared to zero, which the AsMedia host doesn't like:

[  223.701839] xhci_hcd 0000:03:00.0: Slot ID 1 Input Context:
[  223.701841] xhci_hcd 0000:03:00.0: @ffff880137b25000 (virt) @ffffc000 (dma) 0x000000 - drop flags
[  223.701843] xhci_hcd 0000:03:00.0: @ffff880137b25004 (virt) @ffffc004 (dma) 0x000000 - add flags
[  223.701846] xhci_hcd 0000:03:00.0: @ffff880137b25008 (virt) @ffffc008 (dma) 0x000000 - rsvd2[0]
[  223.701848] xhci_hcd 0000:03:00.0: @ffff880137b2500c (virt) @ffffc00c (dma) 0x000000 - rsvd2[1]
[  223.701850] xhci_hcd 0000:03:00.0: @ffff880137b25010 (virt) @ffffc010 (dma) 0x000000 - rsvd2[2]
[  223.701852] xhci_hcd 0000:03:00.0: @ffff880137b25014 (virt) @ffffc014 (dma) 0x000000 - rsvd2[3]
[  223.701854] xhci_hcd 0000:03:00.0: @ffff880137b25018 (virt) @ffffc018 (dma) 0x000000 - rsvd2[4]
[  223.701857] xhci_hcd 0000:03:00.0: @ffff880137b2501c (virt) @ffffc01c (dma) 0x000000 - rsvd2[5]
[  223.701858] xhci_hcd 0000:03:00.0: Slot Context:
[  223.701860] xhci_hcd 0000:03:00.0: @ffff880137b25020 (virt) @ffffc020 (dma) 0x8400000 - dev_info
[  223.701862] xhci_hcd 0000:03:00.0: @ffff880137b25024 (virt) @ffffc024 (dma) 0x010000 - dev_info2
[  223.701864] xhci_hcd 0000:03:00.0: @ffff880137b25028 (virt) @ffffc028 (dma) 0x000000 - tt_info
[  223.701866] xhci_hcd 0000:03:00.0: @ffff880137b2502c (virt) @ffffc02c (dma) 0x000000 - dev_state
[  223.701869] xhci_hcd 0000:03:00.0: @ffff880137b25030 (virt) @ffffc030 (dma) 0x000000 - rsvd[0]
[  223.701871] xhci_hcd 0000:03:00.0: @ffff880137b25034 (virt) @ffffc034 (dma) 0x000000 - rsvd[1]
[  223.701873] xhci_hcd 0000:03:00.0: @ffff880137b25038 (virt) @ffffc038 (dma) 0x000000 - rsvd[2]
[  223.701875] xhci_hcd 0000:03:00.0: @ffff880137b2503c (virt) @ffffc03c (dma) 0x000000 - rsvd[3]
[  223.701877] xhci_hcd 0000:03:00.0: Endpoint 00 Context:
[  223.701879] xhci_hcd 0000:03:00.0: @ffff880137b25040 (virt) @ffffc040 (dma) 0x000000 - ep_info
[  223.701881] xhci_hcd 0000:03:00.0: @ffff880137b25044 (virt) @ffffc044 (dma) 0x2000026 - ep_info2
[  223.701883] xhci_hcd 0000:03:00.0: @ffff880137b25048 (virt) @ffffc048 (dma) 0xffffe8e0 - deq
[  223.701885] xhci_hcd 0000:03:00.0: @ffff880137b25050 (virt) @ffffc050 (dma) 0x000000 - tx_info
[  223.701887] xhci_hcd 0000:03:00.0: @ffff880137b25054 (virt) @ffffc054 (dma) 0x000000 - rsvd[0]
[  223.701889] xhci_hcd 0000:03:00.0: @ffff880137b25058 (virt) @ffffc058 (dma) 0x000000 - rsvd[1]
[  223.701892] xhci_hcd 0000:03:00.0: @ffff880137b2505c (virt) @ffffc05c (dma) 0x000000 - rsvd[2]
...
[  223.701927] xhci_hcd 0000:03:00.0: // Ding dong!
[  223.701992] xhci_hcd 0000:03:00.0: Setup ERROR: address device command for slot 1.

The xHCI spec says that both flags must be set to one for the Address
Device command.  When the device is first enumerated,
xhci_setup_addressable_virt_dev() does set those flags.  However, when
the device is addressed after it has been reset in the configured state,
xhci_setup_addressable_virt_dev() is not called, and
xhci_copy_ep0_dequeue_into_input_ctx() is called instead.  That function
relies on the flags being set up by previous commands, which apparently
isn't a good assumption.

Move the setting of the flags into the common parent function.

This should be queued for stable kernels as old as 2.6.35, since that
was the first introduction of xhci_copy_ep0_dequeue_into_input_ctx.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: NMatt <mdm@iinet.net.au>
Cc: stable@vger.kernel.org