linux-toradex.git/drivers, branch v3.12.2

usb: musb: core: properly free host / device structs in err path

2013-11-29T19:28:12+00:00

commit 0d2dd7eaed1dac07b266ca2c662ff4a184a3060f upstream.

The patch fixes two issues in the error path cleanup:
- in MUSB_PORT_MODE_DUAL_ROLE mode, if musb_gadget_setup() fails we
  never cleanup the host struct earlier allocated.
- if musb_init_debugfs() or sysfs_create_group() fails, then we never
  free the host part initialization, only device part.

Cc: Daniel Mack 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

usb: musb: dsps: redo the otg timer

2013-11-29T19:28:11+00:00

commit 0f901c980110cd69b63670096465b35377e73b1c upstream.

According to the comments, we rely on the OTG timer because the core
does not expose some important OTG details. So far this is all I
know. After playing with OTG I stumbled over a problem:
musb is recognized as a B-device without a problem. Whenever a cable is
plugged, the VBUS rises, musb recognizes this as a starting session,
sets the MUSB_DEVCTL_SESSION bit by itself and a RESET interrupt occurs,
the session starts. Good.
After a disconnect, the timer is started and re-starts itself because
it remains in B_IDLE with the BDEVICE set. I didn't figure the the
reason or the need for it. Nothing changes here except for OTG state
from B to A device if the BDEVICE bit disappears. This doesn't make much
sense to me because nothing happens after this. _IF_ we receive an
interrupt before the state change then we may act on wrong condition.
Plugging a B-device (and letting MUSB act as host) doesn't work here.
The reason seems to be that the MUSB tries to start a session, it fails
and then it removes the bit. So we never start as a host.

This patch sets the MUSB_DEVCTL_SESSION bit in the IDLE state so musb
can try to establish a session as host. After the bit is set, musb tries
to start a session and if it fails it clears the bit. Therefore it will
try over and over again until a session either as host or as device is
established.

The readout of the MUSB_DEVCTL register after the removal the
MUSB_DEVCTL_SESSION (in A_WAIT_BCON) has been removed because it did not
contain the BDEVICE bit set (in the second read) leading to A_IDLE. After
plugging a host musb assumed that it is also a host and complained about
a missing reset. However a third read of the register has has the BDEVICE
bit set so it seems that it is not stable.
This mostly what da8xx.c is doing except that we set the timer also
after A_WAIT_BCON so the session bit can be triggered.

Whit this change I was able to keep am335x-evm in OTG mode and plug in
either a HOST or a DEVICE and in a random order and the device was
recognized.

Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

usb: musb: dsps: move try_idle to start hook

2013-11-29T19:28:11+00:00

commit 8b9fcce2d88586b9a120ff3e039d8f42413f0bb0 upstream.

The timer is initialized right after musb is probed. There is actually
no need to have this timer running because _nothing_ will happen until
we have the gadget loaded. Also we need this timer only if we run in OTG
mode _and_ we need it also after the gadget has been replaced with
another one.

I've been looking at am35x.c, da8xx.c, omap2430.c, tusb6010.c. da8xx
seem to have the same problem as dsps and doing mostly the same thing.
tusb6010 seem to do something different and do some actual "idle / power
saving" work so I am not too comfortable to remove
musb_platform_try_idle() from musb_gadget_setup().

Therefore this patch does not start the timer if there is no gadget
active (which is at musb_gadget_setup() at time). In order to have the
timer active after the gadget is loaded it will be triggered from
dsps_musb_enable().

Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

usb: musb: call musb_start() only once in OTG mode

2013-11-29T19:28:11+00:00

commit ae44df2e21b50f9fff28ac75c57e399c04df812c upstream.

In commit 001dd84 ("usb: musb: start musb on the udc side, too") it was
ensured that the state engine is started also in OTG mode after a
removal / insertion of the gadget.
Unfortunately this change also introduced a bug: If the device is
configured as OTG and it connected with a remote host _without_ loading
a gadget then we bug() later (because musb->otg->gadget is not
initialized).
Initially I assumed it might be nice to have the host part of musb in
OTG mode working without having a gadget loaded. This bug and fact that
it wasn't working like this before the host/gadget split made me realize
that this was a silly idea.
This patch now introduces back the old behavior where in OTG mode the
host mode is only working after the gadget has been loaded.

Cc: Daniel Mack 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

usb: musb: cancel work on removal

2013-11-29T19:28:11+00:00

commit c5340bd14336b902604ab95212a8877de109d9ae upstream.

So I captured this:

|WARNING: CPU: 0 PID: 2078 at /home/bigeasy/work/new/TI/linux/lib/debugobjects.c:260 debug_print_object+0x94/0xc4()
|ODEBUG: free active (active state 0) object type: work_struct hint: musb_irq_work+0x0/0x38 [musb_hdrc]
|CPU: 0 PID: 2078 Comm: rmmod Not tainted 3.12.0-rc4+ #338
|[] (unwind_backtrace+0x0/0xf4) from [] (show_stack+0x14/0x1c)
|[] (show_stack+0x14/0x1c) from [] (warn_slowpath_common+0x64/0x84)
|[] (warn_slowpath_common+0x64/0x84) from [] (warn_slowpath_fmt+0x30/0x40)
|[] (warn_slowpath_fmt+0x30/0x40) from [] (debug_print_object+0x94/0xc4)
|[] (debug_print_object+0x94/0xc4) from [] (debug_check_no_obj_freed+0x1c0/0x228)
|[] (debug_check_no_obj_freed+0x1c0/0x228) from [] (kfree+0xf8/0x228)
|[] (kfree+0xf8/0x228) from [] (release_nodes+0x1a8/0x248)
|[] (release_nodes+0x1a8/0x248) from [] (__device_release_driver+0x98/0xf0)
|[] (__device_release_driver+0x98/0xf0) from [] (device_release_driver+0x24/0x34)
|[] (device_release_driver+0x24/0x34) from [] (bus_remove_device+0x148/0x15c)
|[] (bus_remove_device+0x148/0x15c) from [] (device_del+0x104/0x1c0)
|[] (device_del+0x104/0x1c0) from [] (platform_device_del+0x18/0xac)
|[] (platform_device_del+0x18/0xac) from [] (platform_device_unregister+0xc/0x18)
|[] (platform_device_unregister+0xc/0x18) from [] (dsps_remove+0x20/0x4c [musb_dsps])
|[] (dsps_remove+0x20/0x4c [musb_dsps]) from [] (platform_drv_remove+0x1c/0x24)
|[] (platform_drv_remove+0x1c/0x24) from [] (__device_release_driver+0x90/0xf0)
|[] (__device_release_driver+0x90/0xf0) from [] (driver_detach+0xb4/0xb8)
|[] (driver_detach+0xb4/0xb8) from [] (bus_remove_driver+0x98/0xec)
|[] (bus_remove_driver+0x98/0xec) from [] (SyS_delete_module+0x1e0/0x24c)
|[] (SyS_delete_module+0x1e0/0x24c) from [] (ret_fast_syscall+0x0/0x48)
|---[ end trace d79045419a3e51ec ]---

The workqueue is only scheduled from the ep0 and never canceled in case
the musb is removed before the work has a chance to run.

Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

rt2800usb: slow down TX status polling

2013-11-29T19:28:11+00:00

commit 36165fd5b00bf8163f89c21bb16a3e9834555b10 upstream.

Polling TX statuses too frequently has two negative effects. First is
randomly peek CPU usage, causing overall system functioning delays.
Second bad effect is that device is not able to fill TX statuses in
H/W register on some workloads and we get lot of timeouts like below:

ieee80211 phy4: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2
ieee80211 phy4: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2
ieee80211 phy4: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping

This not only cause flood of messages in dmesg, but also bad throughput,
since rate scaling algorithm can not work optimally.

In the future, we should probably make polling interval be adjusted
automatically, but for now just increase values, this make mentioned
problems gone.

Resolve:
https://bugzilla.kernel.org/show_bug.cgi?id=62781

Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

usb: wusbcore: set the RPIPE wMaxPacketSize value correctly

2013-11-29T19:28:11+00:00

commit 7b6bc07ab554e929c85d51b3d5b26cf7f12c6a3b upstream.

For isochronous endpoints, set the RPIPE wMaxPacketSize value using
wOverTheAirPacketSize from the endpoint companion descriptor instead of
wMaxPacketSize from the normal endpoint descriptor.

Signed-off-by: Thomas Pugliese 
Signed-off-by: Greg Kroah-Hartman

usb: hub: Clear Port Reset Change during init/resume

2013-11-29T19:28:10+00:00

commit e92aee330837e4911553761490a8fb843f2053a6 upstream.

This patch adds the Port Reset Change flag to the set of bits that are
preemptively cleared on init/resume of a hub. In theory this bit should
never be set unexpectedly... in practice it can still happen if BIOS,
SMM or ACPI code plays around with USB devices without cleaning up
correctly. This is especially dangerous for XHCI root hubs, which don't
generate any more Port Status Change Events until all change bits are
cleared, so this is a good precaution to have (similar to how it's
already done for the Warm Port Reset Change flag).

Signed-off-by: Julius Werner 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

usb: Disable USB 2.0 Link PM before device reset.

2013-11-29T19:28:10+00:00

commit dcc01c0864823f91c3bf3ffca6613e2351702b87 upstream.

Before the USB core resets a device, we need to disable the L1 timeout
for the roothub, if USB 2.0 Link PM is enabled.  Otherwise the port may
transition into L1 in between descriptor fetches, before we know if the
USB device descriptors changed.  LPM will be re-enabled after the
full device descriptors are fetched, and we can confirm the device still
supports USB 2.0 LPM after the reset.

We don't need to wait for the USB device to exit L1 before resetting the
device, since the xHCI roothub port diagrams show a transition to the
Reset state from any of the Ux states (see Figure 34 in the 2012-08-14
xHCI specification update).

This patch should be backported to kernels as old as 3.2, that contain
the commit 65580b4321eb36f16ae8b5987bfa1bb948fc5112 "xHCI: set USB2
hardware LPM".  That was the first commit to enable USB 2.0
hardware-driven Link Power Management.

Signed-off-by: Sarah Sharp 
Signed-off-by: Greg Kroah-Hartman

xhci: Set L1 device slot on USB2 LPM enable/disable.

2013-11-29T19:28:10+00:00

commit 58e21f73975ec927119370635bf68b9023831c56 upstream.

To enable USB 2.0 Link Power Management (LPM), the xHCI host controller
needs the device slot ID to generate the device address used in L1 entry
tokens.  That information is set in the L1 device slot ID field of the
USB 2.0 LPM registers.

Currently, the L1 device slot ID is overwritten when the xHCI driver
initiates the software test of USB 2.0 Link PM in
xhci_usb2_software_lpm_test.  It is never cleared when USB 2.0 Link PM
is disabled for the device.  That should be harmless, because the
Hardware LPM Enable (HLE) bit is cleared when USB 2.0 Link PM is
disabled, so the host should not pay attention to the slot ID.

This patch should have no effect on host behavior, but since
xhci_usb2_software_lpm_test is going away in an upcoming bug fix patch,
we need to move that code to the function that enables and disables USB
2.0 Link PM.

This patch should be backported to kernels as old as 3.11, that contain
the commit a558ccdcc71c7770c5e80c926a31cfe8a3892a09 "usb: xhci: add USB2
Link power management BESL support".  The upcoming bug fix patch is also
marked for that stable kernel.

Signed-off-by: Sarah Sharp 
Signed-off-by: Greg Kroah-Hartman