On Fri, Sep 05, 2025 at 04:55:50PM +0200, Greg Kroah-Hartman wrote: > 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 :)
Ok, missed that. The fix would be only for the next release then, with the above justification. > thanks, > > greg k-h
