This patch (as1542) changes the criterion ehci-hcd uses to tell when
it needs to resume the controller's root hub.  A resume is needed when
a port status change is detected, obviously, but only if the root hub
is currently suspended.

Right now the driver tests whether the root hub is running, and that
is not the correct test.  In particular, if the controller has died
then the root hub should not be restarted.  In addition, some buggy
hardware occasionally requires the root hub to be running and
sending out SOF packets even while it is nominally supposed to be
suspended.

In the end, the test needs to be changed.  Rather than checking whether
the root hub is currently running, the driver will now check whether
the root hub is currently suspended.  This will yield the correct
behavior in all cases.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: Peter Chen <B29397@freescale.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

These devices have a number of non serial interfaces as well.  Use
the existing "Direct IP" blacklist to prevent binding to interfaces
which are handled by other drivers.

We also extend the "Direct IP" blacklist with with interfaces only
seen in "QMI" mode, assuming that these devices use the same
interface numbers for serial interfaces both in "Direct IP" and in
"QMI" mode.
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

A large `nents' from userspace could overflow the allocation size,
leading to memory corruption.

| alloc_sglist()
| usbtest_ioctl()

Use kmalloc_array() to avoid the overflow.
Signed-off-by: NXi Wang <xi.wang@gmail.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Avoid overflowing context.count = param->sglen * param->iterations,
where both `sglen' and `iterations' are from userspace.

| test_ctrl_queue()
| usbtest_ioctl()

Keep -EOPNOTSUPP for error code.
Signed-off-by: NXi Wang <xi.wang@gmail.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as154) fixes a self-deadlock that occurs when userspace
writes to the bConfigurationValue sysfs attribute for a hub with
children.  The task tries to lock the bandwidth_mutex at a time when
it already owns the lock:

	The attribute's method calls usb_set_configuration(),
	which calls usb_disable_device() with the bandwidth_mutex
	held.

	usb_disable_device() unregisters the existing interfaces,
	which causes the hub driver to be unbound.

	The hub_disconnect() routine calls hub_quiesce(), which
	calls usb_disconnect() for each of the hub's children.

	usb_disconnect() attempts to acquire the bandwidth_mutex
	around a call to usb_disable_device().

The solution is to make usb_disable_device() acquire the mutex for
itself instead of requiring the caller to hold it.  Then the mutex can
cover only the bandwidth deallocation operation and not the region
where the interfaces are unregistered.

This has the potential to change system behavior slightly when a
config change races with another config or altsetting change.  Some of
the bandwidth released from the old config might get claimed by the
other config or altsetting, make it impossible to restore the old
config in case of a failure.  But since we don't try to recover from
config-change failures anyway, this doesn't matter.

[This should be marked for stable kernels that contain the commit
fccf4e86 "USB: Free bandwidth when
usb_disable_device is called."
That commit was marked for stable kernels as old as 2.6.32.]
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Re-define XHCI_LEGACY_DISABLE_SMI and used it in right way. All SMI enable
bits will be cleared to zero and flag bits 29:31 are also cleared to zero.
Other bits should be presvered as Table 146.

This patch should be backported to kernels as old as 2.6.31.
Signed-off-by: NAlex He <alex.he@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org

The caller is allowed to specify the GFP flags for these functions.
We should prefer their flags unless we have good reason.  For
example, if we take a spin_lock ourselves we'd need to use
GFP_ATOMIC.  But in this case it's safe to use the callers GFP
flags.

The callers all pass GFP_ATOMIC here, so this change doesn't affect
how the kernel behaves but we may add other callers later and this
is a cleanup.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The suspend operation of VIA xHCI host have some issues and
hibernate operation works fine, so The XHCI_RESET_ON_RESUME
quirk is added for it.

This patch should base on "xHCI: Don't write zeroed pointer
to xHC registers" that is released by Sarah. Otherwise, the
host system error will ocurr in the hibernate operation
process.

This should be backported to stable kernels as old as 2.6.37,
that contain the commit c877b3b2
"xhci: Add reset on resume quirk for asrock p67 host".
Signed-off-by: NElric Fu <elricfu1@gmail.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org

When the Seagate Goflex USB3.0 device is attached to VIA xHCI
host, sometimes the device will downgrade mode to high speed.
By the USB analyzer, I found the device finished the link
training process and worked at superspeed mode. But the device
descriptor got from the device shows the device works at 2.1.
It is very strange and seems like the device controller of
Seagate Goflex has a little confusion.

The first 8 bytes of device descriptor should be:
12 01 00 03 00 00 00 09

But the first 8 bytes of wrong device descriptor are:
12 01 10 02 00 00 00 40

The wrong device descriptor caused the initialization of mass
storage failed. After a while, the device would be recognized
as a high speed device and works fine.

This patch will warm reset the device to fix the issue after
finding the bcdUSB field of device descriptor isn't 0x0300
but the speed mode of device is superspeed.

This patch should be backported to kernels as old as 3.2, or ones that
contain the commit 75d7cf72 "usbcore:
refine warm reset logic".
Signed-off-by: NElric Fu <elricfu1@gmail.com>
Acked-by: NAndiry Xu <Andiry.Xu@amd.com>
Acked-by: NSergei Shtylyov <sshtylyov@mvista.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org

The xHCI 1.0 spec errata released on June 13, 2011, changes the ordering
that the xHCI registers are saved and restored in.  It moves the
interrupt pending (IMAN) and interrupt control (IMOD) registers to be
saved and restored last.  I believe that's because the host controller
may attempt to fetch the event ring table when interrupts are
re-enabled.  Therefore we need to restore the event ring registers
before we re-enable interrupts.

This should be backported to kernels as old as 2.6.37, that contain the
commit 5535b1d5 "USB: xHCI: PCI power
management implementation"
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: NElric Fu <elricfu1@gmail.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@vger.kernel.org

The xhci_save_registers() function saved the event ring dequeue pointer
in the s3 register structure, but xhci_restore_registers() never
restored it.  No other code in the xHCI successful resume path would
ever restore it either.  Fix that.

This should be backported to kernels as old as 2.6.37, that contain the
commit 5535b1d5 "USB: xHCI: PCI power
management implementation".
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: NElric Fu <elricfu1@gmail.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@vger.kernel.org

When xhci_mem_cleanup() is called, we can't be sure if the xHC is
actually halted.  We can ask the xHC to halt by writing to the RUN bit
in the command register, but that might timeout due to a HW hang.

If the host controller is still running, we should not write zeroed
values to the event ring dequeue pointers or base tables, the DCBAA
pointers, or the command ring pointers.  Eric Fu reports his VIA VL800
host accesses the event ring pointers after a failed register restore on
resume from suspend.  The hypothesis is that the host never actually
halted before the register write to change the event ring pointer to
zero.

Remove all writes of zeroed values to pointer registers in
xhci_mem_cleanup().  Instead, make all callers of the function reset the
host controller first, which will reset those registers to zero.
xhci_mem_init() is the only caller that doesn't first halt and reset the
host controller before calling xhci_mem_cleanup().

This should be backported to kernels as old as 2.6.32.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: NElric Fu <elricfu1@gmail.com>
Cc: stable@vger.kernel.org

Eric Fu reports a problem with his VIA host controller fetching a zeroed
event ring pointer on resume from suspend.  The host should have been
halted, but we can't be sure because that code ignores the return value
from xhci_halt().  Print a warning when the host controller refuses to
halt within XHCI_MAX_HALT_USEC (currently 16 seconds).

(Update: it turns out that the VIA host controller is reporting a halted
state when it fetches the zeroed event ring pointer.  However, we still
need this warning for other host controllers.)
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

While we're at that, define IMAN bitfield to aid readability.

The interrupt enable bit should be set once on driver init, and we
shouldn't need to continually re-enable it.  Commit c21599a3 introduced
a read of the irq_pending register, and that allows us to preserve the
state of the IE bit.  Before that commit, we were blindly writing 0x3 to
the register.

This patch should be backported to kernels as old as 2.6.36, or ones
that contain the commit c21599a3 "USB:
xhci: Reduce reads and writes of interrupter registers".
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org

xhci_unregister_pci() is called in xhci_hcd_init().
Signed-off-by: NGerard Snitselaar <dev@snitselaar.org>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Correct the print of HSEE of USBCMD in xhci-dbg.c.
Signed-off-by: NAlex He <alex.he@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Fix race between probe and open by making sure that the disconnected
flag is not cleared until all ports have been registered.

A call to tty_open while probe is running may get a reference to the
serial structure in serial_install before its ports have been
registered. This may lead to usb_serial_core calling driver open before
port is fully initialised.

With ftdi_sio this result in the following NULL-pointer dereference as
the private data has not been initialised at open:

[  199.698286] IP: [<f811a089>] ftdi_open+0x59/0xe0 [ftdi_sio]
[  199.698297] *pde = 00000000
[  199.698303] Oops: 0000 [#1] PREEMPT SMP
[  199.698313] Modules linked in: ftdi_sio usbserial
[  199.698323]
[  199.698327] Pid: 1146, comm: ftdi_open Not tainted 3.2.11 #70 Dell Inc. Vostro 1520/0T816J
[  199.698339] EIP: 0060:[<f811a089>] EFLAGS: 00010286 CPU: 0
[  199.698344] EIP is at ftdi_open+0x59/0xe0 [ftdi_sio]
[  199.698348] EAX: 0000003e EBX: f5067000 ECX: 00000000 EDX: 80000600
[  199.698352] ESI: f48d8800 EDI: 00000001 EBP: f515dd54 ESP: f515dcfc
[  199.698356]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[  199.698361] Process ftdi_open (pid: 1146, ti=f515c000 task=f481e040 task.ti=f515c000)
[  199.698364] Stack:
[  199.698368]  f811a9fe f811a9e0 f811b3ef 00000000 00000000 00001388 00000000 f4a86800
[  199.698387]  00000002 00000000 f806e68e 00000000 f532765c f481e040 00000246 22222222
[  199.698479]  22222222 22222222 22222222 f5067004 f5327600 f5327638 f515dd74 f806e6ab
[  199.698496] Call Trace:
[  199.698504]  [<f806e68e>] ? serial_activate+0x2e/0x70 [usbserial]
[  199.698511]  [<f806e6ab>] serial_activate+0x4b/0x70 [usbserial]
[  199.698521]  [<c126380c>] tty_port_open+0x7c/0xd0
[  199.698527]  [<f806e660>] ? serial_set_termios+0xa0/0xa0 [usbserial]
[  199.698534]  [<f806e76f>] serial_open+0x2f/0x70 [usbserial]
[  199.698540]  [<c125d07c>] tty_open+0x20c/0x510
[  199.698546]  [<c10e9eb7>] chrdev_open+0xe7/0x230
[  199.698553]  [<c10e48f2>] __dentry_open+0x1f2/0x390
[  199.698559]  [<c144bfec>] ? _raw_spin_unlock+0x2c/0x50
[  199.698565]  [<c10e4b76>] nameidata_to_filp+0x66/0x80
[  199.698570]  [<c10e9dd0>] ? cdev_put+0x20/0x20
[  199.698576]  [<c10f3e08>] do_last+0x198/0x730
[  199.698581]  [<c10f4440>] path_openat+0xa0/0x350
[  199.698587]  [<c10f47d5>] do_filp_open+0x35/0x80
[  199.698593]  [<c144bfec>] ? _raw_spin_unlock+0x2c/0x50
[  199.698599]  [<c10ff110>] ? alloc_fd+0xc0/0x100
[  199.698605]  [<c10f0b72>] ? getname_flags+0x72/0x120
[  199.698611]  [<c10e4450>] do_sys_open+0xf0/0x1c0
[  199.698617]  [<c11fcc08>] ? trace_hardirqs_on_thunk+0xc/0x10
[  199.698623]  [<c10e458e>] sys_open+0x2e/0x40
[  199.698628]  [<c144c990>] sysenter_do_call+0x12/0x36
[  199.698632] Code: 85 89 00 00 00 8b 16 8b 4d c0 c1 e2 08 c7 44 24 14 88 13 00 00 81 ca 00 00 00 80 c7 44 24 10 00 00 00 00 c7 44 24 0c 00 00 00 00 <0f> b7 41 78 31 c9 89 44 24 08 c7 44 24 04 00 00 00 00 c7 04 24
[  199.698884] EIP: [<f811a089>] ftdi_open+0x59/0xe0 [ftdi_sio] SS:ESP 0068:f515dcfc
[  199.698893] CR2: 0000000000000078
[  199.698925] ---[ end trace 77c43ec023940cff ]---
Reported-and-tested-by: NKen Huang <csuhgw@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: gadget: eliminate NULL pointer dereference (bugfix)

This patch fixes a bug which causes NULL pointer dereference in
ffs_ep0_ioctl. The bug happens when the FunctionFS is not bound (either
has not been bound yet or has been bound and then unbound) and can be
reproduced with running the following commands:

$ insmod g_ffs.ko
$ mount -t functionfs func /dev/usbgadget
$ ./null

where null.c is:

#include <fcntl.h>
#include <linux/usb/functionfs.h>

int main(void)
{
	int fd = open("/dev/usbgadget/ep0", O_RDWR);
	ioctl(fd, FUNCTIONFS_CLEAR_HALT);

	return 0;
}
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Cc: stable@vger.kernel.org
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This patch removes the non-required spinlock acquire/release calls on
'queue->irqlock' from 'uvc_queue_next_buffer' routine.

This routine is called from 'video->encode' function (which translates to
either 'uvc_video_encode_bulk' or 'uvc_video_encode_isoc') in 'uvc_video.c'.
As, the 'video->encode' routines are called with 'queue->irqlock' already held,
so acquiring a 'queue->irqlock' again in 'uvc_queue_next_buffer' routine causes
a spin lock recursion.
Signed-off-by: NBhupesh Sharma <bhupesh.sharma@st.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

It is crucial to assign each req->context value to struct rndis.

The problem happens for multi function gadget (g_multi) when multiple
functions are calling common usb_composite_dev control request.

It might happen that *_setup method from one usb function will
alter some fields of this common request issued by other USB
function.
Signed-off-by: NLukasz Majewski <l.majewski@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

pm_runtime_get_sync returns a signed integer. In case of errors
it returns a negative value. This patch fixes the error check
by making it signed instead of unsigned thus preventing register
access if get_sync_fails. Also passes the error cause to the
debug message.

Cc: stable@vger.kernel.org
Cc:  Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

During modprobe of gadget driver, pullup is called after
udc_start. In order to make the exit path symmetric when
removing a gadget driver, call pullup before ->udc_stop.

This is needed to avoid issues with PM where udc_stop
disables the module completely (put IP in reset state,
cut functional and interface clocks, and so on), which
prevents us from accessing the IP's address space,
thus creating the possibility of an abort exception
when we try to access IP's address space after clocks
are off.

Cc: stable@vger.kernel.org
Signed-off-by: NPartha Basak <p-basak2@ti.com>
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

pm_runtime_enable is being called after omap2430_musb_init. Hence
pm_runtime_get_sync in omap2430_musb_init does not have any effect (does
not enable clocks) resulting in a crash during register access. It is
fixed here.

Cc: stable@vger.kernel.org # v3.0, v3.1, v3.2, v3.3
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

musb can be suspended at the time some other driver wants to do ulpi
transfers using usb_phy_io_* functions, and that can cause data abort,
as it happened with isp1704_charger:
http://article.gmane.org/gmane.linux.kernel/1226122

Add pm_runtime to ulpi functions to rectify this. This also adds io_dev
to usb_phy so that pm_runtime_* functions can be used.

Cc: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Control transfers with data expected from device to host will use usb_rcvctrlpipe()
for urb->pipe so for such urbs 'is_in' will be set causing control urb to fall
into the first "if" condition in musb_cleanup_urb().

Fixed by adding logic to check for non control endpoints.
Signed-off-by: NAjay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

make module init & exit __init & __exit
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

clear FFS_FL_BOUND flag on unbind (bugfix)
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Array should be freed together with event buffers, since it was
allocated dynamically.
Signed-off-by: NAnton Tikhomirov <av.tikhomirov@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

DMA address register shouldn't be updated manually if transfer size
requires multiple packets.
Signed-off-by: NAnton Tikhomirov <av.tikhomirov@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Writing to TxFIFO relates only to Slave mode and leads to
TxFIFO corruption in DMA mode.
Signed-off-by: NAnton Tikhomirov <av.tikhomirov@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

MPS field of DOEPCTL0 is read only.
Signed-off-by: NAnton Tikhomirov <av.tikhomirov@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

According to documentation, TX FIFO_number index starts from 1.
For IN endpoint FIFO 0 we use GNPTXFSIZ register for programming
the size and memory start address.
Signed-off-by: NAnton Tikhomirov <av.tikhomirov@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

- For Control Read transfer, the ACK handshake on an IN transaction
may be corrupted, so the device may not receive the ACK for data
stage, the complete irq will not occur at this situation.
Therefore, we need to move prime status stage from complete irq
routine to the place where the data stage has just primed, or the
host will never get ACK for status stage.
The above issue has been described at USB2.0 spec chapter 8.5.3.3.

- After adding prime status stage just after prime the data stage,
there is a potential problem when the status dTD is added before the data stage
has primed by hardware. The reason is the device's dTD descriptor has NO direction bit,
if data stage (IN) prime hasn't finished, the status stage(OUT)
dTD will be added at data stage dTD's Next dTD Pointer, so when the data stage
transfer has finished, the status dTD will be primed as IN by hardware,
then the host will never receive ACK from the device side for status stage.

- Delete below code at fsl_ep_queue:
       /* Update ep0 state */
       if ((ep_index(ep) == 0))
               udc->ep0_state = DATA_STATE_XMIT;
the udc->ep0_state will be updated again after udc->driver->setup
finishes.

It is tested at i.mx51 bbg board with g_mass_storage, g_ether, g_serial.
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

When runtime_pm was originally added, it was done in rather confusing
way: omap2430_musb_init() (called from musb_init_controller) would do
runtime_pm_get_sync() and musb_init_controller() itself would do
runtime_pm_put to balance it out. This is not only confusing but also
wrong if non-omap2430 glue layer is used.

This confusion resulted in commit 772aed45 "usb: musb: fix
pm_runtime mismatch", that removed runtime_pm_put() from
musb_init_controller as that looked unbalanced, and also happened to
fix unrelated isp1704_charger crash. However this broke runtime PM
functionality (musb is now always powered, even without gadget active).

Avoid these confusing runtime pm dependences by making
musb_init_controller() and omap2430_musb_init() do their own runtime
get/put pairs; also cover error paths. Remove unneeded runtime_pm_put
in omap2430_remove too. isp1704_charger crash that motivated
772aed45 will be fixed by following patch.

Cc: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This change prevents runtime suspend and resume actual execution, if
omap2430 controller driver is loaded after musb-hdrc, and therefore the
controller isn't initialized properly.

The problem is reproducible with 3.1.y and 3.2 kernels.

Kernel configuration of musb:

  % cat .config | egrep 'MUSB|GADGET'
  CONFIG_USB_MUSB_HDRC=y
  # CONFIG_USB_MUSB_TUSB6010 is not set
  CONFIG_USB_MUSB_OMAP2PLUS=m
  # CONFIG_USB_MUSB_AM35X is not set
  CONFIG_MUSB_PIO_ONLY=y
  CONFIG_USB_GADGET=y
  # CONFIG_USB_GADGET_DEBUG is not set
  # CONFIG_USB_GADGET_DEBUG_FILES is not set
  # CONFIG_USB_GADGET_DEBUG_FS is not set
  CONFIG_USB_GADGET_VBUS_DRAW=2
  CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2
  CONFIG_USB_GADGET_MUSB_HDRC=m
  CONFIG_USB_GADGET_DUALSPEED=y
  CONFIG_USB_GADGETFS=m
  # CONFIG_USB_MIDI_GADGET is not set

Fixes the following oops on module unloading:

  Unable to handle kernel NULL pointer dereference at virtual address 00000220
  ----8<----
  [<bf162088>] (omap2430_runtime_resume+0x24/0x54 [omap2430]) from [<c0302e34>] (pm_generic_runtime_resume+0x3c/0x50)
  [<c0302e34>] (pm_generic_runtime_resume+0x3c/0x50) from [<c0031a24>] (_od_runtime_resume+0x28/0x2c)
  [<c0031a24>] (_od_runtime_resume+0x28/0x2c) from [<c0306cb0>] (__rpm_callback+0x60/0xa0)
  [<c0306cb0>] (__rpm_callback+0x60/0xa0) from [<c0307f2c>] (rpm_resume+0x3fc/0x6e4)
  [<c0307f2c>] (rpm_resume+0x3fc/0x6e4) from [<c030851c>] (__pm_runtime_resume+0x5c/0x90)
  [<c030851c>] (__pm_runtime_resume+0x5c/0x90) from [<c02fd0dc>] (__device_release_driver+0x2c/0xd0)
  [<c02fd0dc>] (__device_release_driver+0x2c/0xd0) from [<c02fda18>] (driver_detach+0xe8/0xf4)
  [<c02fda18>] (driver_detach+0xe8/0xf4) from [<c02fcf88>] (bus_remove_driver+0xa0/0x104)
  [<c02fcf88>] (bus_remove_driver+0xa0/0x104) from [<c02fde54>] (driver_unregister+0x60/0x80)
  [<c02fde54>] (driver_unregister+0x60/0x80) from [<c02ff2d4>] (platform_driver_unregister+0x1c/0x20)
  [<c02ff2d4>] (platform_driver_unregister+0x1c/0x20) from [<bf162928>] (omap2430_exit+0x14/0x1c [omap2430])
  [<bf162928>] (omap2430_exit+0x14/0x1c [omap2430]) from [<c007d8bc>] (sys_delete_module+0x1f4/0x264)
  [<c007d8bc>] (sys_delete_module+0x1f4/0x264) from [<c000f000>] (ret_fast_syscall+0x0/0x30)
Signed-off-by: NVladimir Zapolskiy <vladimir.zapolskiy@nokia.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org # 3.1
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Without this default case returning an error,
thus replying with a stall, we would fail
USB30CV TD 9.11 Bad Feature test case.

Cc: stable@vger.kernel.org
Signed-off-by: NGerard Cauvy <g-cauvy1@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

due to a HW limitation we have a bounce buffer for ep0
out transfers which are not aligned with MaxPacketSize.

On such case we were not increment r->actual as we should.

This patch fixes that mistake.

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

To allow ep0 out transfers of upto bounce buffer size
instead of maxpacketsize, use the transfer size as multiple
of ep0 maxpacket size.

Cc: stable@vger.kernel.org
Signed-off-by: NMoiz Sonasath <m-sonasath@ti.com>
Signed-off-by: NPartha Basak <p-basak2@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

When we want to do device-initiated disconnect,
let's make sure we stop the UDC in order to
e.g. allow lower power states to be achieved by
turning off unnecessary clocks and/or stoping
PHYs.

When reconnecting, call ->udc_start() again to
make sure UDC is reinitialized.

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

This patch (as1538) causes uhci_hub_status_data() to return a nonzero
value when any port is undergoing a resume transition while the root
hub is suspended.  This will allow usbcore to handle races between
root-hub suspend and port wakeup.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>