On Thu, Jun 11, 2026 at 05:25:49PM +0300, Imre Deak wrote: > Thanks for the tests and root causing of the issue. > > I think the right solution to avoid using a problematic link > configuartion is to rely on the existing mechanism which is the link > training fallback logic. A quirk in this patch would add another way, > which is less generic and would potentially disable the link config on a > non-affected device as well (I did read your test results above, but I > still think it's possible that another device would use the same > OUI/device ID without this issue).
Hi Imre, thanks for the review, that is a fair point. I agree that the fallback logic is the better place for this and I am dropping the series. I read the cover letter of [1]. If I understand the plan correctly, the follow-up switch to a bandwidth ordered configuration selection would already avoid the greeter case described here. A 1080p60 mode would then pick a 5.4 Gbps configuration such as 2x270000 instead of the 6.48 Gbps 4x162000, and 2x270000 is what the device trains today with the quirk applied. The remaining modes that still compute to 4x162000 would fail training once and then be handled by the per-configuration fallback. That fully covers this device, so nothing is lost by dropping the quirk. Until then carrying the patch locally works fine for me. One offer regarding testing. This PCON fails channel equalization at 4x RBR deterministically on every boot, so I have a reliable reproducer for the fallback paths on PTL with the xe driver. Feel free to ping me whenever the fallback rework or any other part of the series could use a Tested-by on real failing hardware. [1] https://lore.kernel.org/all/[email protected] Thanks, Alex
