Re: [PATCH] Revert "drm/amd/display: more liberal vmin/vmax update for freesync"

[Greg KH <gregkh@linuxfoundation.org>]

On Wed, Jun 04, 2025 at 09:15:14AM -0400, Alex Deucher wrote:
> On Wed, Jun 4, 2025 at 5:40 AM Uwe Kleine-König
> <u.kleine-koenig@baylibre.com> wrote:
> >
> > Hello Alex,
> >
> > On Fri, May 30, 2025 at 04:14:09PM -0400, Alex Deucher wrote:
> > > On Fri, May 30, 2025 at 4:09 PM Aurabindo Pillai
> > > <aurabindo.pillai@amd.com> wrote:
> > > >
> > > > This reverts commit 219898d29c438d8ec34a5560fac4ea8f6b8d4f20 since it
> > > > causes regressions on certain configs. Revert until the issue can be
> > > > isolated and debugged.
> > > >
> > > > Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4238
> > > > Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
> > > > Acked-by: Alex Deucher <alexander.deucher@amd.com>
> > >
> > > Already included in my -fixes PR for this week:
> > > https://lists.freedesktop.org/archives/amd-gfx/2025-May/125350.html
> >
> > Note the way this was done isn't maximally friendly to our stable
> > maintainers though.
> >
> > The commit in your tree (1b824eef269db44d068bbc0de74c94a8e8f9ce02) is a
> > tad better than the patch that Aurabindo sent as it has:
> >
> >         This reverts commit cfb2d41831ee5647a4ae0ea7c24971a92d5dfa0d ...
> >
> > which at least is a known commit and has Cc: stable.
> >
> > However this is still a bit confusing as commit cfb2d41831ee has no Cc:
> > stable, but a duplicate in mainline: f1c6be3999d2 that has Cc: stable.
> >
> > So f1c6be3999d2 was backported to 6.14.7 (commit
> > 4ec308a4104bc71a431c75cc9babf49303645617), 6.12.29 (commit
> > 468034a06a6e8043c5b50f9cd0cac730a6e497b5) and 6.6.91 (commit
> > c8a91debb020298c74bba0b9b6ed720fa98dc4a9). But it might not be obvious
> > that 1b824eef269db44d068bbc0de74c94a8e8f9ce02 needs backporting to trees
> > that don't contain cfb2d41831ee (or a backport of it).
> >
> > Please keep an eye on that change that it gets properly backported.
> 
> DRM patches land in -next first since that is where the developers
> work and then bug fixes get cherry-picked to -fixes.  When a patch is
> cherry-picked to -fixes, we use cherry-pick -x to keep the reference
> to the original commit and then add stable CC's as needed.  See this
> thread for background:
> https://lore.kernel.org/dri-devel/871px5iwbx.fsf@intel.com/T/#t

And that thread shows how the confusion between git ids that are
reverted and committed to the tree cause reverts to get missed with our
automatic tools, so you HAVE to explicitly tag them as cc: stable, which
is not always done :(

thanks,

greg k-h