Re: [PATCH] usb: udc: core: Introduce started state

[Peter Chen <hzpeterchen@gmail.com>]

On 21-01-11 22:35:07, Thinh Nguyen wrote:
> Thinh Nguyen wrote:
> > Hi,
> >
> > Alan Stern wrote:
> >> On Mon, Jan 11, 2021 at 12:38:05PM -0800, Thinh Nguyen wrote:
> >>> For some UDCs, the initialization sequence by udc_start() should not be
> >>> repeated until it is properly cleaned up with udc_stop() and vise versa.
> >>> We may run into some cleanup failure as seen with the DWC3 driver during
> >>> the irq cleanup. This issue can occur when the user triggers
> >>> soft-connect/soft-disconnect from the soft_connect sysfs. To avoid
> >>> adding checks to every UDC driver, at the UDC framework, introduce a
> >>> "started" state to track and prevent the UDC from repeating the
> >>> udc_start() and udc_stop() if it had already started/stopped.
> >>>
> >>> Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
> >> Is the new "started" field subject to races?  What happens if there are 
> >> concurrent requests to start and stop the UDC?
> >>
> >> Alan Stern
> > The caller of this usb_gadget_udc_start/stop() should take care of the
> > locking. It's already done in the case of driver probe/remove, but not
> > for the sysfs soft_connect. Maybe I should add that to this patch.
> >

The udc_bind_to_driver (calls ->start) and usb_gadget_remove_driver(call
->stop) are protected by mutex udc_lock, so don't have concurrent issue for
it. For soft_connect, I think you could add the same mutex.

-- 

Thanks,
Peter Chen