[PATCH v2 01/17] dm: usb: udc: Factor out plain udevice handler functions

[Marek Vasut]

On 10/2/23 15:42, Miquel Raynal wrote:
> Hi Marek,
> 
> marex at denx.de wrote on Sat, 30 Sep 2023 23:11:17 +0200:
> 
>> On 9/27/23 15:59, Miquel Raynal wrote:
>>> Hi Marek,
>>
>> Hi,
>>
>>> miquel.raynal at bootlin.com wrote on Fri, 22 Sep 2023 12:00:12 +0200:
>>>    
>>>> Hi Marek,
>>>>
>>>> I'm answering here as there is no cover letter. Just to let you know
>>>> I'm still concerned by the series and want to test it but did not had
>>>> the time to do so recently. Hopefully next week.
>>>
>>> The series looks good to me and works as well on a Beagle Bone Black
>>> with no visible functional changes regarding the use of the UDC. The
>>> whole series is:
>>>
>>> Tested-by: Miquel Raynal <miquel.raynal at bootlin.com>
>>>
>>> By the way, following your initial series there have been three
>>> followup patches trying to improve a little bit the doc, one got merged
>>> and two others were delegated to you:
>>> https://patchwork.ozlabs.org/project/uboot/list/?series=367635
>>>
>>> They are almost 2 months old now, would you mind acking or merging
>>> them so both your initial USB gadget rework and the additional
>>> (related) doc can be in the same release please?
>>
>> Can you resend those and CC this mail address ?
> 
> Of course!
> 
>> That said, 1/2 should be in some sort of README instead, and the 'dm tree' command depends on CMD_DM=y .
> 
> Well, the README is more something which targets the developer IMO,
> whereas here I want to target the users. Many people only see U-Boot
> through Yocto now (that's a different topic) and the purpose of this
> additional text is to help them in finding their way into U-Boot device
> model *alone*. It's really short, but I bet it can really help, given
> how I felt when I actually understood why you advised to type a couple
> of semi-random bind/unbind commands which eventually worked. Anybody not
> involved in any DM conversion is likely just not aware of all of that.
> Having people finding their own way through the DM means less
> complaints/needs for help on the mailing list.

Thinking about it back and forth, I think you've got a point, yes.

>> The usb_gadget_probe_driver() is code synchronized from kernel, you likely want to add any such clarification to usb_gadget_register_driver() .
> 
> Actually the kernel functions do have some kind of alternate error
> message as well now :-) Clearly different given that this code has been
> adapted to U-Boot's DM, but the idea is close. However
> usb_gadget_register_driver() is kind of blind regarding the number of
> UDCs in the system and if they are already bound or not, so I don't
> really see the point in moving the error message there along with all
> the logic duplication involved.
> 
>> That said, the usb_gadget_register_driver() should be reworked into
>> some new functions, which takes UDC controller *udevice pointer to
>> avoid this binding heuristics.
> 
> Yes, I don't know many boards with two UDCs but it's a clear limitation.

i.MX8M Plus is one such example, Quad I think is another, and pretty 
much anything with more than one DWC3 controller is. The CI HDRC is also 
often present in OTG capable configuration, so a lot of i.MXes are multi 
UDC systems.