DMA mode 1 data corruption anomaly on Blackfin systems.  This issue is
specific to the Blackfin silicon as the bug appears to be related to the
connection of the musb ip to the bus/dma fabric.

Data corruption when using USB DMA mode 1. (Issue manager 17-01-0105)
DMA mode 1 allows large size transfers to generate a single interrupt
at the end of the entire transfer.  The transfer is split up in packets
of length specified in the Maximum Packet Size field for that endpoint.
If the transfer size is not an integer multiple of the Maximum Packet
Size, a short packet will be present at the end of the transfer.

Under certain conditions this packet may be corrupted in the USB FIFO.

Workaround:
Use DMA mode 1 to transfer (n* Maximum Packet Size) and schedule DMA
mode 0 to transfer the short packet.

As an example if your transfer size is 33168 bytes and Maximum Packet
Size equals 512, schedule [33168 - (33168 mod 512)] in DMA mode 1 and
the remainder (33168 mod 512) in DMA mode 0.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Below crash observed with commit 7acc6197
(usb: musb: Idle path retention and offmode support for OMAP3)
during board reboot.

The musb clock was disabled when musb_shutdown() was called by
platform_drv_shutdown in which there are register accesses.
call pm_runtime_get_sync() and pm_runtime_put_sync() in the
musb_shutdown function.

/ # [  172.368774] Unhandled fault: imprecise external abort (0x1406) at 0x400f0000
[  172.376190] Internal error: : 1406 [#1] SMP
[  172.380554] last sysfs file: /sys/devices/platform/omap/omap_i2c.4/i2c-4/i2c-dev/i2c-4/dev
[  172.389221] Modules linked in:
[  172.392456] CPU: 0    Tainted: G        W    (2.6.38-06671-geddecbb6 #33)
[  172.399475] PC is at do_raw_spin_unlock+0x50/0xc0
[  172.404418] LR is at _raw_spin_unlock_irqrestore+0x24/0x44
[  172.410186] pc : [<c069bfdc>]    lr : [<c085a7f8>]    psr: 60000093
[  172.410186] sp : ee993e40  ip : c0d00240  fp : bea9cf14
[  172.422241] r10: 00000000  r9 : ee992000  r8 : c04b2fa8
[  172.427703] r7 : 00000000  r6 : c0fa46c0  r5 : ef966124  r4 : ef966124
[  172.434539] r3 : ef92cbc0  r2 : ef92cbc0  r1 : 00000000  r0 : ef966124
[  172.441406] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
[  172.448974] Control: 10c5387d  Table: ae8d804a  DAC: 00000015
[  172.454986] Process init (pid: 1094, stack limit = 0xee9922f8)
[  172.461120] Stack: (0xee993e40 to 0xee994000)
[  172.465667] 3e40: a0000013 c085a7f8 ef966124 a0000013 c0fa46c0 c0761ab4 c0761a70 ef95c008
[  172.474273] 3e60: ef95c014 c06e2fd0 c06e2fbc c06dea90 00000000 01234567 28121969 c04fccb4
[  172.482849] 3e80: 00000000 c04fcd04 c0a302bc c04fce44 c0a02600 00000001 00000000 c085cd04
[  172.491424] 3ea0: 00000000 00000002 c09ea000 c085afc0 ee993f24 00000000 00040001 00000445
[  172.499999] 3ec0: a8eb9d34 00000027 00000000 00000000 00000000 c0a56a4c 00000000 00000000
[  172.508575] 3ee0: 00000002 60000093 00000000 c0519aac 00000002 00000080 00000000 c0550420
[  172.517150] 3f00: 00000000 00000002 ee970000 c0a56a3c c0a56a20 00000002 c0a56a3c 00000000
[  172.525726] 3f20: c0a56a3c 0000000a c1580e00 c0a56a20 00000002 c0a56a3c c1580e00 c0a56a20
[  172.534301] 3f40: ef92cbc0 c05173a0 00000001 ef92cbc0 c0576190 c04e3174 20000013 c0517324
[  172.542877] 3f60: ef815c00 ee90b720 c04e3174 c0576190 00000001 ef92cbc0 c04b2f00 ffffffff
[  172.551483] 3f80: 00000058 c0517324 00000000 00000000 ffffffff 00000000 00000000 ffffffff
[  172.560058] 3fa0: 00000058 c04b2de0 00000000 00000000 fee1dead 28121969 01234567 00000000
[  172.568634] 3fc0: 00000000 00000000 ffffffff 00000058 00000000 00000001 400aa000 bea9cf14
[  172.577209] 3fe0: 000ea148 bea9c958 000aa750 40225728 60000010 fee1dead 00000000 00000000
[  172.585784] [<c069bfdc>] (do_raw_spin_unlock+0x50/0xc0) from [<c085a7f8>] (_raw_spin_unlock_irqrestore+0x24/0x44)
[  172.596588] [<c085a7f8>] (_raw_spin_unlock_irqrestore+0x24/0x44) from [<c0761ab4>] (musb_shutdown+0x44/0x88)
[  172.606933] [<c0761ab4>] (musb_shutdown+0x44/0x88) from [<c06e2fd0>] (platform_drv_shutdown+0x14/0x18)
[  172.616699] [<c06e2fd0>] (platform_drv_shutdown+0x14/0x18) from [<c06dea90>] (device_shutdown+0x74/0xb4)
[  172.626647] [<c06dea90>] (device_shutdown+0x74/0xb4) from [<c04fccb4>] (kernel_restart_prepare+0x24/0x38)
[  172.636688] [<c04fccb4>] (kernel_restart_prepare+0x24/0x38) from [<c04fcd04>] (kernel_restart+0xc/0x48)
[  172.646545] [<c04fcd04>] (kernel_restart+0xc/0x48) from [<c04fce44>] (sys_reboot+0xfc/0x1d8)
[  172.655426] [<c04fce44>] (sys_reboot+0xfc/0x1d8) from [<c04b2de0>] (ret_fast_syscall+0x0/0x3c)
[  172.664459] Code: e3c3303f e594200c e593300c e1520003 (0a000002)
[  172.670867] ------------[ cut here ]------------
Signed-off-by: NHema HK <hemahk@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We are now using our own list_head, so we should
be checking against that, not the gadget driver's
list_head.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Due to the recent changes to musb's glue layers,
we can't compile musb-hdrc as a module - compilation
will break due to undefined symbol musb_debug. In
order to fix that, we need a big re-work of the
debug support on the MUSB driver.

Because that would mean a lot of new code coming
into the -rc series, it's best to defer that to
next merge window and for now just disable module
support for MUSB.

Once we get the refactor of the debugging support
done, we can simply revert this patch and things
will go back to normal again.

Cc: stable@kernel.org # v2.6.38
Signed-off-by: NFelipe Balbi <balbi@ti.com>

"tx_ram" points to io memory.  We can't dereference it directly.  Sparse
complains about this: "drivers/usb/musb/cppi_dma.c:1205:25: warning:
dereference of noderef expression"
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Gcc gives the following warnings:

drivers/usb/musb/cppi_dma.c: In function ‘cppi_next_tx_segment’:
drivers/usb/musb/cppi_dma.c:600: warning: format ‘%x’ expects type ‘unsigned int’, but argument 8 has type ‘dma_addr_t’
drivers/usb/musb/cppi_dma.c: In function ‘cppi_next_rx_segment’:
drivers/usb/musb/cppi_dma.c:822: warning: format ‘%x’ expects type ‘unsigned int’, but argument 9 has type ‘dma_addr_t’
drivers/usb/musb/cppi_dma.c: In function ‘cppi_rx_scan’:
drivers/usb/musb/cppi_dma.c:1042: warning: format ‘%08x’ expects type ‘unsigned int’, but argument 4 has type ‘dma_addr_t’
drivers/usb/musb/cppi_dma.c:1114: warning: format ‘%08x’ expects type ‘unsigned int’, but argument 7 has type ‘dma_addr_t’

dma_addr_t is sometimes 32 bit and sometimes 64.  We normally cast them
to unsigned long long for printk().
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Sparse complains (and rightly so):
drivers/usb/musb/cppi_dma.c:1458:33:
	warning: Using plain integer as NULL pointer
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We should unlock before returning here.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

musb code checks dma mask before calling dma hooks.
Signed-off-by: NMian Yousaf Kaukab <mian.yousaf.kaukab@stericsson.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

On the completion of tx dma, dma is disabled by clearing MUSB_TXCSR_DMAENAB in
TXCSR. If MUSB_TXCSR_AUTOSET was set in txstate() it will remain set although
it is not needed in PIO mode. Clear it as soon as it is not needed.
Signed-off-by: NMian Yousaf Kaukab <mian.yousaf.kaukab@stericsson.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Fix build warnings caused by removal of *filp arg in struct
usb_serial_driver.

These changes were missed somehow in commits 00a0d0d6 ("tty: remove
filp from the USB tty ioctls") and 60b33c13 ("tiocmget: kill off
the passing of the struct file")

  drivers/usb/serial/mct_u232.c:159: warning: initialization from incompatible pointer type
  drivers/usb/serial/opticon.c:627: warning: initialization from incompatible pointer type
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

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>