On 8/22/24 5:53 PM, Zixun LI wrote:
On Thu, Aug 22, 2024 at 5:24 PM Marek Vasut <ma...@denx.de> wrote:

Can you change the g_dnl_register() prototype and pass he structure in ?
I suspect it should be available in the commands which register g_dnl ?


There are many places where g_dnl_register() is called, like fastboot, dfu, ums,
etc, need to modify all of them ?

I think that should be possible with 'git grep' and 'sed' mechanically.

This is no good, this is a workaround, let's not do this.


You mean which part, order change or disconnect call ?

Yes

Is there a fixed order of udc_start (device init) and driver->bind ?
In non-DM mode most device drivers do init first in their
usb_gadget_register_driver(), except udc-core and DWC2 who does
driver->bind first.

The driver .bind callback is called when the driver is instantiated (e.g. matching compatible string is found in DT, or some board file instantiates a driver and binds it to a DT node). This can happen very early.

The driver .probe callback initializes the controller hardware and is called only the first time the controller is used. U-Boot uses lazy hardware initialization to speed up the boot process, i.e. hardware is initialized the first time it is used, using the .probe callback.

The .udc_start callback in usb_gadget_ops must be called after the controller driver .bind and .probe were called.

The usb_composite_driver .bind has to be called after controller driver .bind (but it may be called before controller driver .probe).

I think udc_bind_to_driver() should not call usb_gadget_connect() , that connect should likely be called by at some later point. I also think that drivers/usb/gadget/udc/udc-core.c might have to be extended to provide some way to convert controller struct udevice to struct usb_gadget , so when e.g. run_usb_dnl_gadget() calls udc_device_get_by_index() and obtains struct udevice * , it can also get matching struct usb_gadget * , and call the usb_gadget_connect().

What do you think ?

Call usb_gadget_disconnect here could avoid modifying all device driver's init.

[...]

Reply via email to