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. > Actually, I still think that the locking for soft_connect_store() should be done in a separate patch since that's needed there regardless whether we introduced this new field. Let me know if you have any concern. Thanks, Thinh
