[PATCH] usb: dwc3: gadget: Fix match_ep callback for NXP UUU tool

[Marek Vasut]

On 4/8/25 11:06 AM, Francesco Dolcini wrote:
> On Mon, Mar 24, 2025 at 03:36:52PM +0100, Marek Vasut wrote:
>> On 3/24/25 3:16 PM, Francesco Dolcini wrote:
>>> On Mon, Mar 24, 2025 at 02:53:23PM +0100, Marek Vasut wrote:
>>>> On 3/24/25 1:30 PM, Francesco Dolcini wrote:
>>>>> On Mon, Mar 24, 2025 at 09:26:03AM +0100, Mattijs Korpershoek wrote:
>>>>>> Hi Francesco,
>>>>>>
>>>>>> On lun., mars 24, 2025 at 09:03, Francesco Dolcini <francesco at dolcini.it> wrote:
>>>>>>
>>>>>>> Hello Mattijs, Marek
>>>>>>>
>>>>>>> On Thu, Mar 20, 2025 at 10:47:02AM +0100, Mattijs Korpershoek wrote:
>>>>>>>> On mer., mars 19, 2025 at 23:07, Marek Vasut <marex at denx.de> wrote:
>>>>>>>>
>>>>>>>>> The UUU tool excepts the interrupt-in endpoint to be ep1in, otherwise
>>>>>>>>> it crashes. This is a result of the previous hard-coded EP setup in
>>>>>>>>> drivers/usb/gadget/epautoconf.c which did special-case EP allocation
>>>>>>>>> for SPL builds, and which was since converted to this callback, but
>>>>>>>>> without the special-case EP allocation in SPL part.
>>>>>>>>>
>>>>>>>>> This reinstates the SPL part in an isolated manner, only for NXP iMX
>>>>>>>>> SoCs, only for SPL builds, and only for the ep1in interrupt-in endpoint.
>>>>>>>
>>>>>>> UUU can (and in our case is) used also on non-NXP i.MX platforms.
>>>>>>> What should we do?
>>>>>>
>>>>>> Do reproduce the problem (UUU tool crashes) on those platforms with
>>>>>> recent U-Boot versions (v2024.10+) ?
>>>>>
>>>>> Not tested, my comment is purely based on the code and the commit message.
>>>>> Older U-Boot versions (up to v2024.04, included) are working fine, with UUU used
>>>>> with TI K3 SoCs (AM69, AM62, AM62P).
>>>> Are you talking about the NXP UUU ?
>>>
>>> yes, it works just fine on not-NXP SoC.
>> Then please test if it still works, and if not, this patch needs to be
>> expanded to cover TI ... or apply unconditionally in SPL (sigh).
> 
> I just found the time to check some logs from our CI in which we execute such a
> workflow.  We do use UUU only from U-Boot proper, so we are not going to be
> affected by this SPL specific change.
> 
> However I found this error in the logs, on both a TI AM62 and an i.MX8MP
> 
> ```
> Starting download of 40524455 bytes
> dwc3-generic-peripheral usb at 31000000: request 0000000099f219c0 was not queued to ep1in-bulk
> ..........................................................................
> ..........................................................................
> ..........................................................................
> ..........................................................................
> .............
> downloading of 40524455 bytes finished
> dwc3-generic-peripheral usb at 31000000: request 0000000099f219c0 was not queued to ep1in-bulk
> dwc3-generic-peripheral usb at 31000000: request 0000000099f219c0 was not queued to ep1in-bulk
> Starting download of 1675 bytes
> dwc3-generic-peripheral usb at 31000000: request 0000000099f219c0 was not queued to ep1in-bulk
> downloading of 1675 bytes finished
> dwc3-generic-peripheral usb at 31000000: request 0000000099f219c0 was not queued to ep1in-bulk
> dwc3-generic-peripheral usb at 31000000: request 0000000099f219c0 was not queued to ep1in-bulk
> Starting download of 82 bytes
> dwc3-generic-peripheral usb at 31000000: request 0000000099f219c0 was not queued to ep1in-bulk
> downloading of 82 bytes finished
> dwc3-generic-peripheral usb at 31000000: request 0000000099f219c0 was not queued to ep1in-bulk
> dwc3-generic-peripheral usb at 31000000: request 0000000099f219c0 was not queued to ep1in-bulk
> ```
> 
> the download is successful however, despite those error messages. Any idea? Is
> this related to this topic?
I have a feeling it is the UUU which should be fixed to not depend on 
the ep1-in , really.

You could however quickly try and apply the change in this patch not 
only to SPL, but to U-Boot on your board as well, and see if those 
warnings disappear.