On Thu, 15 Jun 2017, Peter Chen wrote: > > > No, ->pullup is expected to be called from UDC core, and the UDC core > > > makes sure the coming ->disconnect at kinds of situations. > > > > I think you are wrong. The UDC core calls ->pullup from the > > usb_gadget_disconnect() routine, but it does not call ->disconnect from > > that routine. > > > > You may misunderstand my point, I mean there are always ->disconnect > call after ->pullup at UDC core, eg, usb_gadget_remove_driver and > usb_udc_softconn_store. So individual UDC driver does not need > ->disconnect at its ->pullup implementation.
But a gadget driver can call usb_gadget_disconnect() whenever it wants to, because that function is EXPORTed. When it does, the UDC core will not call ->disconnect. Alan Stern > > Furthermore, there is an advantage to having the UDC driver call > > ->disconnect from within its ->pullup method: It can retain its private > > spinlock across the ->disconnect call. This will help prevent races. > > For example, what would happen if ->disconnect was called while a > > ->setup callback was in progress? Or vice versa? > > > > You mean the private UDC driver spinlock can help prevent races well for > ->setup and ->pullup in UDC driver? Yes, it is the good point. I am > wondering why composite_disconnect has spinlock and without for > composite_setup. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
