aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/usb/gadget/function/f_midi.c
diff options
context:
space:
mode:
authorSebastian Andrzej Siewior <bigeasy@linutronix.de>2014-10-27 19:06:18 +0100
committerFelipe Balbi <balbi@ti.com>2014-11-05 13:23:04 -0600
commitb87fd2f7aa490a7f4bab44c41937aca0bc62fdc5 (patch)
tree5e2b1059f9b16c77f7180317ed57bfb3913d1f79 /drivers/usb/gadget/function/f_midi.c
parentusb: dwc3: exynos: remove non-DT support for Exynos Specific Glue layer (diff)
downloadlinux-dev-b87fd2f7aa490a7f4bab44c41937aca0bc62fdc5.tar.xz
linux-dev-b87fd2f7aa490a7f4bab44c41937aca0bc62fdc5.zip
usb: musb: core: check link status on resume
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: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
Diffstat (limited to 'drivers/usb/gadget/function/f_midi.c')
0 files changed, 0 insertions, 0 deletions