This allows setting the correct fifo_mode when multiple
MUSB glue layers are built-in.

Cc: Fabio Baltieri <fabio.baltieri@linaro.org>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: NApelete Seketeli <apelete@seketeli.net>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This allows the endpoints to work when multiple MUSB glue
layers are built in.

Cc: Fabio Baltieri <fabio.baltieri@linaro.org>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NApelete Seketeli <apelete@seketeli.net>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Change to use new IO access. This allows us to build in multiple
MUSB glue layers.

[ balbi@ti.com : switch to EXPORT_SYMBOL_GPL()
	fix long lines ]

Cc: Fabio Baltieri <fabio.baltieri@linaro.org>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Disable the MUSB interrupts till MUSB is recovered fully from BABBLE
condition. There are chances that we could get multiple interrupts
till the time the babble recover work gets scheduled. Sometimes
this could even end up in an endless loop making MUSB itself unusable.
Reported-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGeorge Cherian <george.cherian@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

On am335x-evm with musb in host mode and using it as a wakeup source the
following happens once the CPU comes out of suspend to ram:
|PM: Wakeup source MPU_WAKE
|PM: noirq resume of devices complete after 15.453 msecs
|PM: early resume of devices complete after 2.222 msecs
|PM: resume of devices complete after 507.351 msecs
|Restarting tasks ...
|------------[ cut here ]------------
|WARNING: CPU: 0 PID: 322 at drivers/usb/core/urb.c:339 usb_submit_urb+0x494/0x4c8()
|URB cc0db380 submitted while active
|[<c0348e64>] (usb_submit_urb) from [<c0340f94>] (hub_activate+0x2b8/0x49c)
|[<c0340f94>] (hub_activate) from [<c03411dc>] (hub_resume+0x14/0x1c)
|[<c03411dc>] (hub_resume) from [<c034be10>] (usb_resume_interface.isra.4+0xdc/0x110)
|[<c034be10>] (usb_resume_interface.isra.4) from [<c034beb0>] (usb_resume_both+0x6c/0x13c)
|[<c034beb0>] (usb_resume_both) from [<c034cca4>] (usb_runtime_resume+0x10/0x14)
|[<c034cca4>] (usb_runtime_resume) from [<c02bbd80>] (__rpm_callback+0x2c/0x60)
|[<c02bbd80>] (__rpm_callback) from [<c02bbdd4>] (rpm_callback+0x20/0x74)
|[<c02bbdd4>] (rpm_callback) from [<c02bcc48>] (rpm_resume+0x380/0x548)
|[<c02bcc48>] (rpm_resume) from [<c02bcb00>] (rpm_resume+0x238/0x548)
|[<c02bcb00>] (rpm_resume) from [<c02bd08c>] (__pm_runtime_resume+0x64/0x94)
|[<c02bd08c>] (__pm_runtime_resume) from [<c034b5a4>] (usb_autopm_get_interface+0x18/0x5c)
|[<c034b5a4>] (usb_autopm_get_interface) from [<c03438b8>] (hub_thread+0x10c/0x115c)
|[<c03438b8>] (hub_thread) from [<c005a70c>] (kthread+0xbc/0xd8)
|---[ end trace 036aa5fe78203142 ]---
|hub 1-0:1.0: activate --> -16
|hub 2-0:1.0: activate --> -16

The reason for this backtrace is the attempt of the USB code to resume
the HUB twice and thus enqueue the status URB twice.
Alan Stern was a great help by explaining how the USB code supposed to
work and what is most likely the problem. The root problem is that after
resume the musb runtime-suspend state remains RPM_SUSPENDED.
According to git log it RPM was added for the omap2430 platform. If I
understand it correct the omap2430 invokes a get on musb once a cable is
connected and a put once the cable is gone. In between the device could
go auto-idle/off. Not sure what happens when the device goes into suspend
but then I guess it was gadget only.
On DSPS I see only a get in probe and put in remove function. This would
forbid RPM from working but then the devices enterns suspended state
anyway :)

To get rid of this warning, I set the device state to RPM_ACTIVE which
the expected state.

Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: <stable@vger.kernel.org>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Attaching a keyboard, using it as a wakeup via
|for f in $(find /sys/devices/ocp.3/47400000.usb -name wakeup)
|do
|	echo enabled > $f
|done

going into standby
|  echo standby >  /sys/power/state

and now a wake up by a pressing a key.
What happens is that the system wakes up but the USB device is dead. The
USB stack tries to send a few control URBs but nothing comes back.
Eventually it gaves up and the device remains dead:
|[  632.559678] PM: Wakeup source USB1_PHY
|[  632.581074] PM: noirq resume of devices complete after 21.261 msecs
|[  632.607521] PM: early resume of devices complete after 10.360 msecs
|[  632.616854] net eth2: initializing cpsw version 1.12 (0)
|[  632.704126] net eth2: phy found : id is : 0x4dd074
|[  636.704048] libphy: 4a101000.mdio:00 - Link is Up - 1000/Full
|[  638.444620] usb 1-1: reset low-speed USB device number 2 using musb-hdrc
|[  653.713435] usb 1-1: device descriptor read/64, error -110
|[  669.093435] usb 1-1: device descriptor read/64, error -110
|[  669.473424] usb 1-1: reset low-speed USB device number 2 using musb-hdrc
|[  684.743436] usb 1-1: device descriptor read/64, error -110
|[  690.065097] PM: resume of devices complete after 57450.744 msecs
|[  690.076601] PM: Finishing wakeup.
|[  690.076627] Restarting tasks ...

It seems that since we got woken up via MUSB_INTR_RESUME the
musb_host_finish_resume() callback is executed before the
resume-callbacks of the PHY and glue layer are invoked. If I delay it
until the glue layer resumed then I don't see this problem.

I also move musb_host_resume_root_hub() into that callback since I don't
see any reason in doing anything resume-link if there are still pieces
not restored.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The am335x-evmsk support two kinds of suspend:
- standby
  the USB device remains powered while the system goes into suspend

- mem
  the USB device becomes powerless while the system goes into suspend.

In the "standby" case the device resumes quickly. In the "mem" case the
system hangs for a few seconds. It seems to me that the USB-device has
no address (it was disconnected) and the USB stack thinks that it is
fully operational and GetPortStatus returns the status from before the
suspend so it is not a big help here.

This adds a check in the resume path to see if the device mode (A or B)
and the speed is the same. If the device went missing between
suspend/resume (VBUS went down) then MUSB seems to go into B mode and
HS/FS bits are cleared. In that case we clear the port1_status bits and
assume a disconnect. Once the stack learns this it does a "logical
disconnect" and removes the USB-device quickly. Should the device remain
connected during the suspend then MUSB will receives a "CONNECT" interrupt.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Before using the PHY framework instead of the USB PHY one, we need to
move the OTG state into another place, since it won't be available when
USB PHY isn't used. This patch moves the OTG state into the OTG
structure, and makes all the needed modifications in the drivers
using the OTG state.

[ balbi@ti.com : fix build regressions with phy-tahvo.c, musb_dsps.c,
		phy-isp1301-omap, and chipidea's debug.c ]
Acked-by: NKishon Vijay Abraham I <kishon@ti.com>
Acked-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NAntoine Tenart <antoine.tenart@free-electrons.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

In commit 0ec8fd70 ("USB: musb: fix possible panic while resuming")
musb_resume() became musb_resume_early() in order to enable the clocks
early on resume. This piece of the resume code was removed later in
commit 03491761 ("usb: musb: move clock handling to glue layer").
In between the function was renamed from musb_resume_early() to
musb_resume_noirq() by commit commit 48fea965 ("USB: Rework musb
suspend()/resume_early()").

Now I see that first musb_core is resumed followed by phy and glue
layer and I ask myself is this really what we intend to do? This kind
of revoked the purpose of the first commit (0ec8fd70).
Because of this and because it looks wrong to resume (core) before the
glue layer I push it to the ->resume callback.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Sanity check on resource happening with devm_ioremap_resource().
Signed-off-by: NVarka Bhadram <varkab@cdac.in>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Currently musb_platform_reset() is only used by dsps.
In case of BABBLE interrupt for other platforms the  musb_platform_reset()
is a NOP. In such situations no need to re-initialize the endpoints.
Also in the latest silicon revision of AM335x, we do have a babble recovery
mechanism without resetting the IP block. In preperation to add that support
its better to have a rest_done return for  musb_platform_reset().
Signed-off-by: NGeorge Cherian <george.cherian@ti.com>
Tested-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

During babble condition both first disconnect of devices are
initiated. Make sure MUSB controller is reset and re-initialized
after all disconnects.

To acheive this schedule a delayed work for babble recovery.

While at that convert udelay to usleep_range.
Refer Documentation/timers/timers-howto.txt
Signed-off-by: NGeorge Cherian <george.cherian@ti.com>
Tested-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

BABBLE and RESET share the same interrupt. The interrupt
is considered to be RESET if MUSB is in peripheral mode and
as a BABBLE if MUSB is in HOST mode.

Handle babble condition iff MUSB is in HOST mode.
Signed-off-by: NGeorge Cherian <george.cherian@ti.com>
Tested-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

On AM33xx platforms, unplugging a device in the middle of an active
transfer leads to a drop of MUSB_DEVCTL_HM in MUSB_DEVCTL before the
system is informed about a disconnect. This consequently makes the musb
core call the gadget code to handle the interrupt request, which then
crashes the kernel because the relevant pointers haven't been set up
for gadget mode.

To fix this, use is_host_active() rather than (devctl & MUSB_DEVCTL_HM)
in musb_interrupt() and musb_dma_completion() to detect whether the
controller is in host or peripheral mode. This information is provided
by the driver logic and does not rely on register contents.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

BABBLE and RESET share the same interrupt. The interrupt
is considered to be RESET if MUSB is in peripheral mode and
as a BABBLE if MUSB is in HOST mode.

Handle babble condition iff MUSB is in HOST mode.

Fixes: ca88fc2e (usb: musb: add a work_struct to recover from babble errors)
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NGeorge Cherian <george.cherian@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Handle BABBLE interrupt error conditions from a work struct handler.
This indirection is necessary as we can't be certain that the phy
functions don't sleep.

Platform layer implementation may pass a babble error down to the core
in order to handle it.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

instead of relying on the otg pointer, which
can be NULL in certain cases, we can use the
gadget and host pointers we already hold inside
struct musb.

Cc: <stable@vger.kernel.org>
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

schedule_delayed_work() takes the delay in jiffies, not msecs.

This bug slipped in with the recent reset logic cleanup
(8ed1fb79: "usb: musb: finish suspend/reset work independently from
musb_hub_control()").
Signed-off-by: NDaniel Mack <daniel@zonque.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

schedule_delayed_work() takes the delay in jiffies, not msecs. Fix the
caller sites in musb. This bug caused regressions with the cleanups
that went in for 3.14 (8ed1fb79: "usb: musb: finish suspend/reset
work independently from musb_hub_control()").
Signed-off-by: NDaniel Mack <daniel@zonque.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

musb_port_reset() is called from musb_hub_control() which in turn holds
a spinlock, so musb_port_reset() is not allowed to call msleep().

With the asynchronous work helpers in place, this is fortunately easy to
fix by rescheduling the reset deassertion function to after the time
when the wait period is finished.

Note, however, that the MUSB_POWER_RESUME bit is only set on AM33xx
processors under rare conditions such as when to another driver
reporting an error during suspend. Hence, this didn't hit me yet in
normal operation.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

musb_port_reset() is called from musb_hub_control() which in turn holds
a spinlock, so musb_port_reset() is not allowed to call msleep().

With the asynchronous work helpers in place, this is fortunately easy to
fix by rescheduling the reset deassertion function to after the time
when the wait period is finished.

Note, however, that the MUSB_POWER_RESUME bit is only set on AM33xx
processors under rare conditions such as when to another driver
reporting an error during suspend. Hence, this didn't hit me yet in
normal operation.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

During resume don't touch SUSPENDM/RESUME bits of POWER register
while restoring controller context. These bits might be changed
by the controller during resume operation and so will be different
than what they were during suspend.

e.g. SUSPENDM bit is set by software during USB global suspend but
automatically cleared by the controller during remote wakeup or
during resume. Setting this bit back while restoring context
causes undesired behaviour. i.e. Babble interrupt is generated
and USB is broken.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

None of these files are actually using any __init type directives
and hence don't need to include <linux/init.h>.  Most are just a
left over from __devinit and __cpuinit removal, or simply due to
code getting copied from one driver to the next.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NRahul Bedarkar <rahulbedarkar89@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Removing the check to usb_disable() before registering the platform
driver allows to build this driver when !USB && USB_GADGET, to be
used in gadget-only mode.

Also, use module_platform_driver() to register the platform driver.
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Currently, resume and reset is completed when the USB core calls back
the root hub, asking for the port's state. This results in
unpredictable timing of state assertion, which in turn renders some
USB devices unusable after resume.

Fix this by moving the logic to end the reset and suspend state out of
musb_hub_control() into separate functions called from delayed workers.
GetPortStatus only reports the current state now, without taking any
real action.

The rh_timeout variable is kept in order to define a minimum time gap
between reset and resume only.

FWIW, in my case, a Verbatim "STORE N GO" mass storage device won't
resume cleanly without this patch.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

It appears not all platforms featuring a musb core need to save the musb
core registers at suspend time and restore them on resume.

The dsps platform does, however, and because it shouldn't cause any
trouble on other platforms, do it unconditionally for all of them.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This will tell glue layer which mode we want port
to be in.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Since commit c5340bd1 ("usb: musb: cancel work on removal") the workqueue
is cancelled but then if we bail out before the workqueue is setup we
get this:

|INFO: trying to register non-static key.
|the code is fine but needs lockdep annotation.
|turning off the locking correctness validator.
|CPU: 0 PID: 708 Comm: modprobe Not tainted 3.12.0+ #435
|[<c00867bc>] (lock_acquire+0xf0/0x108) from [<c00529d0>] (flush_work+0x38/0x2ec)
|[<c00529d0>] (flush_work+0x38/0x2ec) from [<c0052d24>] (__cancel_work_timer+0xa0/0x134)
|[<c0052d24>] (__cancel_work_timer+0xa0/0x134) from [<bf0e4ae4>] (musb_free+0x40/0x60 [musb_hdrc])
|[<bf0e4ae4>] (musb_free+0x40/0x60 [musb_hdrc]) from [<bf0e5364>] (musb_probe+0x678/0xb78 [musb_hdrc])
|[<bf0e5364>] (musb_probe+0x678/0xb78 [musb_hdrc]) from [<c0294bf0>] (platform_drv_probe+0x1c/0x24)
|[<c0294bf0>] (platform_drv_probe+0x1c/0x24) from [<c0293970>] (driver_probe_device+0x90/0x224)
|[<c0293970>] (driver_probe_device+0x90/0x224) from [<c0291ef0>] (bus_for_each_drv+0x60/0x8c)
|[<c0291ef0>] (bus_for_each_drv+0x60/0x8c) from [<c02938bc>] (device_attach+0x80/0xa4)
|[<c02938bc>] (device_attach+0x80/0xa4) from [<c0292b24>] (bus_probe_device+0x88/0xac)
|[<c0292b24>] (bus_probe_device+0x88/0xac) from [<c0291490>] (device_add+0x388/0x6c8)
|[<c0291490>] (device_add+0x388/0x6c8) from [<c02952a0>] (platform_device_add+0x188/0x22c)
|[<c02952a0>] (platform_device_add+0x188/0x22c) from [<bf11ea30>] (dsps_probe+0x294/0x394 [musb_dsps])
|[<bf11ea30>] (dsps_probe+0x294/0x394 [musb_dsps]) from [<c0294bf0>] (platform_drv_probe+0x1c/0x24)
|platform musb-hdrc.1.auto: Driver musb-hdrc requests probe deferral
|musb-hdrc musb-hdrc.1.auto: musb_init_controller failed with status -517

This patch moves the init part to earlier part so it can be cleaned as
part of the fail3 label because now it is surrounded by the fail4 label.
Step two is to remove it from musb_free() and add it to the two cleanup
paths (error path and device removal) separately.

Cc: stable@vger.kernel.org
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

If everything (musb, cppi41, phy) is built-in then musb will start
without the dma engine printing only

|musb-hdrc musb-hdrc.0.auto: Falied to request rx1.

The reason for this is that the musb device structs are created & probed
before those of the cppi41 device. So the cppi41 device is probed too
late.
As a workaround for this allow the musb_cppi41 part to defer the probe
if everything is fine except for the missing DMA controller. In case of
another error we continue.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

In commit f3ce4d5b ("usb: musb: core: call dma_controller_destroy() in the err path")
I erroneously assumed that the dma controller is not removed in the
error patch. This was wrong because it happens later via musb_free().
That means the original commit can be reverted because it is wrong or we
do this, so it is more obvious.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: stable@vger.kernel.org # v3.11
Cc: Daniel Mack <zonque@gmail.com>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

These aren't necessary after switch and if blocks.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

I have am335x-evm with one port running in OTG mode. Since commit
fe4cb091 ("usb: musb: gadget: remove hcd initialization") the loaded
gadget does non pop up on the host. All I see is
|usb 4-5: new high-speed USB device number 52 using ehci-pci
|usb 4-5: device descriptor read/64, error -110

Since a later commit 2cc65fea ("usb: musb: add musb_host_setup() and
musb_host_cleanup()) the gadget shows up on the host again but only
in OTG mode (because we have the host init code running). It does not
work in device only mode.
If running in OTG mode and the gadget is removed and added back (rmmod
followed by modprobe of a gadget) then the same error is pops up on the
host side.

This patch ensures that the gadget side also executes musb_start() which
puts the chip in "connect accept" mode. With this change the device
works in OTG & device mode and the gadget can be added & removed
multiple times.
A device (if musb is in OTG mode acting as a host) is only recognized if
it is attached during module load (musb_hdrc module). After the device
unplugged and plugged again the host does not recognize it. We get a
buch of errors if musb running in OTG mode, attached to a host and no
gadget is loaded. Bah.
This is one step forward. Host & device only mode should work. I will
look at OTG later. I looked at this before commit fe4cb091 and OTG wasn't
working there perfectly so I am not sure that it is a regression :)

Cc: <stable@vger.kernel.org> # v3.11
Cc: Daniel Mack <zonque@gmail.com>
Cc: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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
|[<c0014d38>] (unwind_backtrace+0x0/0xf4) from [<c001249c>] (show_stack+0x14/0x1c)
|[<c001249c>] (show_stack+0x14/0x1c) from [<c0037720>] (warn_slowpath_common+0x64/0x84)
|[<c0037720>] (warn_slowpath_common+0x64/0x84) from [<c00377d4>] (warn_slowpath_fmt+0x30/0x40)
|[<c00377d4>] (warn_slowpath_fmt+0x30/0x40) from [<c022ae90>] (debug_print_object+0x94/0xc4)
|[<c022ae90>] (debug_print_object+0x94/0xc4) from [<c022b7e0>] (debug_check_no_obj_freed+0x1c0/0x228)
|[<c022b7e0>] (debug_check_no_obj_freed+0x1c0/0x228) from [<c00f1f38>] (kfree+0xf8/0x228)
|[<c00f1f38>] (kfree+0xf8/0x228) from [<c02921c4>] (release_nodes+0x1a8/0x248)
|[<c02921c4>] (release_nodes+0x1a8/0x248) from [<c028f70c>] (__device_release_driver+0x98/0xf0)
|[<c028f70c>] (__device_release_driver+0x98/0xf0) from [<c028f840>] (device_release_driver+0x24/0x34)
|[<c028f840>] (device_release_driver+0x24/0x34) from [<c028ebe8>] (bus_remove_device+0x148/0x15c)
|[<c028ebe8>] (bus_remove_device+0x148/0x15c) from [<c028d120>] (device_del+0x104/0x1c0)
|[<c028d120>] (device_del+0x104/0x1c0) from [<c02911e4>] (platform_device_del+0x18/0xac)
|[<c02911e4>] (platform_device_del+0x18/0xac) from [<c029179c>] (platform_device_unregister+0xc/0x18)
|[<c029179c>] (platform_device_unregister+0xc/0x18) from [<bf1902fc>] (dsps_remove+0x20/0x4c [musb_dsps])
|[<bf1902fc>] (dsps_remove+0x20/0x4c [musb_dsps]) from [<c0290d7c>] (platform_drv_remove+0x1c/0x24)
|[<c0290d7c>] (platform_drv_remove+0x1c/0x24) from [<c028f704>] (__device_release_driver+0x90/0xf0)
|[<c028f704>] (__device_release_driver+0x90/0xf0) from [<c028f818>] (driver_detach+0xb4/0xb8)
|[<c028f818>] (driver_detach+0xb4/0xb8) from [<c028e6e8>] (bus_remove_driver+0x98/0xec)
|[<c028e6e8>] (bus_remove_driver+0x98/0xec) from [<c008fc70>] (SyS_delete_module+0x1e0/0x24c)
|[<c008fc70>] (SyS_delete_module+0x1e0/0x24c) from [<c000e680>] (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.

Cc: stable@vger.kernel.org
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Commit 8d2421e6 ("usb: musb: kill global and static for multi instance")
removed the global dma_mask copy and replaced by parent's DMA mask. The
problem here is that if the parent does not have a dma_mask then
musb_remove() goes kaboom.
Instead trying to fix this I was thinking we do we need to erase
dma_mask in the first place?
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The cleanup in the error is missing the dma controller. The structure is
allocated at runtime and ux500 allocates even a little more than just
this struct. So cleanup!
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This patch removes is_dma_capable() and an ifdef in the init/exit path
around init/de-init of the dma_controller. Since we have the empty stubs
in the PIO code we can call it without gcc trouble. Earlier we had an
ifdef and the is_dma_capable() macro where gcc ignored the if (0) path
even that the function was not around :)
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The core code creates a controller and immediately after that it calls
the ->start() callback. This one might drop an error but nobody cares.
The same thing happens in the destroy corner: First ->stop() called
followed by destroy callback. So why not merge those two into the same
function since there is no difference.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>