Done. USB3 works on the GL-BE9300 (IPQ5332) with your patches — SuperSpeed link, disk enumerated, sustained transfers, no errors. Details below, along with six integration issues I had to resolve to get there. Your driver and dwc3-qcom changes are unmodified in what I tested; everything I changed was DTS plumbing and board glue.
Result
dwc3-qcom 8a00000.usb: Configuration mismatch. dr_mode forced to host
xhci-hcd xhci-hcd.1.auto: xHCI Host Controller
xhci-hcd xhci-hcd.1.auto: Host supports USB 3.0 SuperSpeed
usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
Bus 002 Device 002: ID 1058:0827 Western Digital My Passport 0827
negotiated link speed 5000 Mbit/s (still 5000 after sustained I/O)
block device /dev/sda 1.9 TB, sda1 ext4, mounted rw
raw sequential read 111 MB/s
ext4 write / readback 40 / 25 MB/s
USB errors in dmesg 0
The 111 MB/s is disk-limited, not bus-limited — it is a rotational 2.5" My Passport (rotational: 1), so that is roughly its platter speed. The lower ext4 figures are seek and filesystem overhead on spinning media, not transport.
Binding is usb-storage, not uas — but this enclosure advertises no UAS interface, so that is the device, not your patches. I have no UAS-capable device to hand; if that matters for the submission I can source one.
Baseline for comparison: before this, USB on this board was completely dead — drivers loaded, no controller ever registered, /sys/bus/usb/devices/ empty. So this is nothing-to-SuperSpeed, not an incremental improvement.
Six things needed to build it on qualcommbe
Two of these will bite anyone, not just me.
1. phy@4b0000 collides with the existing pcie0_phy — breaks every qualcommbe board. Your 0003 adds usbphy1: phy@4b0000, but stock 6.18 already has pcie0_phy: phy@4b0000 at the same register block. DTC refuses:
ipq5332.dtsi:348: ERROR (duplicate_node_names): /soc@0/phy@4b0000: Duplicate node name
Note this failed while compiling ipq5332-u7-pro-xgs.dts, a board unrelated to mine — so it is not board-specific. On IPQ5332 that block is the shared PCIe0/USB3 combo uniphy: a board can use it as PCIe0 or as the USB SuperSpeed PHY, never both, so describing it twice cannot work. I dropped the node-adding patch and instead retargeted the existing node at board level:
&pcie0_phy {
compatible = "qcom,ipq5332-uniphy-usb-ss-phy";
clocks = <&gcc GCC_PCIE3X1_PHY_AHB_CLK>,
<&gcc GCC_USB0_PHY_CFG_AHB_CLK>,
<&gcc GCC_USB0_PIPE_CLK>;
resets = <&gcc GCC_USB0_PHY_BCR>;
vdd-supply = <&usb_vbus_5v>;
status = "okay";
};
Worth checking whether the same collision exists on the tree you developed against — if not, our dtsi versions differ in a way that matters.
2. The GCC USB PIPE parent slot is already taken on qualcommbe. Upstream ends the list <&pcie0_phy>, <0>, and that trailing <0> is the slot your patch fills with <&usbphy1>. qualcommbe carries an out-of-tree patch (PCIe2 uniphy + controller nodes) that consumed it:
- <&pcie0_phy>,
- <0>;
+ <&pcie2_phy>,
+ <&pcie0_phy>;
So on qualcommbe the fifth parent is already pcie0_phy and your hunk has nothing to match. Since that entry is the combo PHY on this board, it was already correct for USB and needed no change.
3. 0005 removes the usb_dwc label and breaks boards that use it. Flattening usb_dwc: usb@8a00000 into usb: usb@8a00000 is right, but in-tree boards reference &usb_dwc and fail hard:
Error: ../dts/ipq5332-gl-be6500.dts:451.1-9 Label or path usb_dwc not found
FATAL ERROR: Syntax error parsing input tree
That hit both the BE9300 and the BE6500. The series probably wants a companion patch updating in-tree boards, or to keep usb_dwc as a second label on the flattened node. I understand the MR5500 hit this too.
4. PHY_QCOM_UNIPHY_USB_22ULL needs to be in the OpenWrt target config. Your 0017 sets it in arm64/defconfig, which OpenWrt ignores, so syncconfig prompts interactively and the build dies:
Qualcomm IPQ5332 USB SuperSpeed UNIPHY driver (PHY_QCOM_UNIPHY_USB) [Y/n/m/?] (NEW)
make[7]: *** [scripts/kconfig/Makefile:85: syncconfig] Error 1
Adding CONFIG_PHY_QCOM_UNIPHY_USB_22ULL=y to target/linux/qualcommbe/config-6.18 fixes it. Worth a note in the series, since the same trap already caught someone on ipq5018 — and mind the exact symbol name, another IPQ5332 USB patch floating around uses PHY_QCOM_UNIPHY_USB without the _22ULL.
5 and 6, board-level, for anyone porting this. The SuperSpeed PHY needs a board vdd-supply — my DTS had no 5 V regulator at all, so I added a fixed one. And on the BE9300 the USB port power pinctrl (usb_pins, GPIO 16) was defined but never referenced by any node, so the port had no power regardless of driver state. A board can carry your whole series correctly and still see nothing because of that one.
Two observations for you
qcom-m31usb-phy 7b000.phy: supply vdd not found, using dummy regulator— the USB2 M31 PHY still has no supply. Harmless here since SuperSpeed came up, but it is the same missing-vdd-supplyclass as the SS PHY.dwc3-qcom 8a00000.usb: Configuration mismatch. dr_mode forced to host— is that expected on this SoC, or does the DTS want an explicitdr_mode = "host"?
Happy to re-run any of this on a revision — the test is scripted and takes about ten minutes end to end, and I have two BE9300 units on the bench. If it is useful for the upstream posting, use whatever you need from the above.