glymur/UX3607OA: usb_1 SS root port fails link training with hubs, trains Gen2x1 devices fine

Hi,

On the Asus Zenbook A16 (UX3607OA, X2 Elite Extreme), the SuperSpeed
root port of usb_1 (a800000) cannot bring up a link to any hub, while
the same port trains a directly attached Gen2x1 device at 10 Gbps
without a single error. The same hub works fine on usb_0 (a600000).
Under Windows the port drives the same hub normally.

Kernel: next-20260730 plus your A16 series and the three later glymur
fixes cherry-picked (e78c5e9d79e3, 5ac32106d3c2, 1b0b6ddd0299), plus
the USB vote patch I just sent separately ("arm64: dts: qcom: glymur:
Add missing USB clock, power and bandwidth votes").

Reproducer (~20 s): plug a USB-C adapter containing a SS hub into each
Type-C port in turn. Ours enumerates as Terminus 1a40:0101 (USB2 hub) +
VIA 2109:0817/2817 + Billboard 25a4:9321; a VL817-based dock shows the
same behaviour. No monitor attached, so all four SS lanes are available
to USB3 on both ports.

  usb_0: SS hub + downstream devices at 5 Gbps, clean
  usb_1: HS half of the hub enumerates fine, SS root port fails

Interestingly the failure signature depends on the CX performance
state. Before the vote patch (CX aggregating to SVS), the SS port never
reaches U0:

  usb usb6-port1: Cannot enable. Maybe the USB cable is bad?  (x8)

With the vote patch applied (CX at NOM while the controller is active),
link training gets further - the port reaches U0 and the failure moves
to the first control transfer:

  usb 4-1: Device not responding to setup address.  (x2)
  usb 4-1: device not accepting address 2, error -71
  usb usb4-port1: Cannot enable. Maybe the USB cable is bad?

A directly attached SanDisk Extreme SSD trains SuperSpeed Plus Gen 2x1
on this same port and transfers normally in both configurations, which
is what makes this odd - a marginal link would be expected to fail the
faster mode first.

Ruled out by measurement on this machine:

  - master clock rates: all three gcc_usb30_*_master_clk at 200 MHz
  - TCSR_USB4_1_CLKREF_EN: enabled, hw gate on, 19.2 MHz
  - swapped vdda-phy/vdda-pll (the glymur-crd issue Mani fixed): this
    board has them correct (0.91-0.94 V phy, 1.2 V pll)
  - DP altmode interference: no altmode entered, Billboard shows up on
    both ports, DP-1/DP-2 disconnected throughout
  - USB_QUIRK_NO_LPM on the VL817 SS half: the quirk never gets a
    chance to apply since the SS device never enumerates

The one asymmetry we know of is the QMP PHY reference clock source:
usb_0_qmpphy takes RPMH_CXO_CLK directly while usb_1_qmpphy takes
TCSR_USB4_1_CLKREF_EN (per 12c97d1c15f9 that matches the HW design).
Is there anything else that differs between these two ports on the SiP
package that would be worth poking at? Happy to test patches or gather
more data - the machine reproduces this on demand.

Thanks,
Greg