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

[Alex Deucher]

On Wed, Jun 4, 2025 at 10:55 AM Uwe Kleine-König
<u.kleine-koenig at baylibre.com> wrote:
>
> Hello Alex,
>
> On Wed, Jun 04, 2025 at 03:29:58PM +0200, Greg KH wrote:
> > 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 at baylibre.com> wrote:
> > > > On Fri, May 30, 2025 at 04:14:09PM -0400, Alex Deucher wrote:
> > > > > 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.
>
> I'm not sure if my mail was already enough to ensure that
> 1b824eef269db44d068bbc0de74c94a8e8f9ce02 will be backported to stable,
> so that request still stands.
>
> > > 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
>
> Yeah I thought so. The problem isn't per se that there are duplicates,
> but that they are not handled with the needed care. I don't know about
> Greg's tooling, but my confusion would have been greatly reduced if you
> reverted f1c6be3999d2 instead of cfb2d41831ee. That is the older commit
> (with POV = mainline) and the one that has the relevant information (Cc:
> stable and the link to cfb2d41831ee).

The revert cc'd stable so it should go to stable.  You can check the
cherry-picked commits to see what patches they were cherry-picked from
to see if you need to apply them to stable kernels.

>
> Getting this wrong is just a big waste of time and patience (or if the
> backport is missed results in systems breaking for problems that are
> already known and fixed).

Tons of patches end up getting cherry-picked to stable without anyone
even asking for them via Sasha's scripts.  Won't this cause the same
problem?

Alex