On Tue, Jul 29, 2025 at 4:19 AM Alice Guo (OSS) <[email protected]> wrote: > > From: Ye Li <[email protected]> >
Hi Ye, I think a better commit subject would be 'imx: Update SDP VID/PID' or something more descriptive than what you have. > 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 s/windowns/Windows/ > > Change to use Freescale VID 0x1fc9 > > PID 0x151, for SPL SDP HID download > PID 0x152, for Fastboot > PID 0x153, for Kernel fastboot > Please expand a bit on why you need to change these exactly. It took me a while to figure out how the VID/PID's affect uuu and what you are trying to do here: The uuu tool maps VID/PID/BCD values to protocols (see 'uuu -v' for a list) and supports built-in scripts mapping protocols to various functions (see 'uuu -bshow'). Before these changes for these defconfigs: - SPL SDP enumerates as 0x0525:0xb4a4:0x500 which uuu maps to the SDPV protocol (the 0xb4a4 comes from adding 0xfff to the PID which was indeed strange) - U-Boot SDP command enumerates as 0x0525:0xa4a5 which uuu maps to the FB (fastboot) protocol After your changes for these defconfigs: - SPL SDP enumerates as 0x1FC9:0x0151:0x0500 which uuu also maps to the SDPV protocol. - U-Boot SDP command enumerates as 0x1FC9:0x0152 which uuu maps to the FB (fastboot) protocol So with respect to using uuu on these devices the protocols and thus functions have not changed and what you were really trying to do is properly use NXP ID's instead of squatting on the PLX ID's for historic reasons. Is there any other side effect of changing VID/PID here when not using uuu? I'm not very familiar with Windows drivers... Perhaps there was a Windows driver binding to the old VID/PID getting in the way of using uuu on Windows? I'm not clear what other OS's like could be used here. > Need update uuu above 1.4.182 > > Signed-off-by: Frank Li <[email protected]> > Signed-off-by: Alice Guo <[email protected]> > Reviewed-by: Ye Li <[email protected]> > --- > arch/arm/mach-imx/spl.c | 2 +- > configs/imx8m_data_modul.config | 4 ++-- > configs/imx8mm_evk_defconfig | 4 ++-- > configs/imx8mn_ddr4_evk_defconfig | 4 ++-- > configs/imx8mp_evk_defconfig | 4 ++-- > configs/mx6qsabrelite_defconfig | 4 ++-- > configs/mx6sabreauto_defconfig | 4 ++-- > configs/mx6sabresd_defconfig | 4 ++-- > configs/mx6ul_14x14_evk_defconfig | 4 ++-- > configs/mx7dsabresd_defconfig | 4 ++-- > 10 files changed, 19 insertions(+), 19 deletions(-) Why are you suggesting changing specifically these defconfigs and not all imx defconfigs? It seems you cherry-picked a handful but they don't all look like NXP maintained boards to me. > > diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c > index 518d9cb1262..4a86d8698b4 100644 > --- a/arch/arm/mach-imx/spl.c > +++ b/arch/arm/mach-imx/spl.c > @@ -184,7 +184,7 @@ u32 spl_boot_device(void) > #ifdef CONFIG_SPL_USB_GADGET > int g_dnl_bind_fixup(struct usb_device_descriptor *dev, const char *name) > { > - put_unaligned(CONFIG_USB_GADGET_PRODUCT_NUM + 0xfff, &dev->idProduct); > + put_unaligned(0x0151, &dev->idProduct); A comment here indicating that 0x1fc9:0x151 is mapped by uuu to the SDPV protocol would be handy. The magic 0xa4a5+0xfff=0xb4a4 which maps to SDPV was very strange and confusing for sure. Should the VID be hard coded to 0x1fc9 as well? I think these should be #defines in this file. But, because you are only changing a handful of IMX defconfigs you are completely breaking SDP for all other imx defconfigs with the above change so: NAK Note that I would agree with not using the PLX ID's in general. Also note that this patch isn't necessary for Alice's series and can be dropped from that series. Best Regards, Tim
