[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <82bb5df19e9047298f4e80aa870cceec@BL2PR03MB226.namprd03.prod.outlook.com>
Date: Thu, 5 Jun 2014 01:30:12 +0000
From: Peter Chen <Peter.Chen@...escale.com>
To: Alan Stern <stern@...land.harvard.edu>,
"Yang,Wei" <Wei.Yang@...driver.com>
CC: Michal Nazarewicz <mina86@...a86.com>,
Andrzej Pietrasiewicz <andrzej.p@...sung.com>,
Felipe Balbi <balbi@...com>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
USB list <linux-usb@...r.kernel.org>,
Kernel development list <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v1] USB:gadget: Fix a warning while loading g_mass_storage
> 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@...sung.com>
> > >> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists