Hi Stefan, I tested your patch on i.MX95 (Advantech AOM-2521), with a GL3523 hub connected to the DWC3 root port.
The board is not supported in mainline, so testing was done on NXP BSP u-boot-imx 2026.04 (lf_v2026.04). Compared with your patch's mainline pre-image, the BSP dwc3-generic.c differs only in board_usb_init() / board_usb_cleanup() hooks and glue ops linkage and const qualifiers, all outside the ref-clock code. The ref-clock hunks applied exactly; only the dwc3_generic_remove() hunk needed a six-line offset and fuzz 1. I replaced my local ref-clock fix with your patch, keeping the other five BSP patches unchanged. After "usb start": GUCTL 0x4c10c12c = 0x0a404010 REFCLKPER = 41 GFLADJ 0x4c10c630 = 0x0a87f000 REFCLK_FLADJ = 2032, 240MHZDECR = 10 These fields match the expected values for a 24 MHz reference. GFLADJ also matches the value Linux programs on this board. Earlier testing of an unfixed build gave 821 / 2 / 28 when the 32.768 kHz clock was selected. Both halves of the GL3523 now enumerate, the USB 3.2 half at 5 Gb/s and the USB 2.1 half at 480 Mb/s. The 480 Mb/s half previously failed with "Device not responding to set address"; that error is absent with your patch. The added clk_enable() also works for the SCMI reference clock on this board. There is no "failed to enable ref clock" message, and "clk dump" shows the 24 MHz clock's usecount increasing from 0 to 1: before "usb start": 24000000 0 scmi-2 after "usb start": 24000000 1 osc24m Testing covered boot-time hub enumeration; no USB storage device was attached, and the remove path was not exercised. Tested-by: Tom Hsieh <[email protected]> Regards, Tom
