linux.git/drivers/usb/musb, branch v4.9

usb: musb: Drop pointless PM runtime code for dsps glue

2016-11-17T15:25:40+00:00

This already gets done automatically by PM runtime and we have
a separate autosuspend timeout in musb_core.c.

Reviewed-by: Johan Hovold 
Tested-by: Laurent Pinchart 
Signed-off-by: Tony Lindgren 
Signed-off-by: Bin Liu 
Signed-off-by: Greg Kroah-Hartman

usb: musb: Add missing pm_runtime_disable and drop 2430 PM timeout

2016-11-17T15:25:39+00:00

We are missing pm_runtime_disable() in 2430 glue layer. Further,
we only need to enable PM runtime and disable it on exit. With
musb_core.c doing PM, the glue layer as a parent will always be
active when musb_core.c is active.

This fixes host enumeration issues with some devices as reported
by Ladislav Michl .

And holding an RPM reference while deregistering the child would
lead to a crash in omap2430_runtime_suspend() which dereferences
the now freed child's driver data on put as pointed out by
Johan Hovold :

Unable to handle kernel paging request at virtual address 6b6b6f17
...
[] (omap2430_runtime_suspend) from []
 (pm_generic_runtime_suspend+0x3c/0x48)
[] (pm_generic_runtime_suspend) from []
 (_od_runtime_suspend+0x1c/0x30)
[] (_od_runtime_suspend) from [] (__rpm_callback+0x3c/0x70)
[] (__rpm_callback) from [] (rpm_callback+0x30/0x90)
[] (rpm_callback) from [] (rpm_suspend+0x118/0x6b4)
[] (rpm_suspend) from [] (rpm_idle+0x104/0x440)
[] (rpm_idle) from [] (__pm_runtime_idle+0x7c/0xb0)
[] (__pm_runtime_idle) from [] (omap2430_remove+0x38/0x58)
[] (omap2430_remove) from [] (platform_drv_remove+0x34/0x4c)

Note that if changes are needed to the autosuspend timeout, it should
be done in musb_core.c.

Reported-by: Ladislav Michl 
Fixes: 87326e858448 ("usb: musb: Remove extra PM runtime calls from
2430 glue layer")
Tested-by: Ladislav Michl 
Reviewed-by: Johan Hovold 
Tested-by: Laurent Pinchart 
Signed-off-by: Tony Lindgren 
Signed-off-by: Bin Liu 
Signed-off-by: Greg Kroah-Hartman

usb: musb: Fix PM for hub disconnect

2016-11-17T15:25:39+00:00

With a USB hub disconnected, devctl can be 0x19 for about a second
on am335x and will stay forever on at least omap3. And we get no
further interrupts when devctl session bit clears. This keeps
PM runtime active.

Let's fix the issue by polling devctl until the session bit clears
or times out. We can do this by making musb->irq_work into
delayed_work.

And with the polling implemented, we can now also have the quirk
for invalid VBUS it to avoid disconnecting too early while VBUS
is ramping up.

Fixes: 467d5c980709 ("usb: musb: Implement session bit based runtime
PM for musb-core")
Fixes: 65b3f50ed6fa ("usb: musb: Add PM runtime support for MUSB DSPS
Tested-by: Ladislav Michl 
Tested-by: Laurent Pinchart 
Signed-off-by: Tony Lindgren 
Signed-off-by: Bin Liu 
Signed-off-by: Greg Kroah-Hartman

usb: musb: Fix sleeping function called from invalid context for hdrc glue

2016-11-17T15:25:39+00:00

Commit 65b3f50ed6fa ("usb: musb: Add PM runtime support for MUSB DSPS
glue layer") wrongly added a call for pm_runtime_get_sync to otg_timer
that runs in softirq context. That causes a "BUG: sleeping function called
from invalid context" every time when polling the cable status:

[] (__might_sleep) from [] (__pm_runtime_resume+0x9c/0xa0)
[] (__pm_runtime_resume) from [] (otg_timer+0x3c/0x254)
[] (otg_timer) from [] (call_timer_fn+0xfc/0x41c)
[] (call_timer_fn) from [] (expire_timers+0x120/0x210)
[] (expire_timers) from [] (run_timer_softirq+0xa4/0xdc)
[] (run_timer_softirq) from [] (__do_softirq+0x12c/0x594)

I did not notice that as I did not have CONFIG_DEBUG_ATOMIC_SLEEP enabled.
And looks like also musb_gadget_queue() suffers from the same problem.

Let's fix the issue by using a list of delayed work then call it on
resume. Note that we want to do this only when musb core and it's
parent devices are awake, and we need to make sure the DSPS glue
timer is stopped as noted by Johan Hovold .
Note that we already are re-enabling the timer with mod_timer() in
dsps_musb_enable().

Later on we may be able to remove other delayed work in the musb driver
and just do it from pending_resume_work. But this should be done only
for delayed work that does not have other timing requirements beyond
just being run on resume.

Fixes: 65b3f50ed6fa ("usb: musb: Add PM runtime support for MUSB DSPS
glue layer")
Reported-by: Johan Hovold 
Reviewed-by: Johan Hovold 
Tested-by: Laurent Pinchart 
Signed-off-by: Tony Lindgren 
Signed-off-by: Bin Liu 
Signed-off-by: Greg Kroah-Hartman

usb: musb: Fix broken use of static variable for multiple instances

2016-11-17T15:25:39+00:00

We can't use static variable first for checking when musb is
initialized when we have multiple musb instances like on am335x.

Tested-by: Ladislav Michl 
Reviewed-by: Johan Hovold 
Tested-by: Laurent Pinchart 
Signed-off-by: Tony Lindgren 
Signed-off-by: Bin Liu 
Signed-off-by: Greg Kroah-Hartman

usb: musb: remove duplicated actions

2016-11-07T09:10:25+00:00

Removing unnecessary duplicated actions that we've got while merging:
Commit 19915e623458 ("Merge 4.1-rc7 into usb-next")

[ b-liu@ti.com: added 'Commit' in the commit message ]

Signed-off-by: Kirill Esipov 
Signed-off-by: Bin Liu 
Signed-off-by: Greg Kroah-Hartman

usb: musb: da8xx: Don't print phy error on -EPROBE_DEFER

2016-11-07T09:10:24+00:00

This suppresses printing the error message "failed to get phy" in the
kernel log when the error is -EPROBE_DEFER. This prevents usless noise
in the kernel log.

Signed-off-by: David Lechner 
Signed-off-by: Bin Liu 
Signed-off-by: Greg Kroah-Hartman

usb: musb: Call pm_runtime from musb_gadget_queue

2016-10-24T12:29:08+00:00

If we're booting pandaboard using NFSroot over built-in g_ether, we
can get the following after booting once and doing a warm reset:

g_ether gadget: ecm_open
g_ether gadget: notify connect true
...
WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147
l3_interrupt_handler+0x220/0x34c
44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4CFG (Read):
Data Access in User mode du ring Functional access
...

Fix the issue by calling pm_runtime functions from
musb_gadget_queue.

Note that in the long run we should be able to queue the pending
transfers if pm_runtime is not active, and flush the queue from
pm_runtime_resume.

Reported-by: Laurent Pinchart 
Tested-by: Laurent Pinchart 
Signed-off-by: Tony Lindgren 
Signed-off-by: Bin Liu 
Signed-off-by: Greg Kroah-Hartman

usb: musb: Fix hardirq-safe hardirq-unsafe lock order error

2016-10-24T12:29:08+00:00

If we configure musb with 2430 glue as a peripheral, and then rmmod
omap2430 module, we'll get the following error:

[ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
...
rmmod/413 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
 (&phy->mutex){+.+.+.}, at: [] phy_power_off+0x1c/0xb8
[  204.678710]
               and this task is already holding:
 (&(&musb->lock)->rlock){-.-...}, at: []
 musb_gadget_stop+0x24/0xec [musb_hdrc]
which would create a new lock dependency:
 (&(&musb->lock)->rlock){-.-...} -> (&phy->mutex){+.+.+.}
...

This is because some glue layers expect musb_platform_enable/disable
to be called with spinlock held, and 2430 glue layer has USB PHY on
the I2C bus using a mutex.

We could fix the glue layers to take the spinlock, but we still have
a problem of musb_plaform_enable/disable being called in an unbalanced
manner. So that would still lead into USB PHY enable/disable related
problems for omap2430 glue layer.

While it makes sense to only enable USB PHY when needed from PM point
of view, in this case we just can't do it yet without breaking things.
So let's just revert phy_enable/disable related changes instead and
reconsider this after we have fixed musb_platform_enable/disable to
be balanced.

Fixes: a83e17d0f73b ("usb: musb: Improve PM runtime and phy handling for 2430 glue layer")
Reviewed-by: Laurent Pinchart 
Signed-off-by: Tony Lindgren 
Signed-off-by: Bin Liu 
Signed-off-by: Greg Kroah-Hartman

usb: musb: da8xx: fix error handling message in probe

2016-09-23T10:26:07+00:00

We print an error message when platform_device_register_full()
fails, but the initialization of the argument has been removed,
as shown in this warning:

drivers/usb/musb/da8xx.c: In function 'da8xx_probe':
drivers/usb/musb/da8xx.c:521:3: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized]

This modifies the function to assign the return code before
checking it, and does uses the same method in the check for
usb_phy_generic_register() as well.

Fixes: 947c49afe41f ("usb: musb: da8xx: Remove mach code")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Bin Liu 
Signed-off-by: Greg Kroah-Hartman