Regression/bug in U-Boot USB ID vs mainline

[fd]

Hello,

`commit a5c91319731f ("MLK-25803-2: Update VID/PID")`, in U-Boot lf-6.18.20-2.0.0 branch,  introduces a regression in any user of USB.

It forces a hard-coded USB product ID, instead of taking the value from the configuration. This is breaking any board that is using a different value from 0x0151.

The issue is happening when using this U-Boot branch with non-NXP boards (using NXP SoC).

This value needs to come from the configuration, and not be hard-coded.

The following patch fixes the problem, can you apply it to your branch?

```

diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
index 165cc82d9c72..46e26d138cf9 100644
--- a/arch/arm/mach-imx/spl.c
+++ b/arch/arm/mach-imx/spl.c
@@ -199,7 +199,7 @@ int g_dnl_bind_fixup(struct usb_device_descriptor *dev, const char *name)
snprintf(serial_string, sizeof(serial_string), "%08x%08x", serialnr.high, serialnr.low);
g_dnl_set_serialnumber(serial_string);
#endif
- put_unaligned(0x0151, &dev->idProduct);
+ put_unaligned(CONFIG_USB_GADGET_PRODUCT_NUM + 0xfff, &dev->idProduct);

return 0;
}

```

[simonatoaca · Accepted solution]

Hello,

A fix was pushed, so the issue should be resolved starting with our Q3 RC2 2026 release.

Simona

[Oswalag]

Hello, 

The change was intentional, 

VID 0x525 and PID 0xa4a5 already registered as PLX Technology, Inc.

Linux-USB File-backed Storage Gadget

But fastboot device is not mass storage devices windowns 10 latest update already cached above vid/pid

Change to use Freescale VID 0x1fc9

PID 0x151, for SPL SDP HID download

PID 0x152, for Fastboot

PID 0x153, for Kernel fastboot

Need update uuu above 1.4.182 

[fd]

The issue is not your specific NXP needs that you just described. The issue is that hard coding the number in the code is preventing any user to configure it from the kconfig, as it is designed to be and effectively creating a regression.

That change is disregarding any existing user that has a different need, actively breaking working use cases. Just grep for CONFIG_USB_GADGET_PRODUCT_NUM in the code and you'll see the multiple use cases this is breaking.

You need to have a different solution that is not introducing a regression.

[Oswalag]

Hello, 

I will inform the internal team of this so they will check if the patch is needed for the next release, at this moment you can implement your workaround. 

Regards.

[fd]

> I will inform the internal team of this so they will check if the patch is needed for the next release, at this moment you can implement your workaround. 

This is not working for us.

We are implementing multiple fixes on your branch, and this one is just an example.

We need a feedback from the developer if they are going to accept this patch or solve the issue in a different way. Sending patches and fixes and getting no feedback and having to wait to some future release, in which we will not even be notified on the decision, is not an effective way to collaborate.

Can you please advise on a different way to move this forward? Thanks,

Francesco