On 20-07-29 10:14:48, Alan Stern wrote:
> On Wed, Jul 29, 2020 at 01:47:20AM +0000, Peter Chen wrote:
> > On 20-07-28 15:32:46, Alan Stern wrote:
> > > Roger:
> > >
> > > Your commit fac323471df6 ("usb: udc: allow adding and removing the same
> > > gadget device") from a few years ago just caught my eye. (I don't
> > > recall whether I noticed it at the time.)
> > >
> > > In any case, we need to talk about it. What you're doing --
> > > unregistering and re-registering the struct device embedded in the
> > > gadget structure -- is strictly forbidden by the kernel's device model.
> > > It's even mentioned specifically in the kerneldoc for device_add().
> > >
> > > Now, I guess doing this would be okay _if_ you took care not to
> > > re-register the device until all references to the previous incarnation
> > > have been dropped. In particular, setting the structure's memory to 0
> > > should not be done immediately after calling device_unregister() --
> > > which is what the commit does -- but rather in the release routine.
> > >
> > > Do you know which UDC drivers actually do re-register their gadgets? In
> > > particular, do they have their own release routines or do they rely on
> > > the default usb_udc_nop_release() provided by the UDC core?
> >
> > dwc3 and cdns3 gadget driver do that, they use default usb_udc_nop_release()
> > provided by the UDC core. The usb_add_gadget_udc is called when the
> > controller role switch to device mode (the host VBUS is seen at device
> > side), and usb_del_gadget_udc is called when the cable is disconnected
> > from host.
>
> What if the role switches back to host without the cable being
> disconnected?
This kinds of role switch is through the sys entry directly, without
considering hardware signal. Taking cdns3 as an example for this use
case, usb_del_gadget_udc will be called for stopping device mode, and
create xhci platform device for starting host.
--
Thanks,
Peter Chen
