Peter Chen wrote: > 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. > Right. I was suggesting to do that in a separate patch :) Thanks, Thinh
