Fixes generated by 'codespell' and manually reviewed.
Signed-off-by: NLucas De Marchi <lucas.demarchi@profusion.mobi>

Scripted with coccinelle.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Fix potential null-pointer exception on disconnect introduced by commit
11ea859d (USB: additional power savings
for cdc-acm devices that support remote wakeup).

Only access acm->dev after making sure it is non-null in control urb
completion handler.

Cc: stable <stable@kernel.org>
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Must check return value of tty_port_tty_get.

Cc: stable <stable@kernel.org>
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Prevent read urbs from being resubmitted from tasklet after port close.

The receive tasklet was not disabled on port close, which could lead to
corruption of receive lists on consecutive port open. In particular,
read urbs could be re-submitted before port open, added to free list in
open, and then added a second time to the free list in the completion
handler.

cdc-acm.c: Entering acm_tty_open.
cdc-acm.c: acm_control_msg: rq: 0x22 val: 0x3 len: 0x0 result: 0
cdc-acm.c: Entering acm_rx_tasklet
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da280, rcv 0xf57fbc24, buf 0xf57fbd64
cdc-acm.c: set line: 115200 0 0 8
cdc-acm.c: acm_control_msg: rq: 0x20 val: 0x0 len: 0x7 result: 7
cdc-acm.c: acm_tty_close
cdc-acm.c: acm_port_down
cdc-acm.c: acm_control_msg: rq: 0x22 val: 0x0 len: 0x0 result: 0
cdc-acm.c: acm_ctrl_irq - urb shutting down with status: -2
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da300, rcv 0xf57fbc10, buf 0xf57fbd50
cdc-acm.c: Entering acm_read_bulk with status -2
cdc_acm 4-1:1.1: Aborting, acm not ready
cdc-acm.c: Entering acm_read_bulk with status -2
cdc_acm 4-1:1.1: Aborting, acm not ready
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da380, rcv 0xf57fbbfc, buf 0xf57fbd3c
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da400, rcv 0xf57fbbe8, buf 0xf57fbd28
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da480, rcv 0xf57fbbd4, buf 0xf57fbd14
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da900, rcv 0xf57fbbc0, buf 0xf57fbd00
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da980, rcv 0xf57fbbac, buf 0xf57fbcec
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50daa00, rcv 0xf57fbb98, buf 0xf57fbcd8
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50daa80, rcv 0xf57fbb84, buf 0xf57fbcc4
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dab00, rcv 0xf57fbb70, buf 0xf57fbcb0
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dab80, rcv 0xf57fbb5c, buf 0xf57fbc9c
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dac00, rcv 0xf57fbb48, buf 0xf57fbc88
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dac80, rcv 0xf57fbb34, buf 0xf57fbc74
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dad00, rcv 0xf57fbb20, buf 0xf57fbc60
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dad80, rcv 0xf57fbb0c, buf 0xf57fbc4c
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da880, rcv 0xf57fbaf8, buf 0xf57fbc38
cdc-acm.c: Entering acm_tty_open.
cdc-acm.c: acm_control_msg: rq: 0x22 val: 0x3 len: 0x0 result: 0
cdc-acm.c: Entering acm_rx_tasklet
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da280, rcv 0xf57fbc24, buf 0xf57fbd64
cdc-acm.c: Entering acm_tty_write to write 3 bytes,
cdc-acm.c: Get 3 bytes...
cdc-acm.c: acm_write_start susp_count: 0
cdc-acm.c: Entering acm_read_bulk with status 0
------------[ cut here ]------------
WARNING: at /home/johan/src/linux/linux-2.6/lib/list_debug.c:57 list_del+0x10c/0x120()
Hardware name: Vostro 1520
list_del corruption. next->prev should be f57fbc10, but was f57fbaf8
Modules linked in: cdc_acm
Pid: 3, comm: ksoftirqd/0 Not tainted 2.6.37+ #39
Call Trace:
 [<c103c7e2>] warn_slowpath_common+0x72/0xa0
 [<c11dd8ac>] ? list_del+0x10c/0x120
 [<c11dd8ac>] ? list_del+0x10c/0x120
 [<c103c8b3>] warn_slowpath_fmt+0x33/0x40
 [<c11dd8ac>] list_del+0x10c/0x120
 [<f8051dbf>] acm_rx_tasklet+0xef/0x3e0 [cdc_acm]
 [<c135465d>] ? net_rps_action_and_irq_enable+0x6d/0x80
 [<c1042bb6>] tasklet_action+0xe6/0x140
 [<c104342f>] __do_softirq+0xaf/0x210
 [<c1043380>] ? __do_softirq+0x0/0x210
 <IRQ>  [<c1042c9a>] ? run_ksoftirqd+0x8a/0x1c0
 [<c1042c10>] ? run_ksoftirqd+0x0/0x1c0
 [<c105ac24>] ? kthread+0x74/0x80
 [<c105abb0>] ? kthread+0x0/0x80
 [<c100337a>] ? kernel_thread_helper+0x6/0x10
---[ end trace efd9a11434f0082e ]---
------------[ cut here ]------------
WARNING: at /home/johan/src/linux/linux-2.6/lib/list_debug.c:57 list_del+0x10c/0x120()
Hardware name: Vostro 1520
list_del corruption. next->prev should be f57fbd50, but was f57fbdb0
Modules linked in: cdc_acm
Pid: 3, comm: ksoftirqd/0 Tainted: G        W   2.6.37+ #39
Call Trace:
 [<c103c7e2>] warn_slowpath_common+0x72/0xa0
 [<c11dd8ac>] ? list_del+0x10c/0x120
 [<c11dd8ac>] ? list_del+0x10c/0x120
 [<c103c8b3>] warn_slowpath_fmt+0x33/0x40
 [<c11dd8ac>] list_del+0x10c/0x120
 [<f8051dd6>] acm_rx_tasklet+0x106/0x3e0 [cdc_acm]
 [<c135465d>] ? net_rps_action_and_irq_enable+0x6d/0x80
 [<c1042bb6>] tasklet_action+0xe6/0x140
 [<c104342f>] __do_softirq+0xaf/0x210
 [<c1043380>] ? __do_softirq+0x0/0x210
 <IRQ>  [<c1042c9a>] ? run_ksoftirqd+0x8a/0x1c0
 [<c1042c10>] ? run_ksoftirqd+0x0/0x1c0
 [<c105ac24>] ? kthread+0x74/0x80
 [<c105abb0>] ? kthread+0x0/0x80
 [<c100337a>] ? kernel_thread_helper+0x6/0x10
---[ end trace efd9a11434f0082f ]---
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da300, rcv 0xf57fbc10, buf 0xf57fbd50
cdc-acm.c: disconnected from network
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da380, rcv 0xf57fbbfc, buf 0xf57fbd3c
cdc-acm.c: Entering acm_rx_tasklet
------------[ cut here ]------------
WARNING: at /home/johan/src/linux/linux-2.6/lib/list_debug.c:48 list_del+0xd5/0x120()
Hardware name: Vostro 1520
list_del corruption, next is LIST_POISON1 (00100100)
Modules linked in: cdc_acm
Pid: 3, comm: ksoftirqd/0 Tainted: G        W   2.6.37+ #39
Call Trace:
 [<c103c7e2>] warn_slowpath_common+0x72/0xa0
 [<c11dd875>] ? list_del+0xd5/0x120
 [<c11dd875>] ? list_del+0xd5/0x120
 [<c103c8b3>] warn_slowpath_fmt+0x33/0x40
 [<c11dd875>] list_del+0xd5/0x120
 [<f8051fac>] acm_rx_tasklet+0x2dc/0x3e0 [cdc_acm]
 [<c106dbab>] ? trace_hardirqs_on+0xb/0x10
 [<c1042b30>] ? tasklet_action+0x60/0x140
 [<c1042bb6>] tasklet_action+0xe6/0x140
 [<c104342f>] __do_softirq+0xaf/0x210
 [<c1043380>] ? __do_softirq+0x0/0x210
 <IRQ>  [<c1042c9a>] ? run_ksoftirqd+0x8a/0x1c0
 [<c1042c10>] ? run_ksoftirqd+0x0/0x1c0
 [<c105ac24>] ? kthread+0x74/0x80
 [<c105abb0>] ? kthread+0x0/0x80
 [<c100337a>] ? kernel_thread_helper+0x6/0x10
---[ end trace efd9a11434f00830 ]---
BUG: unable to handle kernel paging request at 00200200
IP: [<c11dd7bd>] list_del+0x1d/0x120
*pde = 00000000
Oops: 0000 [#1] PREEMPT SMP
last sysfs file: /sys/devices/pci0000:00/0000:00:1a.1/usb4/4-1/4-1:1.0/tty/ttyACM0/uevent
Modules linked in: cdc_acm
Pid: 3, comm: ksoftirqd/0 Tainted: G        W   2.6.37+ #39 0T816J/Vostro 1520
EIP: 0060:[<c11dd7bd>] EFLAGS: 00010046 CPU: 0
EIP is at list_del+0x1d/0x120
EAX: f57fbd3c EBX: f57fb800 ECX: ffff8000 EDX: 00200200
ESI: f57fbe90 EDI: f57fbd3c EBP: f600bf54 ESP: f600bf3c
 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process ksoftirqd/0 (pid: 3, ti=f600a000 task=f60791c0 task.ti=f6082000)
Stack:
 c1527e84 00000030 c1527e54 00100100 f57fb800 f57fbd3c f600bf98 f8051fac
 f8053104 f8052b94 f600bf6c c106dbab f600bf80 00000286 f60791c0 c1042b30
 f57fbda8 f57f5800 f57fbdb0 f57fbd80 f57fbe7c c1656b04 00000000 f600bfb0
Call Trace:
 [<f8051fac>] ? acm_rx_tasklet+0x2dc/0x3e0 [cdc_acm]
 [<c106dbab>] ? trace_hardirqs_on+0xb/0x10
 [<c1042b30>] ? tasklet_action+0x60/0x140
 [<c1042bb6>] ? tasklet_action+0xe6/0x140
 [<c104342f>] ? __do_softirq+0xaf/0x210
 [<c1043380>] ? __do_softirq+0x0/0x210
 <IRQ>
 [<c1042c9a>] ? run_ksoftirqd+0x8a/0x1c0
 [<c1042c10>] ? run_ksoftirqd+0x0/0x1c0
 [<c105ac24>] ? kthread+0x74/0x80
 [<c105abb0>] ? kthread+0x0/0x80
 [<c100337a>] ? kernel_thread_helper+0x6/0x10
Code: ff 48 14 e9 57 ff ff ff 90 90 90 90 90 90 55 89 e5 83 ec 18 81 38 00 01 10 00 0f 84 9c 00 00 00 8b 50 04 81 fa 00 02 20 00 74 33 <8b> 12 39 d0 75 5c 8b 10 8b 4a 04 39 c8 0f 85 b5 00 00 00 8b 48
EIP: [<c11dd7bd>] list_del+0x1d/0x120 SS:ESP 0068:f600bf3c
CR2: 0000000000200200
---[ end trace efd9a11434f00831 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Pid: 3, comm: ksoftirqd/0 Tainted: G      D W   2.6.37+ #39
Call Trace:
 [<c13fede1>] ? printk+0x1d/0x24
 [<c13fecce>] panic+0x66/0x15c
 [<c10067df>] oops_end+0x8f/0x90
 [<c1025476>] no_context+0xc6/0x160
 [<c10255a8>] __bad_area_nosemaphore+0x98/0x140
 [<c103cf68>] ? release_console_sem+0x1d8/0x210
 [<c1025667>] bad_area_nosemaphore+0x17/0x20
 [<c1025a49>] do_page_fault+0x279/0x420
 [<c1006a8f>] ? show_trace+0x1f/0x30
 [<c13fede1>] ? printk+0x1d/0x24
 [<c10257d0>] ? do_page_fault+0x0/0x420
 [<c140333b>] error_code+0x5f/0x64
 [<c103007b>] ? select_task_rq_fair+0x37b/0x6a0
 [<c10257d0>] ? do_page_fault+0x0/0x420
 [<c11dd7bd>] ? list_del+0x1d/0x120
 [<f8051fac>] acm_rx_tasklet+0x2dc/0x3e0 [cdc_acm]
 [<c106dbab>] ? trace_hardirqs_on+0xb/0x10
 [<c1042b30>] ? tasklet_action+0x60/0x140
 [<c1042bb6>] tasklet_action+0xe6/0x140
 [<c104342f>] __do_softirq+0xaf/0x210
 [<c1043380>] ? __do_softirq+0x0/0x210
 <IRQ>  [<c1042c9a>] ? run_ksoftirqd+0x8a/0x1c0
 [<c1042c10>] ? run_ksoftirqd+0x0/0x1c0
 [<c105ac24>] ? kthread+0x74/0x80
 [<c105abb0>] ? kthread+0x0/0x80
 [<c100337a>] ? kernel_thread_helper+0x6/0x10
panic occurred, switching back to text console
------------[ cut here ]------------

Cc: stable <stable@kernel.org>
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

In the WDM class driver a disconnect event leads to calls to
usb_free_coherent to put back two USB DMA buffers allocated earlier.
The call to usb_free_coherent uses a different size parameter
(desc->wMaxCommand) than the corresponding call to usb_alloc_coherent
(desc->bMaxPacketSize0).

When a disconnect event occurs, this leads to 'bad dma' complaints
from usb core because the USB DMA buffer is being pushed back to the
'buffer-2048' pool from which it has not been allocated.

This patch against the most recent linux-2.6 kernel ensures that the
parameters used by usb_alloc_coherent & usb_free_coherent calls in
cdc-wdm.c match.
Signed-off-by: NRobert Lukassen <robert.lukassen@tomtom.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The pm usage counter must be accessed with the proper wrappers
to allow compilation under all configurations.
Signed-off-by: NOliver Neukum <oneukum@suse.de>
Reported-by: NEric Dumazet <eric.dumazet@gmail.com>
Reported-by: NTao Ma <boyu.mt@taobao.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

My testprog do a lot of bitbang - after hours i got following warning and my machine lockups:
WARNING: at /build/buildd/linux-2.6.38/lib/kref.c:34
After debugging uss720 driver i discovered that the completion callback was called before
usb_submit_urb returns. The callback frees the request structure that is krefed on return by
usb_submit_urb.
Signed-off-by: NPeter Holik <peter@holik.at>
Acked-by: NThomas Sailer <t.sailer@alumni.ethz.ch>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The common code has a "get" in the middle, but each implementation
does not have it.

Cc: stable@kernel.org
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Cc: stable@kernel.org
Signed-off-by: NBob Liu <lliubbo@gmail.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The modularization of the Blackfin driver set the name to "musb-blackfin"
in all the boards, but "musb-bfin" in the driver itself.  Since the driver
file name uses "blackfin", change the driver to "musb-blackfin".  This is
also easier as it's only one file to change.

Cc: stable@kernel.org
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

There was conflict while merging 2 patches. Enabling vbus code
is wrongly moved to error check if loop.

This is a fix to resolve the merge issue.
Signed-off-by: NHema HK <hemahk@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1453) fixes a long-standing bug in the ehci-hcd driver.

There is no need to set the Halt bit in the overlay region for an
unlinked or blocked QH.  Contrary to what the comment says, setting
the Halt bit does not cause the QH to be patched later; that decision
(made in qh_refresh()) depends only on whether the QH is currently
pointing to a valid qTD.  Likewise, setting the Halt bit does not
prevent completions from activating the QH while it is "stopped"; they
are prevented by the fact that qh_completions() temporarily changes
qh->qh_state to QH_STATE_COMPLETING.

On the other hand, there are circumstances in which the QH will be
reactivated _without_ being patched; this happens after an URB beyond
the head of the queue is unlinked.  Setting the Halt bit will then
cause the hardware to see the QH with both the Active and Halt bits
set, an invalid combination that will prevent the queue from
advancing and may even crash some controllers.

Apparently the only reason this hasn't been reported before is that
unlinking URBs from the middle of a running queue is quite uncommon.
However Test 17, recently added to the usbtest driver, does exactly
this, and it confirms the presence of the bug.

In short, there is no reason to set the Halt bit for an unlinked or
blocked QH, and there is a very good reason not to set it.  Therefore
the code that sets it is removed.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NAndiry Xu <andiry.xu@amd.com>
CC: David Brownell <david-b@pacbell.net>
CC: <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

When `echo Y > /sys/module/usbcore/parameters/usbfs_snoop` and
usb_control_msg() returns error, a lot of kernel memory is dumped to dmesg
until unhandled kernel paging request occurs.
Signed-off-by: NMichal Sojka <sojkam1@fel.cvut.cz>
Cc: stable@kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This silences warnings such as

drivers/video/tmiofb.c: In function 'tmiofb_hw_init':
drivers/video/tmiofb.c:270: warning: initialization discards qualifiers from pointer target type

These were added by me in commit 2a79bb1d.
Signed-off-by: NAndres Salomon <dilinger@queued.net>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

No need to explicitly set the cell's platform_data/data_size.

Modify clients to use mfd_get_cell helper function instead of
accessing platform_data directly.
Signed-off-by: NAndres Salomon <dilinger@queued.net>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

There may be multiple ways of controlling the backlight on a given
machine.  Allow drivers to expose the type of interface they are
providing, making it possible for userspace to make appropriate policy
decisions.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: David Airlie <airlied@linux.ie>
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

USB defines usb_device_type pointing to usb_device_pm_ops that
provides system-wide PM callbacks only and usb_bus_type pointing to
usb_bus_pm_ops that provides runtime PM callbacks only.  However,
the USB runtime PM callbacks may be defined in usb_device_pm_ops
which makes it possible to drop usb_bus_pm_ops and will allow us
to consolidate the handling of subsystems by the PM core code.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>

Stop handling gpio-vbus internally. All boards that depended on this
functionality have been converted to use gpio-vbus tranceiver. All
new boards can use it right from the start. Drop unused code.
Signed-off-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

After redefining CONFIG_PM to depend on (CONFIG_PM_SLEEP ||
CONFIG_PM_RUNTIME) the CONFIG_PM_OPS option is redundant and can be
replaced with CONFIG_PM.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

A subsequent patch will modify device_set_wakeup_capable() in such
a way that it will call functions which may sleep and therefore it
shouldn't be called under spinlocks.  In preparation to that, modify
usb_set_device_state() to avoid calling device_set_wakeup_capable()
under device_state_lock.
Tested-by: NMinchan Kim <minchan.kim@gmail.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>

Use the Mult and bMaxBurst values from the endpoint companion
descriptor to calculate the max length of an isoc transfer.

Add USB_SS_MULT macro to access Mult field of bmAttributes, at
Sarah's suggestion.

This patch should be queued for the 2.6.36 and 2.6.37 stable trees, since
those were the first kernels to have isochronous support for SuperSpeed
devices.
Signed-off-by: NPaul Zimmerman <paulz@synopsys.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org

Use XOR to invert the cycle bit, instead of a more complicated
calculation.  Eliminate a check for the link TRB type in find_trb_seg().
We know that there will always be a link TRB at the end of a segment, so
xhci_segment->trbs[TRBS_PER_SEGMENT - 1] will always have a link TRB type.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: NTakashi Iwai <tiwai@suse.de>

When an endpoint stalls, we need to update the xHCI host's internal
dequeue pointer to move it past the stalled transfer.  This includes
updating the cycle bit (TRB ownership bit) if we have moved the dequeue
pointer past a link TRB with the toggle cycle bit set.

When we're trying to find the new dequeue segment, find_trb_seg() is
supposed to keep track of whether we've passed any link TRBs with the
toggle cycle bit set.  However, this while loop's body

	while (cur_seg->trbs > trb ||
			&cur_seg->trbs[TRBS_PER_SEGMENT - 1] < trb) {

Will never get executed if the ring only contains one segment.
find_trb_seg() will return immediately, without updating the new cycle
bit.  Since find_trb_seg() has no idea where in the segment the TD that
stalled was, make the caller, xhci_find_new_dequeue_state(), check for
this special case and update the cycle bit accordingly.

This patch should be queued to kernels all the way back to 2.6.31.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: NTakashi Iwai <tiwai@suse.de>
Cc: stable@kernel.org

When an endpoint stalls, the xHCI driver must move the endpoint ring's
dequeue pointer past the stalled transfer.  To do that, the driver issues
a Set TR Dequeue Pointer command, which will complete some time later.

Takashi was having issues with USB 1.1 audio devices that stalled, and his
analysis of the code was that the old code would not update the xHCI
driver's ring dequeue pointer after the command completes.  However, the
dequeue pointer is set in xhci_find_new_dequeue_state(), just before the
set command is issued to the hardware.

Setting the dequeue pointer before the Set TR Dequeue Pointer command
completes is a dangerous thing to do, since the xHCI hardware can fail the
command.  Instead, store the new dequeue pointer in the xhci_virt_ep
structure, and update the ring's dequeue pointer when the Set TR dequeue
pointer command completes.

While we're at it, make sure we can't queue another Set TR Dequeue Command
while the first one is still being processed.  This just won't work with
the internal xHCI state code.  I'm still not sure if this is the right
thing to do, since we might have a case where a driver queues multiple
URBs to a control ring, one of the URBs Stalls, and then the driver tries
to cancel the second URB.  There may be a race condition there where the
xHCI driver might try to issue multiple Set TR Dequeue Pointer commands,
but I would have to think very hard about how the Stop Endpoint and
cancellation code works.  Keep the fix simple until when/if we run into
that case.

This patch should be queued to kernels all the way back to 2.6.31.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: NTakashi Iwai <tiwai@suse.de>
Cc: stable@kernel.org

USB 3.0 devices have a slightly different suspend sequence than USB
2.0/1.1 devices.  There isn't support for USB 3.0 device suspend yet, so
make khubd leave autosuspend disabled for USB 3.0 hubs.  Make sure that
USB 3.0 roothubs still have autosuspend enabled, since that path in the
xHCI driver works fine.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

USB_PORT_STAT_SUPER_SPEED is a made up symbol that the USB core used to
track whether USB ports had a SuperSpeed device attached.  This is a
linux-internal symbol that was used when SuperSpeed and non-SuperSpeed
devices would show up under the same xHCI roothub.  This particular
port status is never returned by external USB 3.0 hubs.  (Instead they
have a USB_PORT_STAT_SPEED_5GBPS that uses a completely different speed
mask.)

Now that the xHCI driver registers two roothubs, USB 3.0 devices will only
show up under USB 3.0 hubs.  Rip out USB_PORT_STAT_SUPER_SPEED and replace
it with calls to hub_is_superspeed().
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

When the xHCI host controller is halted, it won't respond to commands
placed on the command ring.  So if an URB is cancelled after the first
roothub is deallocated, it will try to place a stop endpoint command on
the command ring, which will fail.  The command watchdog timer will fire
after five seconds, and the host controller will be marked as dying, and
all URBs will be completed.

Add a flag to the xHCI's internal state variable for when the host
controller is halted.  Immediately return the canceled URB if the host
controller is halted.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Make sure the HCD_FLAG_HW_ACCESSIBLE flag is mirrored by both roothubs,
since it refers to whether the shared hardware is accessible.  Make sure
each bus is marked as suspended by setting usb_hcd->state to
HC_STATE_SUSPENDED when the PCI host controller is resumed.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

When a host controller has lost power during a suspend, we must
reinitialize it.  Now that the xHCI host has two roothubs, xhci_run() and
xhci_stop() expect to be called with both usb_hcd structures.  Be sure
that the re-initialization code in xhci_resume() mirrors the process the
USB PCI probe function uses.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Return early in the roothub control and status functions if the xHCI host
controller is not electrically present in the system (register reads
return all "fs").  This issue only shows up when the xHCI driver registers
two roothubs and the host controller is removed from the system.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The USB core allocates a USB 2.0 roothub descriptor that has room for 31
(USB_MAXCHILDREN) ports' worth of DeviceRemovable and PortPwrCtrlMask
fields.  Limit the number of USB 2.0 roothub ports accordingly.  I don't
expect to run into this limitation ever, but this prevents a buffer
overflow issue in the roothub descriptor filling code.

Similarly, a USB 3.0 hub can only have 15 downstream ports, so limit the
USB 3.0 roothub to 15 USB 3.0 ports.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Return the correct xHCI roothub descriptor, based on whether the roothub
is marked as USB 3.0 or USB 2.0 in usb_hcd->bcdUSB.  Fill in
DeviceRemovable for the USB 2.0 and USB 3.0 roothub descriptors, using the
Device Removable bit in the port status and control registers.  xHCI is
the first host controller to actually properly set these bits (other hosts
say all devices are removable).

When userspace asks for a USB 2.0-style hub descriptor for the USB 3.0
roothub, stall the endpoint.  This is what real external USB 3.0 hubs do,
and we don't want to return a descriptor that userspace didn't ask for.

The USB core is already fixed to always ask for USB 3.0-style hub
descriptors.  Only usbfs (typically lsusb) will ask for the USB 2.0-style
hub descriptors.  This has already been fixed in usbutils version 0.91,
but the kernel needs to deal with older usbutils versions.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

This patch changes the xHCI driver to allocate two roothubs.  This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers.  This is a rather large patch, but it
can't be broken up, or it would break git-bisect.

Make the xHCI driver register its own PCI probe function.  This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub.  This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.

Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub.  This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.

The reset method will also mark the xHCI USB2 roothub as having an
integrated TT.  Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT.  We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.

Other details:
-------------

The roothub emulation code is changed to return the correct number of
ports for the two roothubs.  For the USB 3.0 roothub, it only reports the
USB 3.0 ports.  For the USB 2.0 roothub, it reports all the LS/FS/HS
ports.  The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.

The code for initializing a new device context must be changed to set the
proper roothub port number.  Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub.  Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.

The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.

The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.

There's also changes to the driver initialization and shutdown paths:

 1. Make sure that the xhci_hcd pointer is shared across the two
    usb_hcd structures.  The xhci_hcd pointer is allocated and the
    registers are mapped in when xhci_pci_setup() is called with the
    primary HCD.  When xhci_pci_setup() is called with the non-primary
    HCD, the xhci_hcd pointer is stored.

 2. Make sure to set the sg_tablesize for both usb_hcd structures.  Set
    the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
    DMA.  (The PCI DMA mask is set from the primary HCD further down in
    the xhci_pci_setup() function.)

 3. Ensure that the host controller doesn't start kicking khubd in
    response to port status changes before both usb_hcd structures are
    registered.  xhci_run() only starts the xHC running once it has been
    called with the non-primary roothub.  Similarly, the xhci_stop()
    function only halts the host controller when it is called with the
    non-primary HCD.  Then on the second call, it resets and cleans up the
    MSI-X irqs.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

xhci_find_slot_id_by_port() tries to map the port index to the slot ID for
the USB device.  In the future, there will be two xHCI roothubs, and their
port indices will overlap.  Therefore, xhci_find_slot_id_by_port() will
need to use information in the roothub's usb_hcd structure to map the port
index and roothub speed to the right slot ID.

Add a new parameter to xhci_find_slot_id_by_port(), in order to pass in
the roothub's usb_hcd structure.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

There are several variables in the xhci_hcd structure that are related to
bus suspend and resume state.  There are a couple different port status
arrays that are accessed by port index.  Move those variables into a
separate structure, xhci_bus_state.  Stash that structure in xhci_hcd.

When we have two roothhubs that can be suspended and resumed separately,
we can have two xhci_bus_states, and index into the port arrays in each
structure with the fake roothub port index (not the real hardware port
index).
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

In the upcoming patches, the roothub emulation code will need to return
port status and port change buffers based on whether they are called with
the xHCI USB 2.0 or USB 3.0 roothub.  To facilitate that, make the roothub
code index into an array of port addresses with wIndex, rather than
calculating the address using the offset and the address of the PORTSC
registers.  Later we can set the port array to be the array of USB 3.0
port addresses, or the USB 2.0 port addresses, depending on the roothub
passed in.

Create a temporary (statically sized) port array and fill it in with both
USB 3.0 and USB 2.0 port addresses.  This is inefficient to do for every
roothub call, but this is needed for git bisect compatibility.  The
temporary port array will be deleted in a subsequent patch.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The hcd->flags are in a sorry state.  Some of them are clearly specific to
the particular roothub (HCD_POLL_RH, HCD_POLL_PENDING, and
HCD_WAKEUP_PENDING), but some flags are related to PCI device state
(HCD_HW_ACCESSIBLE and HCD_SAW_IRQ).  This is an issue when one PCI device
can have two roothubs that share the same IRQ line and hardware.

Make sure to set HCD_FLAG_SAW_IRQ for both roothubs when an interrupt is
serviced, or an URB is unlinked without an interrupt.  (We can't tell if
the host actually serviced an interrupt for a particular bus, but we can
tell it serviced some interrupt.)

HCD_HW_ACCESSIBLE is set once by usb_add_hcd(), which is set for both
roothubs as they are added, so it doesn't need to be modified.
HCD_POLL_RH and HCD_POLL_PENDING are only checked by the USB core, and
they are never set by the xHCI driver, since the roothub never needs to be
polled.

The usb_hcd's state field is a similar mess.  Sometimes the state applies
to the underlying hardware: HC_STATE_HALT, HC_STATE_RUNNING, and
HC_STATE_QUIESCING.  But sometimes the state refers to the roothub state:
HC_STATE_RESUMING and HC_STATE_SUSPENDED.

Alan Stern recently made the USB core not rely on the hcd->state variable.
Internally, the xHCI driver still checks for HC_STATE_SUSPENDED, so leave
that code in.  Remove all references to HC_STATE_HALT, since the xHCI
driver only sets and doesn't test those variables.  We still have to set
HC_STATE_RUNNING, since Alan's patch has a bug that means the roothub
won't get registered if we don't set that.

Alan's patch made the USB core check a different variable when trying to
determine whether to suspend a roothub.  The xHCI host has a split
roothub, where two buses are registered for one PCI device.  Each bus in
the xHCI split roothub can be suspended separately, but both buses must be
suspended before the PCI device can be suspended.  Therefore, make sure
that the USB core checks HCD_RH_RUNNING() for both roothubs before
suspending the PCI host.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Introduce the notion of a PCI device that may be associated with more than
one USB host controller driver (struct usb_hcd).  This patch is the start
of the work to separate the xHCI host controller into two roothubs: a USB
3.0 roothub with SuperSpeed-only ports, and a USB 2.0 roothub with
HS/FS/LS ports.

One usb_hcd structure is designated to be the "primary HCD", and a pointer
is added to the usb_hcd structure to keep track of that.  A new function
call, usb_hcd_is_primary_hcd() is added to check whether the USB hcd is
marked as the primary HCD (or if it is not part of a roothub pair).  To
allow the USB core and xHCI driver to access either roothub in a pair, a
"shared_hcd" pointer is added to the usb_hcd structure.

Add a new function, usb_create_shared_hcd(), that does roothub allocation
for paired roothubs.  It will act just like usb_create_hcd() did if the
primary_hcd pointer argument is NULL.  If it is passed a non-NULL
primary_hcd pointer, it sets usb_hcd->shared_hcd and usb_hcd->primary_hcd
fields.  It will also skip the bandwidth_mutex allocation, and set the
secondary hcd's bandwidth_mutex pointer to the primary HCD's mutex.

IRQs are only allocated once for the primary roothub.

Introduce a new usb_hcd driver flag that indicates the host controller
driver wants to create two roothubs.  If the HCD_SHARED flag is set, then
the USB core PCI probe methods will allocate a second roothub, and make
sure that second roothub gets freed during rmmod and in initialization
error paths.

When usb_hc_died() is called with the primary HCD, make sure that any
roothubs that share that host controller are also marked as being dead.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The xHCI driver essentially has both a USB 2.0 and a USB 3.0 roothub.  So
setting the HCD_USB3 bits in the hcd->driver->flags is a bit misleading.
Add a new field to usb_hcd, bcdUSB.  Store the result of
hcd->driver->flags & HCD_MASK in it.  Later, when we have the xHCI driver
register the two roothubs, we'll set the usb_hcd->bcdUSB field to HCD_USB2
for the USB 2.0 roothub, and HCD_USB3 for the USB 3.0 roothub.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>