Sounds good to me - will update the patches with this on the next
respin, which should get sent out in a moment.
On Tue, 2026-06-30 at 18:05 +0200, Danilo Krummrich wrote:
> On Tue Jun 30, 2026 at 1:53 PM CEST, Andy Shevchenko wrote:
> > On Mon, Jun 29, 2026 at 06:42:33PM -0400, Lyude Paul wrote:
> > > This reverts commit 8302d0afeaec0bc57d951dd085e0cffe997d4d18.
> > >
> > > It turns out this looked like the right fix on some systems, but
> > > it's not -
> > > as this causes runtime PM to actually fail on many a laptop.
> > >
> > > [I have set the fixes to an older commit then the one that is
> > > reverted
> > > here, because when applied with the other patches in this series,
> > > this
> > > appears to /fully/ fix runtime PM in addition to the regression]
> >
> > No need to have this in the commit message, move it to the comment
> > block...
> >
> > > Fixes: 53dac0623853 ("drm/nouveau/gsp: add support for 570.144")
> >
> > I'm not sure, actually, that this is a correct approach. You can't
> > revert
> > something that never appeared (in time range between 53dac0623853
> > and
> > 8302d0afeaec). Have you consulted with the stable kernel process
> > documentation
> > and/or respective maintainers?
>
> I think it should be as simple as picking
>
> Fixes: 8302d0afeaec ("nouveau/gsp: fix suspend/resume regression on
> r570 firmware")
> Cc: <[email protected]> # v6.19+
>
> for this commit and keep patches 2, 3 and 4 as they are.
>
> The commit message of this revert can then explain that the commit
> that was
> attempted to fix with this revert, i.e. commit 53dac0623853
> ("drm/nouveau/gsp:
> add support for 570.144") is fixed with a different, subsequent
> approach.
>
> This seems correct, as reverting a bad fix does not claim to solve
> the original
> problem.
>
> Thanks,
> Danilo
