** Description changed:
[ Impact ]
Users connecting a Lenovo USB-C to VGA Adapter (or similar USB-C DP adapters
with
a FIXED_VS LTTPR retimer) get no display output. The AMD display driver fails
DP
link training and logs:
- amdgpu 0000:c4:00.0: [drm] enabling link 2 failed: 15
+ amdgpu 0000:c4:00.0: [drm] enabling link 2 failed: 15
The fix is a single-line change:
- - if (memcmp("\x0,\x0,\x0", &link->dpcd_caps.lttpr_caps.lttpr_ieee_oui[0],
3) == 0)
- + if (memcmp("\x00\x00\x00", &link->dpcd_caps.lttpr_caps.lttpr_ieee_oui[0],
3) == 0)
+ - if (memcmp("\x0,\x0,\x0", &link->dpcd_caps.lttpr_caps.lttpr_ieee_oui[0],
3) == 0)
+ + if (memcmp("\x00\x00\x00", &link->dpcd_caps.lttpr_caps.lttpr_ieee_oui[0],
3) == 0)
The root cause is a typo in a C string literal used to check whether a
FIXED_VS
LTTPR retimer has no IEEE OUI. The literal "\x0,\x0,\x0" was intended to be
three
zero bytes but actually evaluates to five bytes {0x00, 0x2C, 0x00, 0x2C, 0x00}
(0x2C = ASCII comma) because commas are not valid hex digits and terminate
the \x
escape early. The memcmp() against the 3-byte LTTPR OUI field therefore never
matches, so the vendor-specific link rate toggle workaround required by these
retimers is never applied, and link training fails.
[ Test Plan ]
1. Connect a Lenovo USB-C to VGA Adapter to a system with an AMD GPU.
2. Without patch: confirm no display output and observe the following in
dmesg:
- amdgpu ...: [drm] enabling link N failed: 15
+ amdgpu ...: [drm] enabling link N failed: 15
3. Install a new kernel with patch: confirm display output appears and the
"enabling link failed: 15"
- message is absent from dmesg.
+ message is absent from dmesg.
[ Where problems could occur ]
The change is confined to the FIXED_VS LTTPR link training path
(dp_perform_fixed_vs_pe_training_sequence). It only affects systems where:
- - An AMD GPU with USB-C DP output is present, AND
- - A DP retimer (LTTPR) with no IEEE OUI is detected on the link.
+ - An AMD GPU with USB-C DP output is present, AND
+ - A DP retimer (LTTPR) with no IEEE OUI is detected on the link.
The risk of regression is very low — the fix corrects a comparison that was
always
false before, restoring the originally intended behaviour. Systems without a
FIXED_VS LTTPR retimer are completely unaffected.
[ Other Info ]
Upstream commit: 531fe6e0fee85a1bdb5b8223a706fff654ed0a61 (v7.0-rc1)
Stable backport: 91e6b6a7fe57d48c392d353ee50162a525d9e80c (v6.19.6)
- Reported against: linux-oem-6.17 6.17.0-1025.25
+ Affected kernel on noble and questing:
+ linux-oem-6.17 6.17.0-1025.25
+ linux-image-generic-hwe-24.04 6.17.0-35.35~24.04.1
+ Noble's hwe-24.04-edge and resolute is not affected.
+ linux-image-generic-hwe-24.04-edge 7.0.0-14.14~24.04.3
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2155619
Title:
[SRU] Correct FIXED_VS Link Rate Toggle Condition
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2155619/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
