[Intel-gfx] [PATCH] x86/gpu: add CFL to early quirks

[Jani Nikula]

On Tue, 12 Dec 2017, Lucas De Marchi <lucas.de.marchi at gmail.com> wrote:
> 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.

There's a cc: stable annotation for dependencies like that, see stable
kernel rules. I think Greg has stated a preference for picking up
dependencies rather than having manually backported patches.

BR,
Jani.



-- 
Jani Nikula, Intel Open Source Technology Center