[Intel-gfx] [PATCH] x86/gpu: add CFL to early quirks
Lucas De Marchi
lucas.de.marchi at gmail.com
Wed Dec 13 00:17:25 UTC 2017
On Tue, Dec 12, 2017 at 1:53 AM, Joonas Lahtinen
<joonas.lahtinen at 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 at 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 at kernel.org>
>> > > Cc: H. Peter Anvin <hpa at zytor.com>
>> > > Cc: Thomas Gleixner <tglx at linutronix.de>
>> > > Cc: x86 at kernel.org
>> > > Cc: Rodrigo Vivi <rodrigo.vivi at intel.com>
>> > > Signed-off-by: Lucas De Marchi <lucas.demarchi at 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.
Lucas De Marchi
More information about the Intel-gfx
mailing list