[Bug 2155619] Re: [SRU] Correct FIXED_VS Link Rate Toggle Condition

** 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 subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2155619 Title: [SRU] Correct FIXED_VS Link Rate Toggle Condition Status in linux package in Ubuntu: In Progress Bug description: [ 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 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) 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 3. Install a new kernel with patch: confirm display output appears and the "enabling link failed: 15"    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. 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) 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2155619/+subscriptions