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

[Mika Westerberg <mika.westerberg@linux.intel.com>]

Hi,

On Sun, Nov 08, 2026 at 01:15:45PM +0000, James Taylor wrote:
> 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.

Please use tbdump from tbtools [1]. It knows the registers. Something like
this:

https://github.com/intel/tbtools/wiki/Useful-Commands#dump-lane-adapter-capability-for-current-link-capabilities-and-status

Also please provide full dmesg with dynamic debugging enabled.

[1] https://github.com/intel/tbtools