Re: [PATCH] x86/gpu: add CFL to early quirks

From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Lucas De Marchi <lucas.de.marchi@gmail.com>
Cc: David Airlie <airlied@linux.ie>,
	intel-gfx@lists.freedesktop.org, x86@kernel.org,
	Lucas De Marchi <lucas.demarchi@intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	"H . Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: [PATCH] x86/gpu: add CFL to early quirks
Date: Wed, 13 Dec 2017 12:59:43 +0200	[thread overview]
Message-ID: <1513162783.5228.27.camel@linux.intel.com> (raw)
In-Reply-To: <CAKi4VALES0YOqW6UmGtUDObRBE2hMc3a6KdxK8Ru_Ua5DNLEOQ@mail.gmail.com>

On Tue, 2017-12-12 at 16:17 -0800, Lucas De Marchi wrote:
> On Tue, Dec 12, 2017 at 1:53 AM, Joonas Lahtinen
> <joonas.lahtinen@linux.intel.com> wrote:
> > + Jani, who'll continue with -fixes
> > 
> > On Mon, 2017-12-11 at 13:50 -0800, Lucas De Marchi wrote:
> > > On Mon, Dec 11, 2017 at 2:26 AM, Joonas Lahtinen
> > > <joonas.lahtinen@linux.intel.com> wrote:
> > > > On Fri, 2017-12-08 at 10:47 -0800, Lucas De Marchi wrote:
> > > > > CFL was missing from intel_early_ids[].
> > > > > 
> > > > > Cc: Ingo Molnar <mingo@kernel.org>
> > > > > Cc: H. Peter Anvin <hpa@zytor.com>
> > > > > Cc: Thomas Gleixner <tglx@linutronix.de>
> > > > > Cc: x86@kernel.org
> > > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> > > > 
> > > > This should come with a Fixes: line to be picked up to -fixes. The IDs
> > > 
> > > I thought this didn't deserve CC to stable since alpha support was
> > > removed for CFL only for 4.15.
> > 
> > I don't think system memory corruption is really acceptable even for
> > alpha quality support :P
> > 
> > > > have been added in smaller chunks and reworked after, so backporting
> > > > will be required. For this level of fix, my recommendation would be to
> > > > actively provide a cleanly applying backports to affected stable
> > > > versions.
> > > 
> > > Are you saying this should be proactive rather than reactive? I don't
> > > see this mentioned on
> > > Documentation/process/stable-kernel-rules.rst... the only thing I see
> > > there regarding patches that don't apply
> > > cleanly is that I may bring more patches through a tag for each version.
> > > 
> > > If we are indeed going to cc stable I can submit a v2 with added tags.
> > > If a patch that can be cc'ed to stable
> > > needs to be provided we may need to improve our docs, too.
> > 
> > That's correct. But once Cc:d stable, we can see from the GIT history
> > that it'll bounce back because it won't apply. For this specific case
> > that might cause system memory corruption, I'd make an exception and be
> > proactive.
> 
> Another option would be to cherry-pick
> 0890540e21cf1156b4cf960a4c1c734db4e816f9 and
> 41693fd5237397d3c61b311af0fda1f6f39297c2 so then all commits apply cleanly.

The stable patches should be as minimal as possible to avoid conflicts.
The first one has some potential for extra clashes, but whatever is
guesstimated to cause least conflicts, should be sent.

The tooling automatically picks up Fixes:, which those commits don't
have so it probably needs to be noted when sending the patch that
related commits need to be picked up.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx