linux.git/drivers/usb/musb, branch v3.0.48

usb: musb: omap: fix the error check for pm_runtime_get_sync

2012-04-27T16:51:08+00:00

commit ad579699c4f0274bf522a9252ff9b20c72197e48 upstream.

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:  Kishon Vijay Abraham I 
Signed-off-by: Shubhrajyoti D 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

usb: musb: omap: fix crash when musb glue (omap) gets initialized

2012-04-27T16:51:08+00:00

commit 3006dc8c627d738693e910c159630e4368c9e86c upstream.

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.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

usb: musb: Reselect index reg in interrupt context

2012-04-02T16:26:52+00:00

commit 39287076e46d2c19aaceaa6f0a44168ae4d257ec upstream.

musb INDEX register is getting modified/corrupted during temporary
un-locking in a SMP system. Set this register with proper value
after re-acquiring the lock

Scenario:
---------
CPU1 is handling a data transfer completion interrupt received for
the CLASS1 EP
CPU2 is handling a CLASS2 thread which is queuing data to musb for
transfer

Below is the error sequence:

         CPU1                   |             CPU2
--------------------------------------------------------------------
Data transfer completion inter- |
rupt recieved.                  |
                                |
musb INDEX reg set to CLASS1 EP |
                                |
musb LOCK is acquired.          |
                                |
                                | CLASS2 thread queues data.
                                |
                                | CLASS2 thread tries to acquire musb
                                | LOCK but lock is already taken by
                                | CLASS1, so CLASS2 thread is
                                | spinning.
                                |
From Interrupt Context musb     |
giveback function is called     |
                                |
The giveback function releases  | CLASS2 thread now acquires LOCK
LOCK                            |
                                |
ClASS1 Request's completion cal-| ClASS2 schedules the data transfer and
lback is called                 | sets the MUSB INDEX to Class2 EP number
                                |
Interrupt handler for CLASS1 EP |
tries to acquire LOCK and is    |
spinning                        |
                                |
Interrupt for Class1 EP acquires| Class2 completes the scheduling etc and
the MUSB LOCK                   | releases the musb LOCK
                                |
Interrupt for Class1 EP schedul-|
es the next data transfer       |
but musb INDEX register is still|
set to CLASS2 EP                |

Since the MUSB INDEX register is set to a different endpoint, we
read and modify the wrong registers. Hence data transfer will not
happen properly. This results in unpredictable behavior

So, the MUSB INDEX register is set to proper value again when
interrupt re-acquires the lock

Signed-off-by: Supriya Karanth 
Signed-off-by: Praveena Nadahally 
Reviewed-by: srinidhi kasagar 
Signed-off-by: Felipe Balbi

usb: musb: fix pm_runtime mismatch

2012-01-12T19:35:16+00:00

commit 772aed45b604c5ff171f0f12c12392d868333f79 upstream.

In musb_init_controller() there's a pm_runtime_put(), but there's no
pm_runtime_get(), which creates a mismatch that causes the driver to
sleep when it shouldn't.

This was introduced in 7acc619[1], but it wasn't triggered in my setup
until 18a2689[2] was merged to Linus' branch at point df0914[3]. IOW;
when PM is working as it was supposed to.

However, it seems most of the time this is used in a way that keeps the
counter above 0, so nobody noticed. Also, it seems to depend on the
configuration used in versions before 3.1, but not later (or in it).

I found the problem by loading isp1704_charger before any usb gadgets:
http://article.gmane.org/gmane.linux.kernel/1226122

All versions after 2.6.39 are affected.

[1] usb: musb: Idle path retention and offmode support for OMAP3
[2] OMAP2+: musb: hwmod adaptation for musb registration
[3] Merge branch 'omap-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6

Cc: Hema HK 
Signed-off-by: Felipe Contreras 
Signed-off-by: Felipe Balbi

usb: musb: cppi: fix build errors due to DBG and missing musb variable

2011-10-03T18:39:51+00:00

commit f847a79ab3c1faca3022061045cd22e4678c1b1c upstream.

Replace DBG with dev_dbg and fix invalid access of musb->controller.
With this patch cppi_dma builds successfully.

Signed-off-by: Per Forlin 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

usb: musb: fix oops on musb_gadget_pullup

2011-08-17T17:55:51+00:00

commit 72c487dfb94d02025fb7437dfe2314d836d5a9ab upstream.

an 'unhandled fault' is causes when a gadget driver calls
usb_gadget_connect() while the USB cable isn't plugged into
the OTG port.

the fault is caused by an access to MUSB's memory space
while its clock is turned off due to pm_runtime kicking
in.

in order to fix the fault, we enclose musb_gadget_pullup()
with pm_runtime_get_sync() ... pm_runtime_put() calls to
be sure we will always reach that path with clock turned on.

[ balbi@ti.com : simplified commit log; removed few things
	which didn't belong there ]

Reported-by: Zach Pfeffer 
Signed-off-by: John Stultz 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

usb: musb: restore INDEX register in resume path

2011-08-05T04:58:32+00:00

commit 3c5fec75e121b21a2eb35e5a6b44291509abba6f upstream.

Restoring the missing INDEX register value in musb_restore_context().
Without this suspend resume functionality is broken with offmode
enabled.

Acked-by: Anand Gadiyar 
Signed-off-by: Ajay Kumar Gupta 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

usb: musb: gadget: clear TXPKTRDY flag when set FLUSHFIFO

2011-06-09T09:01:03+00:00

Fixes mis-use of MUSB's hardware feature where it won't
flush FIFOs when TXPKTRDY flag was set before and we are
flushing setting both FLUSHFIFO and TXPKTRDY.

In other words, we need to ensure that when we try to
flush FIFOs, we don't accidentaly set TXPKTRDY bit too
due to a read-back of the register.

The MUSB Programming Guide says "May be set simultaneously
with TxPktRdy to abort the packet that is currently being
loaded into the FIFO". This is a situation where TXPKTRDY
hasn't been set yet, but some data already loaded into the
fifo. It looks, that if TXPKTRDY has been set before, and
there is no loading in progress, but we set FLUSHFIFO with
the TXPKTRDY, controller tries to use the same logic to
abort loading and as the result just does nothing (because
there is no packet been loaded currently)

Signed-off-by: Yauheni Kaliuta 

[ balbi@ti.com : fixed one whitespace git complained about
		 improved the commit log slightly ]

Signed-off-by: Felipe Balbi

usb: musb: host: compare status for negative error values

2011-06-09T09:01:03+00:00

Variable d is a struct usb_iso_packet_descriptor. The status filed is usually
negative when an error happens.

Signed-off-by: Márton Németh 
Signed-off-by: Felipe Balbi

musb: fix prefetch build failure

2011-06-06T23:02:31+00:00

After the prefetch/list.h restructure, drivers need to explicitly include
linux/prefetch.h in order to use the prefetch() function.  Otherwise, the
current driver fails to build:

drivers/usb/musb/musb_core.c: In function 'musb_write_fifo':
drivers/usb/musb/musb_core.c:219: error: implicit declaration of function 'prefetch'
make[3]: *** [drivers/usb/musb/musb_core.o] Error 1

Signed-off-by: Mike Frysinger 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman