thunderbolt: AMD Phoenix USB4 host advertises Gen3 Support=0 in SB LINK_CONF with TB5 device, link stuck at Gen2

[James Taylor <jrtaylor11@gmail.com>]

Hi,

(Resend as plain text. The first copy was rejected by the list for HTML.
Mika, apologies for the duplicate.)

I'm reporting a link-speed problem on an AMD Phoenix USB4 host with a
Thunderbolt 5 (Barlow Ridge) device. I think the register data points at
host firmware, and I'd like to know whether the connection manager has any
supported way to influence it.

Setup
- Host: Minisforum UM890 Pro (AMD Ryzen 9 8945HS / Phoenix, "Pink Sardine"
  USB4 NHI 1022:1668/1669), BIOS 1.06, AGESA PhoenixPI-FP8-FP7 1.2.0.0a
- Device: Minisforum DEG2 eGPU dock, Intel JHL9480 (8086:5786), NVM 62.42,
  vendor 0x41f device 0xd002
- Cable: StarTech TBLT5MM50CM240W (0.5 m, TB5). One retimer is enumerated:
  1-0:2.1 vendor=0x7fea device=0x1032
- Kernel: 7.2.15, software CM, thunderbolt.host_reset=0 (also tested
  host_reset=1: same result)

Symptom
The link always comes up 2 x Gen2 (rx/tx 10.0 Gb/s, 2 lanes),
usb4_port2/link = "tbt". It's deterministic across replug, host_reset and
reboots. A USB4 v1 device (ASM2464PD enclosure) on the same host port, with
a different cable, trains Gen3 x2.

Registers (debugfs)
Host 1-0 port2:
  LANE_ADP_CS_0 = 0x003c01c0   (supported Gen2|Gen3)
  LANE_ADP_CS_1 = 0x4828003c   (target Gen3, current Gen2, width 2)
  PORT_CS_18    = 0x00002f00   (TCM set)
  SB 0x0c LINK_CONF = 03 d3 03
Device 1-2 port1:
  LANE_ADP_CS_0 = 0x0cfe01c0   (supported Gen2|Gen3|Gen4)
  LANE_ADP_CS_1 = 0x4828003e   (target Gen4, current Gen2)
  PORT_CS_18    = 0x00902f01   (TCM set)
  SB 0x0c LINK_CONF = 03 f3 1b

The two LINK_CONF values differ in bit 13. If I map the fields in the USB4
order (enabling decisions, rsvd, enabling requests, rsvd, bonding, Gen3
support, RS-FEC Gen2/Gen3, SB channel support, TBT3 speeds, Gen4, asym...),
the host advertises Gen3 Support = 0 and the device advertises Gen3
Support = 1. I took the field positions from a protocol-analyser field list
rather than the spec text, so please correct me if the layout is wrong.
Under that reading, the host's link characteristics exclude Gen3 even though
its lane adapter supports and targets Gen3, which would explain Gen2.

Experiment
With a thunderbolt.ko built with CONFIG_USB4_DEBUGFS_WRITE:
- Writing "0x0c 0x03 0xf3 0x03" to 1-0/port2/sb_regs fails with -EIO, and
  the value is unchanged. So the host router appears to own this register
  (set by platform/PD firmware).
- Toggling LANE_ADP_CS_1.LD on 1-0 port2 dropped the link. It did not
  re-establish when LD was cleared, and recovered only after reloading the
  driver with host_reset=1. Possibly worth handling separately.

Questions
1. Is my reading of SB LINK_CONF correct, i.e. is the host-side Gen3
   Support bit what limits this link?
2. On AMD USB4 hosts, is there a CM-visible way (router operation, port
   config, or reset sequence) to make the host re-evaluate Gen3 support, or
   is this purely platform PD/USB4 firmware (cable/partner VDO handling with
   TB5 cables)?
3. Is this a known issue with Phoenix/Hawk Point hosts and USB4 v2 / TB5
   devices or cables? (Bugzilla 221822 and 221319 look related but describe
   different symptoms.)

I can provide full debugfs dumps, dmesg with thunderbolt.dyndbg, or test
patches.

Thanks,
James