+ 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 > <[email protected]> wrote: > > On Fri, 2017-12-08 at 10:47 -0800, Lucas De Marchi wrote: > > > CFL was missing from intel_early_ids[]. > > > > > > Cc: Ingo Molnar <[email protected]> > > > Cc: H. Peter Anvin <[email protected]> > > > Cc: Thomas Gleixner <[email protected]> > > > Cc: [email protected] > > > Cc: Rodrigo Vivi <[email protected]> > > > Signed-off-by: Lucas De Marchi <[email protected]> > > > > 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. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation _______________________________________________ Intel-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/intel-gfx
