On Fri, Sep 05, 2025 at 04:45:34PM +0300, Imre Deak wrote:
On Fri, Sep 05, 2025 at 07:07:40AM +0200, Greg Kroah-Hartman wrote:
On Fri, Sep 05, 2025 at 12:48:11AM +0300, Imre Deak wrote:
Hi Greg,
On Tue, Sep 02, 2025 at 03:20:41PM +0200, Greg Kroah-Hartman wrote:
6.16-stable review patch. If anyone has any objections, please let me know.
Thanks for queuing this and the corresponding reverts for the other stable trees. This one patch doesn't match what I sent, the address should be changed to DP_TRAINING_PATTERN_SET not to DP_DPCD_REV, see [1]. I still think that's the correct thing to do here conforming to the DP Standard and matching what the upstream kernel does, also solving a link training issue for a DP2.0 docking station.
The reverts queued for the other stable trees are correct, since for now I do not want to change the behavior in those (i.e. those trees should continue to use the DP_DPCD_REV register matching what's been the case since the DPCD probing was introduced).
Ick, why were the values different for different branches? That feels wrong, and is why I missed that.
The requirement for changing the DPCD probe address was only introduced/clarified by a recent DP Standard version (with the introducation of LTTPR / UHBR link rates), so in the DRM code this got changed only in v6.16.0. However, this change revealed a bug in the firmwares of an eDP panel and Thunderbolt host, which also had to be fixed/worked around. The only such remaining issue is the latter one tracked at [1], which is now fixed by [2].
Based on all the above I still would like to keep the change only in the v6.16 tree and not backport it to earlier stable trees, until having more confidence that the change doesn't cause an issue for any sink device.
Can you just send a fix-up patch for the one I got wrong?
Ok, I can send a patch for v6.16.y on top of what is already queued there.
It's already in a release :)
thanks,
greg k-h