There's a race between the USB disconnect handler and the TTY close
handler which may cause the acm object to be freed while it's still
being used. This may lead to things like

http://article.gmane.org/gmane.linux.usb.general/54250

and

https://lkml.org/lkml/2011/5/29/64

This is the simplest fix I could come up with. Holding on to open_mutex
while closing the TTY device prevents acm_disconnect() from freeing the
acm object between acm->port.count drops to 0 and the TTY side of the
cleanups are finalized.
Signed-off-by: NHavard Skinnemoen <hskinnemoen@google.com>
Cc: Oliver Neukum <oliver@neukum.name>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

We've had another report of the "chipmunk" sound on a Logitech C600 webcam.
This patch resolves the issue.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJosh Boyer <jwboyer@redhat.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>

This patch for the usb serial ark3116 driver fixes an initialisation
ordering bug that gets triggered on hotplug when using at least recent
debian/ubuntu userspace. Without it, ark3116 serial cables don't work.
Signed-off-by: NBart Hartgers <bart.hartgers@gmail.com>
Tested-by: law_ence.dev@ntlworld.com
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

commit de477254 (include: replace linux/module.h
with "struct module" wherever possible) introduced
a compilation breaked when it removed <linux/module.h>
from <linux/device.h> which musb glue layers were
(mistakenly) relying on.

Include that header to fix the compile error.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Without this the gadget will never be able to allocate a stream capable
endpoint. The manual says that the stream id is a 16bit id. It does not
talk about an upper limit in any other way. So I think 15 is a
reasonable limit :)
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

new endpoint should start from DATA0,
but mod_host didn't care it.
This patch fix it.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

renesas_usbhs is caring pipe type and its direction.
but current usbhs_endpoint_alloc() didn't check direction.
this patch modify it.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Since commit "193ab2a6 usb: gadget: allow multiple gadgets to be built"
the udc controllers can be compiled as a module. The ci13xxx_msm driver
is missing the MODULE_LICENSE statement, so loading fails with:

ci13xxx_msm: module license 'unspecified' taints kernel.
ci13xxx_msm: Unknown symbol dev_set_name (err 0)
ci13xxx_msm: Unknown symbol platform_get_irq (err 0)
ci13xxx_msm: Unknown symbol device_unregister (err 0)
ci13xxx_msm: Unknown symbol usb_add_gadget_udc (err 0)
ci13xxx_msm: Unknown symbol put_device (err 0)
ci13xxx_msm: Unknown symbol platform_driver_register (err 0)
ci13xxx_msm: Unknown symbol platform_get_resource (err 0)
ci13xxx_msm: Unknown symbol device_register (err 0)
ci13xxx_msm: Unknown symbol usb_del_gadget_udc (err 0)

This patch adds the missing MODULE_LICENSE statement with GPL v2 according
to the header of the driver.
Tested-by: NPavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch fixes the following compile errors that show up if switching
on the debug trace code:

drivers/usb/gadget/ci13xxx_udc.c: In function 'ci13xxx_wakeup':
drivers/usb/gadget/ci13xxx_udc.c:2517:3: error: 'dev' undeclared (first use in this function)
drivers/usb/gadget/ci13xxx_udc.c:2517:3: note: each undeclared identifier is reported only once for each function it appears in
drivers/usb/gadget/ci13xxx_udc.c: In function 'udc_probe':
drivers/usb/gadget/ci13xxx_udc.c:2867:2: error: 'name' undeclared (first use in this function)
Tested-by: NPavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The inline documentation of _gadget_stop_activity() states that the
function should be called holding the udc->lock. This however will
result in a deadlock, because _gadget_stop_activity() takes the udc->lock.

During normal operation _gadget_stop_activity() is always called unlocked,
but in ci13xxx_stop() it's called locked, this results in the following
deadlock during rmmod of a gadget driver.

This patch fixes the deadlock by calling _gadget_stop_activity() always
unlocked, the inline documentation is adjusted accordingly.

=============================================
[ INFO: possible recursive locking detected ]
3.1.0-rc6+ #159
---------------------------------------------
rmmod/121 is trying to acquire lock:
 (udc_lock){-.-...}, at: [<c0229048>] _gadget_stop_activity+0x18/0x154

but task is already holding lock:
 (udc_lock){-.-...}, at: [<c02291e0>] ci13xxx_stop+0x5c/0x164

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(udc_lock);
  lock(udc_lock);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

2 locks held by rmmod/121:
 #0:  (udc_lock#2){+.+.+.}, at: [<c02286c0>] usb_gadget_unregister_driver+0x34/0x88
 #1:  (udc_lock){-.-...}, at: [<c02291e0>] ci13xxx_stop+0x5c/0x164

stack backtrace:
[<c000d41c>] (unwind_backtrace+0x0/0xf0) from [<c0056f94>] (check_deadlock.clone.24+0x284/0x2c4)
[<c0056f94>] (check_deadlock.clone.24+0x284/0x2c4) from [<c00589ac>] (validate_chain.clone.25+0x430/0x6fc)
[<c00589ac>] (validate_chain.clone.25+0x430/0x6fc) from [<c0059bac>] (__lock_acquire+0x494/0x8f0)
[<c0059bac>] (__lock_acquire+0x494/0x8f0) from [<c005a698>] (lock_acquire+0x98/0x1a8)
[<c005a698>] (lock_acquire+0x98/0x1a8) from [<c02f12a4>] (_raw_spin_lock_irqsave+0x64/0xa0)
[<c02f12a4>] (_raw_spin_lock_irqsave+0x64/0xa0) from [<c0229048>] (_gadget_stop_activity+0x18/0x154)
[<c0229048>] (_gadget_stop_activity+0x18/0x154) from [<c0229234>] (ci13xxx_stop+0xb0/0x164)
[<c0229234>] (ci13xxx_stop+0xb0/0x164) from [<c022867c>] (usb_gadget_remove_driver+0x88/0x98)
[<c022867c>] (usb_gadget_remove_driver+0x88/0x98) from [<c02286f4>] (usb_gadget_unregister_driver+0x68/0x88)
[<c02286f4>] (usb_gadget_unregister_driver+0x68/0x88) from [<c0065f2c>] (sys_delete_module+0x1fc/0x26c)
[<c0065f2c>] (sys_delete_module+0x1fc/0x26c) from [<c00092a0>] (ret_fast_syscall+0x0/0x38)
BUG: spinlock lockup on CPU#0, rmmod/121, c05b1644
[<c000d41c>] (unwind_backtrace+0x0/0xf0) from [<c01da000>] (do_raw_spin_lock+0x128/0x144)
[<c01da000>] (do_raw_spin_lock+0x128/0x144) from [<c02f12c8>] (_raw_spin_lock_irqsave+0x88/0xa0)
[<c02f12c8>] (_raw_spin_lock_irqsave+0x88/0xa0) from [<c0229048>] (_gadget_stop_activity+0x18/0x154)
[<c0229048>] (_gadget_stop_activity+0x18/0x154) from [<c0229234>] (ci13xxx_stop+0xb0/0x164)
[<c0229234>] (ci13xxx_stop+0xb0/0x164) from [<c022867c>] (usb_gadget_remove_driver+0x88/0x98)
[<c022867c>] (usb_gadget_remove_driver+0x88/0x98) from [<c02286f4>] (usb_gadget_unregister_driver+0x68/0x88)
[<c02286f4>] (usb_gadget_unregister_driver+0x68/0x88) from [<c0065f2c>] (sys_delete_module+0x1fc/0x26c)
[<c0065f2c>] (sys_delete_module+0x1fc/0x26c) from [<c00092a0>] (ret_fast_syscall+0x0/0x38)
Tested-by: NPavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The current driver sets the request's dma addr (mReq->req.dma) to 0 to
mark the DMA address as not valid. However some gadget drivers
(e.g. gadgetfs) set the request's dma addr to DMA_ADDR_INVALID to mark
the address as invalid. This leads to bogus data send because the
ci13xxx_udc driver assumes the request has already been mapped.

This patch fixes the problem, by using DMA_ADDR_INVALID instead of 0
to mark the request's DMA address as invalid.
Tested-by: NPavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: NMichael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Under certain circumstances lockdep finds an inconsistent lock state in
gadgetfs. The problem can be reproduced with a hardware using the
ci13xxx_udc driver and the gadgetfs test program (needs a patch to support
the ci13xxx_udc, though):
	http://www.linux-usb.org/gadget/usb.c
Start the test program, wait to initialize, then press Ctrl+c.

This patch fixes the following problem by using spin_lock_irqsave()
instead of spin_lock().

=================================
[ INFO: inconsistent lock state ]
3.1.0-rc6+ #158
---------------------------------
inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
usb/113 [HC0[0]:SC0[0]:HE1:SE1] takes:
 (&(&dev->lock)->rlock){?.....}, at: [<bf000340>] gadgetfs_disconnect+0x14/0x80 [gadgetfs]
{IN-HARDIRQ-W} state was registered at:
  [<c00596b8>] mark_irqflags+0x14c/0x1ac
  [<c0059bf8>] __lock_acquire+0x4e0/0x8f0
  [<c005a698>] lock_acquire+0x98/0x1a8
  [<c02f10e0>] _raw_spin_lock+0x54/0x8c
  [<bf000340>] gadgetfs_disconnect+0x14/0x80 [gadgetfs]
  [<c0229104>] _gadget_stop_activity+0xd4/0x154
  [<c022b130>] isr_reset_handler+0x34/0x1c0
  [<c022c320>] udc_irq+0x204/0x228
  [<c0069018>] handle_irq_event_percpu+0x64/0x3a0
  [<c0069390>] handle_irq_event+0x3c/0x5c
  [<c006ae5c>] handle_level_irq+0x8c/0x10c
  [<c0068a34>] generic_handle_irq+0x30/0x44
  [<c0009b2c>] handle_IRQ+0x30/0x84
  [<c0008ef8>] __irq_svc+0x38/0x60
  [<c0009c58>] default_idle+0x30/0x34
  [<c0009e30>] cpu_idle+0x9c/0xd8
  [<c04056f4>] start_kernel+0x278/0x2bc
irq event stamp: 6412
hardirqs last  enabled at (6412): [<c02f1cd0>] _raw_spin_unlock_irqrestore+0x30/0x5c
hardirqs last disabled at (6411): [<c02f1278>] _raw_spin_lock_irqsave+0x20/0xa0
softirqs last  enabled at (6381): [<c002833c>] irq_exit+0xa0/0xa8
softirqs last disabled at (6372): [<c002833c>] irq_exit+0xa0/0xa8

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&(&dev->lock)->rlock);
  <Interrupt>
    lock(&(&dev->lock)->rlock);

 *** DEADLOCK ***

1 lock held by usb/113:
 #0:  (udc_lock#2){+.+.+.}, at: [<c02286c0>] usb_gadget_unregister_driver+0x34/0x88

stack backtrace:
[<c000d41c>] (unwind_backtrace+0x0/0xf0) from [<c0058e98>] (print_usage_bug+0x144/0x1c4)
[<c0058e98>] (print_usage_bug+0x144/0x1c4) from [<c0059144>] (mark_lock_irq+0x22c/0x274)
[<c0059144>] (mark_lock_irq+0x22c/0x274) from [<c00592d4>] (mark_lock+0x148/0x3e0)
[<c00592d4>] (mark_lock+0x148/0x3e0) from [<c0059668>] (mark_irqflags+0xfc/0x1ac)
[<c0059668>] (mark_irqflags+0xfc/0x1ac) from [<c0059bf8>] (__lock_acquire+0x4e0/0x8f0)
[<c0059bf8>] (__lock_acquire+0x4e0/0x8f0) from [<c005a698>] (lock_acquire+0x98/0x1a8)
[<c005a698>] (lock_acquire+0x98/0x1a8) from [<c02f10e0>] (_raw_spin_lock+0x54/0x8c)
[<c02f10e0>] (_raw_spin_lock+0x54/0x8c) from [<bf000340>] (gadgetfs_disconnect+0x14/0x80 [gadgetfs])
[<bf000340>] (gadgetfs_disconnect+0x14/0x80 [gadgetfs]) from [<c0229104>] (_gadget_stop_activity+0xd4/0x154)
[<c0229104>] (_gadget_stop_activity+0xd4/0x154) from [<c0229240>] (ci13xxx_stop+0xbc/0x17c)
[<c0229240>] (ci13xxx_stop+0xbc/0x17c) from [<c022867c>] (usb_gadget_remove_driver+0x88/0x98)
[<c022867c>] (usb_gadget_remove_driver+0x88/0x98) from [<c02286f4>] (usb_gadget_unregister_driver+0x68/0x88)
[<c02286f4>] (usb_gadget_unregister_driver+0x68/0x88) from [<bf0003e8>] (dev_release+0x14/0x48 [gadgetfs])
[<bf0003e8>] (dev_release+0x14/0x48 [gadgetfs]) from [<c00cc158>] (__fput+0xa4/0x1f0)
[<c00cc158>] (__fput+0xa4/0x1f0) from [<c00c7f28>] (filp_close+0x5c/0x74)
[<c00c7f28>] (filp_close+0x5c/0x74) from [<c00c7fe8>] (sys_close+0xa8/0x150)
[<c00c7fe8>] (sys_close+0xa8/0x150) from [<c00092a0>] (ret_fast_syscall+0x0/0x38)
Tested-by: NPavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The dynamic jack allocation of the MIDI gadget currently links all
external jacks to one single instance of an embedded jack. According to
the spec, this is only valid if these streams always carry the same data
stream, as described in the USB MIDI 1.0 spec, chapter 3.3.1.

Also, genius Windows 7(tm) terminates it's life cycle instantly with a
blue screen of death once a device with more than one input and output
port with the current implementation is connected.

While at it, and because it grew again by this change, allocate the
temporary function pointer list on the heap, not on the stack.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The USB-IF CV compliance tester is getting stricter, and it would
be valid for it to fail a mass-storage device that accepts an
invalid USB_BULK_RESET_REQUEST request. Although it doesn't do
that yet, let's be proactive and fix that now.

Suggested by Alan Stern.
Signed-off-by: NPaul Zimmerman <paulz@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The latest USB-IF CV tester checks for a valid length for this
request.
Signed-off-by: NPaul Zimmerman <paulz@synopsys.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Fix up the following section mismatch warnings:

WARNING: drivers/usb/renesas_usbhs/renesas_usbhs.o(.text+0xf5d): Section
mismatch in reference from the function usbhs_mod_probe() to the function
.devinit.text:usbhs_mod_host_probe() The function usbhs_mod_probe() references
the function __devinit usbhs_mod_host_probe().  This is often because
usbhs_mod_probe lacks a __devinit annotation or the annotation of
usbhs_mod_host_probe is wrong.

WARNING: drivers/usb/renesas_usbhs/renesas_usbhs.o(.text+0xfd7): Section
mismatch in reference from the function usbhs_mod_probe() to the function
.devexit.text:usbhs_mod_host_remove() The function usbhs_mod_probe() references
a function in an exit section.  Often the function usbhs_mod_host_remove() has
valid usage outside the exit section and the fix is to remove the __devexit
annotation of usbhs_mod_host_remove.

WARNING: drivers/usb/renesas_usbhs/renesas_usbhs.o(.text+0x1005): Section
mismatch in reference from the function usbhs_mod_remove() to the function
.devexit.text:usbhs_mod_host_remove() The function usbhs_mod_remove()
references a function in an exit section.  Often the function
usbhs_mod_host_remove() has valid usage outside the exit section and the fix is
to remove the __devexit annotation of usbhs_mod_host_remove.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

this patch fixup bogus conversion of
8a9775ab
(usb: gadget: renesas_usbhs: fix compile warning)
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Since renesas_usbhs mod_host didn't use
struct completion as static object, the warning of lockdep came out.
This patch fixup this issue.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Fix compile error in file drivers/usb/gadget/fsl_udc_core.c.

drivers/usb/gadget/fsl_udc_core.c: In function 'portscx_device_speed':
drivers/usb/gadget/fsl_udc_core.c:1720: error: 'speed' undeclared (first
use in this function)

Introduced in commit e538dfda
(usb: Provide usb_speed_string() function)
Signed-off-by: NAlexander Aring <a.aring@phytec.de>
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The "BCLR" in CFIFOCTR/DnFIFOCTR can flush the fifo of "CPU side" only.
To flush the fifo of "SIE side", we have to use the "ACLRM" in PIPEnCTR.
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The udc-newstyle needs device_register in probe() of platform_device.
If it doesn't call, kernel panic happens in the sysfs_create_dir() when
we run modprobe a gadget driver.

[ balbi@ti.com : fix compile warning introduced by this patch ]
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

USB_MUSB_HDRC depends on USB_GADGET_DUALSPEED.  If HDRC is selected
but DUALSPEED is not, the kernel oopses:

[    3.132781] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[    3.141296] pgd = c0004000
[    3.144134] [00000000] *pgd=00000000
[    3.147918] Internal error: Oops: 5 [#1] SMP
[    3.152404] Modules linked in:
[    3.155609] CPU: 0    Not tainted  (3.1.0-rc9-wl+ #417)
[    3.161132] PC is at composite_setup+0x738/0xbb4
[    3.165985] LR is at vprintk+0x400/0x47c
[    3.170135] pc : [<c031df90>]    lr : [<c004c150>]    psr: 60000093
[    3.170135] sp : c065dd50  ip : dfb1f0fc  fp : c065ddbc
[    3.182220] r10: 00000000  r9 : df8fcae8  r8 : df8fcaa0
[    3.187713] r7 : 00000000  r6 : df8eaa20  r5 : dfae8ea0  r4 : 00000000
[    3.194580] r3 : df8fcae8  r2 : 00010002  r1 : c065dc40  r0 : 00000047
[    3.201446] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[    3.209228] Control: 10c53c7d  Table: 8000404a  DAC: 00000015
[    3.215270] Process swapper (pid: 0, stack limit = 0xc065c2f8)
[    3.221405] Stack: (0xc065dd50 to 0xc065e000)
[...]
[    3.415405] [<c031df90>] (composite_setup+0x738/0xbb4) from [<c0310d18>] (musb_g_ep0_irq+0x9d0/0xaf8)
[    3.425109] [<c0310d18>] (musb_g_ep0_irq+0x9d0/0xaf8) from [<c030fb04>] (musb_interrupt+0xb48/0xc74)
[    3.434722] [<c030fb04>] (musb_interrupt+0xb48/0xc74) from [<c030fc98>] (generic_interrupt+0x68/0x80)
[    3.444458] [<c030fc98>] (generic_interrupt+0x68/0x80) from [<c0095204>] (handle_irq_event_percpu+0x9c/0x234)
[    3.454925] [<c0095204>] (handle_irq_event_percpu+0x9c/0x234) from [<c00953e8>] (handle_irq_event+0x4c/0x6c)
[    3.465270] [<c00953e8>] (handle_irq_event+0x4c/0x6c) from [<c0097e10>] (handle_fasteoi_irq+0xd8/0x110)
[    3.475158] [<c0097e10>] (handle_fasteoi_irq+0xd8/0x110) from [<c0094d2c>] (generic_handle_irq+0x34/0x3c)
[    3.485260] [<c0094d2c>] (generic_handle_irq+0x34/0x3c) from [<c0014ae4>] (handle_IRQ+0x88/0xc8)
[    3.494537] [<c0014ae4>] (handle_IRQ+0x88/0xc8) from [<c00085b0>] (asm_do_IRQ+0x18/0x1c)
[    3.503051] [<c00085b0>] (asm_do_IRQ+0x18/0x1c) from [<c0429e78>] (__irq_svc+0x38/0xc0)

This patch changes Kconfig so that USB_GADGET_DUALSPEED is selected
automatically by USB_MUSB_HDRC.
Signed-off-by: NLuciano Coelho <coelho@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

ARCH_U8500 covers both MACH_U8500 and MACH_U5500
Reported-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NMian Yousaf Kaukab <mian.yousaf.kaukab@stericsson.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Those are simply giving information about the current
state of the UDC, nothing really fancy. We can let
everybody read those.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

usb_gadget_disconnect() is responsible of removing
data pullups. Before doing that we must, first, tell
gadget driver we're disconnecting (by calling disconnect
method on gadget driver structure), unbind the gadget
driver and stop the controller.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

that has already being done by udc-core.c. It's
unnecessary and might cause issues with some gadget
drivers.

Tested: Ajay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

We should not be using dev_get_drvdata() because we
never call dev_set_drvdata(). Let's use container_of()
as all other sysfs attributes.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Originally, the runtime PM core would send an idle notification
whenever a suspend attempt failed.  The idle callback routine could
then schedule a delayed suspend for some time later.

However this behavior was changed by commit
f71648d7 (PM / Runtime: Remove idle
notification after failing suspend).  No notifications were sent, and
there was no clear mechanism to retry failed suspends.

This caused problems for the usbhid driver, because it fails
autosuspend attempts as long as a key is being held down.  A companion
patch changes the PM core's behavior, but we also need to change the
USB core.  In particular, this patch (as1493) updates the device's
last_busy time when an autosuspend fails, so that the PM core will
retry the autosuspend in the future when the delay time expires
again.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NHenrik Rydberg <rydberg@euromail.se>
Cc: <stable@kernel.org>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

I noticed on my Panther Point system that I wasn't getting hotplug events
for my usb3.0 disk on a usb3 port.  I tracked it down to the fact that the
system had the warm reset change bit still set.  This seemed to block future
events from being received, including a hotplug event.

Clearing this bit during initialization allowed the hotplug event to be
received and the disk to be recognized correctly.

This patch should be backported to kernels as old as 2.6.39.
Signed-off-by: NDon Zickus <dzickus@redhat.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org

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

While debugging a usb3 problem, I stumbled upon this lockdep warning.

Oct 18 21:41:17 dhcp47-74 kernel: =================================
Oct 18 21:41:17 dhcp47-74 kernel: [ INFO: inconsistent lock state ]
Oct 18 21:41:17 dhcp47-74 kernel: 3.1.0-rc4nmi+ #456
Oct 18 21:41:17 dhcp47-74 kernel: ---------------------------------
Oct 18 21:41:17 dhcp47-74 kernel: inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
Oct 18 21:41:17 dhcp47-74 kernel: swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
Oct 18 21:41:17 dhcp47-74 kernel: (&(&xhci->lock)->rlock){?.-...}, at: [<ffffffffa0228990>] xhci_stop_endpoint_command_watchdog+0x30/0x340 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel: {IN-HARDIRQ-W} state was registered at:
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8109a941>] __lock_acquire+0x781/0x1660
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8109bed7>] lock_acquire+0x97/0x170
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff81501b46>] _raw_spin_lock+0x46/0x80
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffffa02299fa>] xhci_irq+0x3a/0x1960 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffffa022b351>] xhci_msi_irq+0x31/0x40 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff810d2305>] handle_irq_event_percpu+0x85/0x320
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff810d25e8>] handle_irq_event+0x48/0x70
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff810d537d>] handle_edge_irq+0x6d/0x130
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff810048c9>] handle_irq+0x49/0xa0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8150d56d>] do_IRQ+0x5d/0xe0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff815029b0>] ret_from_intr+0x0/0x13
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff81388aca>] usb_set_device_state+0x8a/0x180
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8138f038>] usb_add_hcd+0x2b8/0x730
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffffa022ed7e>] xhci_pci_probe+0x9e/0xd4 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8127915f>] local_pci_probe+0x5f/0xd0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8127a569>] pci_device_probe+0x119/0x120
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff81334473>] driver_probe_device+0xa3/0x2c0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8133473b>] __driver_attach+0xab/0xb0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8133373c>] bus_for_each_dev+0x6c/0xa0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff813341fe>] driver_attach+0x1e/0x20
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff81333b88>] bus_add_driver+0x1f8/0x2b0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff81334df6>] driver_register+0x76/0x140
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8127a7c6>] __pci_register_driver+0x66/0xe0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffffa013c04a>] snd_timer_find+0x4a/0x70 [snd_timer]
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffffa013c00e>] snd_timer_find+0xe/0x70 [snd_timer]
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff810001d3>] do_one_initcall+0x43/0x180
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff810a9ed2>] sys_init_module+0x92/0x1f0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8150ab6b>] system_call_fastpath+0x16/0x1b
Oct 18 21:41:17 dhcp47-74 kernel: irq event stamp: 631984
Oct 18 21:41:17 dhcp47-74 kernel: hardirqs last  enabled at (631984): [<ffffffff81502720>] _raw_spin_unlock_irq+0x30/0x50
Oct 18 21:41:17 dhcp47-74 kernel: hardirqs last disabled at (631983): [<ffffffff81501c49>] _raw_spin_lock_irq+0x19/0x90
Oct 18 21:41:17 dhcp47-74 kernel: softirqs last  enabled at (631980): [<ffffffff8105ff63>] _local_bh_enable+0x13/0x20
Oct 18 21:41:17 dhcp47-74 kernel: softirqs last disabled at (631981): [<ffffffff8150ce6c>] call_softirq+0x1c/0x30
Oct 18 21:41:17 dhcp47-74 kernel:
Oct 18 21:41:17 dhcp47-74 kernel: other info that might help us debug this:
Oct 18 21:41:17 dhcp47-74 kernel: Possible unsafe locking scenario:
Oct 18 21:41:17 dhcp47-74 kernel:
Oct 18 21:41:17 dhcp47-74 kernel:       CPU0
Oct 18 21:41:17 dhcp47-74 kernel:       ----
Oct 18 21:41:17 dhcp47-74 kernel:  lock(&(&xhci->lock)->rlock);
Oct 18 21:41:17 dhcp47-74 kernel:  <Interrupt>
Oct 18 21:41:17 dhcp47-74 kernel:    lock(&(&xhci->lock)->rlock);
Oct 18 21:41:17 dhcp47-74 kernel:
Oct 18 21:41:17 dhcp47-74 kernel: *** DEADLOCK ***
Oct 18 21:41:17 dhcp47-74 kernel:
Oct 18 21:41:17 dhcp47-74 kernel: 1 lock held by swapper/0:
Oct 18 21:41:17 dhcp47-74 kernel: #0:  (&ep->stop_cmd_timer){+.-...}, at: [<ffffffff8106abf2>] run_timer_softirq+0x162/0x570
Oct 18 21:41:17 dhcp47-74 kernel:
Oct 18 21:41:17 dhcp47-74 kernel: stack backtrace:
Oct 18 21:41:17 dhcp47-74 kernel: Pid: 0, comm: swapper Tainted: G        W   3.1.0-rc4nmi+ #456
Oct 18 21:41:17 dhcp47-74 kernel: Call Trace:
Oct 18 21:41:17 dhcp47-74 kernel: <IRQ>  [<ffffffff81098ed7>] print_usage_bug+0x227/0x270
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff810999c6>] mark_lock+0x346/0x410
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8109a7de>] __lock_acquire+0x61e/0x1660
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81099893>] ? mark_lock+0x213/0x410
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8109bed7>] lock_acquire+0x97/0x170
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffffa0228990>] ? xhci_stop_endpoint_command_watchdog+0x30/0x340 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81501b46>] _raw_spin_lock+0x46/0x80
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffffa0228990>] ? xhci_stop_endpoint_command_watchdog+0x30/0x340 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffffa0228990>] xhci_stop_endpoint_command_watchdog+0x30/0x340 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8106abf2>] ? run_timer_softirq+0x162/0x570
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8106ac9d>] run_timer_softirq+0x20d/0x570
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8106abf2>] ? run_timer_softirq+0x162/0x570
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffffa0228960>] ? xhci_queue_isoc_tx_prepare+0x8e0/0x8e0 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff810604d2>] __do_softirq+0xf2/0x3f0
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81020edd>] ? lapic_next_event+0x1d/0x30
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81090d4e>] ? clockevents_program_event+0x5e/0x90
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8150ce6c>] call_softirq+0x1c/0x30
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8100484d>] do_softirq+0x8d/0xc0
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8105ff35>] irq_exit+0xe5/0x100
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8150d65e>] smp_apic_timer_interrupt+0x6e/0x99
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8150b6f0>] apic_timer_interrupt+0x70/0x80
Oct 18 21:41:17 dhcp47-74 kernel: <EOI>  [<ffffffff81095d8d>] ? trace_hardirqs_off+0xd/0x10
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff812ddb76>] ? acpi_idle_enter_bm+0x227/0x25b
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff812ddb71>] ? acpi_idle_enter_bm+0x222/0x25b
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff813eda63>] cpuidle_idle_call+0x103/0x290
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81002155>] cpu_idle+0xe5/0x160
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff814e7f50>] rest_init+0xe0/0xf0
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff814e7e70>] ? csum_partial_copy_generic+0x170/0x170
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81df8e23>] start_kernel+0x3fc/0x407
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81df8321>] x86_64_start_reservations+0x131/0x135
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81df8412>] x86_64_start_kernel+0xed/0xf4
Oct 18 21:41:17 dhcp47-74 kernel: xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command.
Oct 18 21:41:17 dhcp47-74 kernel: xhci_hcd 0000:00:14.0: Assuming host is dying, halting host.
Oct 18 21:41:17 dhcp47-74 kernel: xhci_hcd 0000:00:14.0: HC died; cleaning up
Oct 18 21:41:17 dhcp47-74 kernel: usb 3-4: device descriptor read/8, error -110
Oct 18 21:41:17 dhcp47-74 kernel: usb 3-4: device descriptor read/8, error -22
Oct 18 21:41:17 dhcp47-74 kernel: hub 3-0:1.0: cannot disable port 4 (err = -19)

Basically what is happening is in xhci_stop_endpoint_command_watchdog()
the xhci->lock is grabbed with just spin_lock.  What lockdep deduces is
that if an interrupt occurred while in this function it would deadlock
with xhci_irq because that function also grabs the xhci->lock.

Fixing it is trivial by using spin_lock_irqsave instead.

This should be queued to stable kernels as far back as 2.6.33.
Signed-off-by: NDon Zickus <dzickus@redhat.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org

To fix this build error on ARM:

drivers/usb/host/xhci-hub.c: In function 'xhci_stop_device':
drivers/usb/host/xhci-hub.c:261: error: 'GFP_NOIO' undeclared (first use in this function)
make[4]: *** [drivers/usb/host/xhci-hub.o] Error 1
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

With module.h being implicitly everywhere via device.h, the absence
of explicitly including something for EXPORT_SYMBOL went unnoticed.
Since we are heading to fix things up and clean module.h from the
device.h file, we need to explicitly include these files now.

Use the lightweight version of the header that has just THIS_MODULE
and EXPORT_SYMBOL variants.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

The situation up to this point meant that module.h was pretty
much everywhere, regardless of whether you asked for it or not.
We are fixing that, so give the USB folks who want it an actual
include of it.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

Now that no driver any longer depends on the CONFIG_SOC_AU1???  symbols,
it's time to get rid of them: Move some of the platform devices to the
boards which can use them, Rename a few (unused) constants in the header,
Replace them with MIPS_ALCHEMY in the various Kconfig files.  Finally
delete them altogether from the Alchemy Kconfig file.
Signed-off-by: NManuel Lauss <manuel.lauss@googlemail.com>
To: Linux-MIPS <linux-mips@linux-mips.org>
Patchwork: https://patchwork.linux-mips.org/patch/2707/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Alchemy chips have one or more registers which control access
to the usb blocks as well as PHY configuration.  I don't want
the OHCI/EHCI glues to know about the different registers and bits;
new code hides the gory details of USB configuration from them.
Signed-off-by: NManuel Lauss <manuel.lauss@googlemail.com>
To: Linux-MIPS <linux-mips@linux-mips.org>
Cc: linux-usb@vger.kernel.org
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Patchwork: https://patchwork.linux-mips.org/patch/2709/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

 create mode 100644 drivers/usb/host/alchemy-common.c