RE: [PATCH v1] USB:gadget: Fix a warning while loading g_mass_storage
From: Peter Chen
Date: Wed Jun 04 2014 - 21:30:23 EST
> 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?
>
We must call gadget driver's disconnect, otherwise, there at least
has a warning when unload module, please refer to __composite_unbind
at drivers/usb/gadget/composite.c
Peter
> It makes no sense at all to call a disconnect handler from within the
> SET_ADDRESS routine.
>
> Alan Stern
--
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/