Hello,
On 2014-10-25 03:23, Paul Zimmerman wrote:
From: Marek Szyprowski [mailto:m.szyprowski@xxxxxxxxxxx]
Sent: Monday, October 20, 2014 3:46 AM
This patch adds a call to s3c_hsotg_disconnect() from 'end session'
interrupt (GOTGINT_SES_END_DET) to correctly notify gadget subsystem
about unplugged usb cable. 'disconnected' interrupt (DISCONNINT) might
look a bit more suitable for this event, but it is asserted only in
host mode, so in device mode we need to use something else.
Signed-off-by: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>
---
drivers/usb/dwc2/gadget.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 7b5856fadd93..119c8a3effc2 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2279,6 +2279,12 @@ irq_retry:
dev_info(hsotg->dev, "OTGInt: %08x\n", otgint);
writel(otgint, hsotg->regs + GOTGINT);
+
+ if (otgint & GOTGINT_SES_END_DET) {
+ if (hsotg->gadget.speed != USB_SPEED_UNKNOWN)
+ s3c_hsotg_disconnect(hsotg);
+ hsotg->gadget.speed = USB_SPEED_UNKNOWN;
+ }
}
if (gintsts & GINTSTS_SESSREQINT) {
Does this mean we can get rid of the call to s3c_hsotg_disconnect in
s3c_hsotg_process_control after a SET_ADDRESS is received? If not,
then s3c_hsotg_disconnect will be called twice, once here after the
disconnect, and once again after the reconnect and SET_ADDRESS.
Nope, we cannot get rid of that call, because it is needed got get gadget
operational when device has been re-enumerated. The simplest way to
reproduce
such case is to connect dwc2 to externally powered hub and then unplug cable
between hub and usb host. In such case the 'end session' interrupt is not
asserted, so the additional s3c_hsotg_disconnect() call before setting new
address is needed. I will rework this patch and add a code to ensures that
the gadget->disconnect() will be called only once.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
