RE: [PATCH v1] USB:gadget: Fix a warning while loading g_mass_storage

[Paul Zimmerman]

> From: linux-usb-owner@xxxxxxxxxxxxxxx [mailto:linux-usb-owner@xxxxxxxxxxxxxxx] On Behalf Of Alan Stern
> Sent: Wednesday, June 04, 2014 6:57 AM
> 
> On Wed, 4 Jun 2014, Yang,Wei wrote:
> 
> > On 06/04/2014 09:45 AM, Peter Chen wrote:
> > >
> > >> commit d18f7116a5ddb8263fe62b05ad63e5ceb5875791
> > >> Author: Robert Baldyga <r.baldyga@xxxxxxxxxxx>
> > >> Date:   Thu Nov 21 13:49:18 2013 +0100
> > >>
> > >>       usb: gadget: s3c-hsotg: fix disconnect handling
> > >>
> > >>       This patch moves s3c_hsotg_disconnect function call from USBSusp
> > >> interrupt
> > >>       handler to SET_ADDRESS request handler.
> > >>
> > > It is a little strange we call gadget's disconnect at SET_ADDRESS?
> > > How the udc calls gadget driver the disconnection has happened when
> > > the usb cable is disconnected from the host?
> > >
> > > Usually, we call gadget's disconnect at two situations
> > >
> > > - udc's reset handler if udc's speed is not UNKNOWN, it is usually happened
> > > when the host sends reset after enumeration.
> > > - udc's disconnect handler, it is usually happened when the usb cable
> > > is disconnected from host.
> >
> > Hmm, usually the two situations, but according to the commit log, s3c
> > hsotg does not support Disconnected interrupt for device mode,
> > so the second situation does not happen for s3c hsotg, therefore, he has
> > to disconnect the connection before it is connected again.
> 
> Why does he need to do that?  Why not just skip the disconnect
> notification if the hardware can't detect a disconnect?
> 
> It makes no sense at all to call a disconnect handler from within the
> SET_ADDRESS routine.

FWIW, here is the section from the DWC2 databook that describes how a
disconnect should be handled for the device:

When OTG_MODE is set to 0, 1, or 3, the device disconnect flow is as
follows:
	1. When the USB cable is unplugged or when the VBUS is switched
	   off by the Host, the Device core triggers GINTSTS.OTGInt
	   [bit 2] interrupt bit.
	2. When the device application detects GINTSTS.OTGInt interrupt,
	   it checks that the GOTGINT.SesEndDet (Session End Detected)
	   bit is set to 1'b1.

When OTG_MODE is set to 2 or 4, the device disconnect flow is as
follows:
	1. When the USB cable is unplugged or when the VBUS is switched
	   off by the Host, the Device core triggers GINTSTS.USBRst
	   [bit 12] interrupt bit.
	2. When the device application detects GINTSTS.USBRst, the
	   application sets a timeout check for SET ADDRESS Control Xfer
	   from Host.
	3. If application does not receive SET ADDRESS Control Xfer from
	   Host before the timeout period, it is treated as a device
	   disconnection.

OTG_MODE is a configuration parameter that is set when the core is
built. From this discussion, it sounds like the s3c-hsotg core is
built for either mode 2 or 4. So SET ADDRESS should be involved, but
not in the way the driver is currently doing it.

Unfortunately I don't have the s3c-hsotg hardware, so I can't work on this
myself.

-- 
Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/