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@xxxxxxxxxxxx> > >> 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
