| Message ID | 20171208184752.25974-1-lucas.demarchi@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Dec 08, 2017 at 06:47:52PM +0000, 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> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> > --- > > Like it was done for other platforms, ideally we should get an ack from x86 > maintainers and apply this through the drm-intel tree. > > arch/x86/kernel/early-quirks.c | 1 + > include/drm/i915_pciids.h | 6 ++++++ > 2 files changed, 7 insertions(+) > > diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c > index 1e82f787c160..c87560e1e3ef 100644 > --- a/arch/x86/kernel/early-quirks.c > +++ b/arch/x86/kernel/early-quirks.c > @@ -527,6 +527,7 @@ static const struct pci_device_id intel_early_ids[] __initconst = { > INTEL_SKL_IDS(&gen9_early_ops), > INTEL_BXT_IDS(&gen9_early_ops), > INTEL_KBL_IDS(&gen9_early_ops), > + INTEL_CFL_IDS(&gen9_early_ops), > INTEL_GLK_IDS(&gen9_early_ops), > INTEL_CNL_IDS(&gen9_early_ops), > }; > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h > index 972a25633525..c65e4489006d 100644 > --- a/include/drm/i915_pciids.h > +++ b/include/drm/i915_pciids.h > @@ -392,6 +392,12 @@ > INTEL_VGA_DEVICE(0x3EA8, info), /* ULT GT3 */ \ > INTEL_VGA_DEVICE(0x3EA5, info) /* ULT GT3 */ > > +#define INTEL_CFL_IDS(info) \ > + INTEL_CFL_S_GT1_IDS(info), \ > + INTEL_CFL_S_GT2_IDS(info), \ > + INTEL_CFL_H_GT2_IDS(info), \ > + INTEL_CFL_U_GT3_IDS(info) > + > /* CNL U 2+2 */ > #define INTEL_CNL_U_GT2_IDS(info) \ > INTEL_VGA_DEVICE(0x5A52, info), \ > -- > 2.14.3 >
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 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. Counting from the first CFL PCI addition, this should have following tags (adding them to this mail); Fixes: b056f8f3d6b9 ("drm/i915/cfl: Add Coffee Lake PCI IDs for S Skus.") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: David Airlie <airlied@linux.ie> Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v4.13+ Please improve the commit message to describe why the code is critical to be there and what is the impact on systems without the code. (Should be something about RAM being arbitarily overwritten if you keep using UEFI framebuffer for example, depending on how BIOS has set up the e820 map.) Regards, Joonas > --- > > Like it was done for other platforms, ideally we should get an ack from x86 > maintainers and apply this through the drm-intel tree. > > arch/x86/kernel/early-quirks.c | 1 + > include/drm/i915_pciids.h | 6 ++++++ > 2 files changed, 7 insertions(+) > > diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c > index 1e82f787c160..c87560e1e3ef 100644 > --- a/arch/x86/kernel/early-quirks.c > +++ b/arch/x86/kernel/early-quirks.c > @@ -527,6 +527,7 @@ static const struct pci_device_id intel_early_ids[] __initconst = { > INTEL_SKL_IDS(&gen9_early_ops), > INTEL_BXT_IDS(&gen9_early_ops), > INTEL_KBL_IDS(&gen9_early_ops), > + INTEL_CFL_IDS(&gen9_early_ops), > INTEL_GLK_IDS(&gen9_early_ops), > INTEL_CNL_IDS(&gen9_early_ops), > }; > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h > index 972a25633525..c65e4489006d 100644 > --- a/include/drm/i915_pciids.h > +++ b/include/drm/i915_pciids.h > @@ -392,6 +392,12 @@ > INTEL_VGA_DEVICE(0x3EA8, info), /* ULT GT3 */ \ > INTEL_VGA_DEVICE(0x3EA5, info) /* ULT GT3 */ > > +#define INTEL_CFL_IDS(info) \ > + INTEL_CFL_S_GT1_IDS(info), \ > + INTEL_CFL_S_GT2_IDS(info), \ > + INTEL_CFL_H_GT2_IDS(info), \ > + INTEL_CFL_U_GT3_IDS(info) > + > /* CNL U 2+2 */ > #define INTEL_CNL_U_GT2_IDS(info) \ > INTEL_VGA_DEVICE(0x5A52, info), \
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. > 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. > > Counting from the first CFL PCI addition, this should have following > tags (adding them to this mail); > > Fixes: b056f8f3d6b9 ("drm/i915/cfl: Add Coffee Lake PCI IDs for S Skus.") > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> > Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> > Cc: Jani Nikula <jani.nikula@linux.intel.com> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> > Cc: David Airlie <airlied@linux.ie> > Cc: intel-gfx@lists.freedesktop.org > Cc: dri-devel@lists.freedesktop.org > Cc: <stable@vger.kernel.org> # v4.13+ > > Please improve the commit message to describe why the code is critical > to be there and what is the impact on systems without the code. (Should > be something about RAM being arbitarily overwritten if you keep using > UEFI framebuffer for example, depending on how BIOS has set up the e820 > map.) Noted. thanks Lucas De Marchi > > Regards, Joonas > >> --- >> >> Like it was done for other platforms, ideally we should get an ack from x86 >> maintainers and apply this through the drm-intel tree. >> >> arch/x86/kernel/early-quirks.c | 1 + >> include/drm/i915_pciids.h | 6 ++++++ >> 2 files changed, 7 insertions(+) >> >> diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c >> index 1e82f787c160..c87560e1e3ef 100644 >> --- a/arch/x86/kernel/early-quirks.c >> +++ b/arch/x86/kernel/early-quirks.c >> @@ -527,6 +527,7 @@ static const struct pci_device_id intel_early_ids[] __initconst = { >> INTEL_SKL_IDS(&gen9_early_ops), >> INTEL_BXT_IDS(&gen9_early_ops), >> INTEL_KBL_IDS(&gen9_early_ops), >> + INTEL_CFL_IDS(&gen9_early_ops), >> INTEL_GLK_IDS(&gen9_early_ops), >> INTEL_CNL_IDS(&gen9_early_ops), >> }; >> diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h >> index 972a25633525..c65e4489006d 100644 >> --- a/include/drm/i915_pciids.h >> +++ b/include/drm/i915_pciids.h >> @@ -392,6 +392,12 @@ >> INTEL_VGA_DEVICE(0x3EA8, info), /* ULT GT3 */ \ >> INTEL_VGA_DEVICE(0x3EA5, info) /* ULT GT3 */ >> >> +#define INTEL_CFL_IDS(info) \ >> + INTEL_CFL_S_GT1_IDS(info), \ >> + INTEL_CFL_S_GT2_IDS(info), \ >> + INTEL_CFL_H_GT2_IDS(info), \ >> + INTEL_CFL_U_GT3_IDS(info) >> + >> /* CNL U 2+2 */ >> #define INTEL_CNL_U_GT2_IDS(info) \ >> INTEL_VGA_DEVICE(0x5A52, info), \ > -- > 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
+ 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. Regards, Joonas
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. Lucas De Marchi
On Tue, 12 Dec 2017, Lucas De Marchi <lucas.de.marchi@gmail.com> 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. 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.
On Mon, 11 Dec 2017, Lucas De Marchi <lucas.de.marchi@gmail.com> 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. We'll need Fixes: no matter what to tell our scripts to pick this up for v4.15 even. Otherwise this might slip to the queue targeting v4.16! BR, Jani.
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
On Wed, Dec 13, 2017 at 2:11 AM, Jani Nikula <jani.nikula@linux.intel.com> wrote: > On Tue, 12 Dec 2017, Lucas De Marchi <lucas.de.marchi@gmail.com> 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. > > There's a cc: stable annotation for dependencies like that, see stable Yep, that's why I suggested the alternative. I think bring those commits to stable will be better because they will always cause conflicts on future backports. If we have them applied it will make future backports to apply cleanly rather than needing to diverge more from master. > kernel rules. I think Greg has stated a preference for picking up > dependencies rather than having manually backported patches. Great. I will follow that approach for v2. thanks Lucas De Marchi
diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c index 1e82f787c160..c87560e1e3ef 100644 --- a/arch/x86/kernel/early-quirks.c +++ b/arch/x86/kernel/early-quirks.c @@ -527,6 +527,7 @@ static const struct pci_device_id intel_early_ids[] __initconst = { INTEL_SKL_IDS(&gen9_early_ops), INTEL_BXT_IDS(&gen9_early_ops), INTEL_KBL_IDS(&gen9_early_ops), + INTEL_CFL_IDS(&gen9_early_ops), INTEL_GLK_IDS(&gen9_early_ops), INTEL_CNL_IDS(&gen9_early_ops), }; diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index 972a25633525..c65e4489006d 100644 --- a/include/drm/i915_pciids.h +++ b/include/drm/i915_pciids.h @@ -392,6 +392,12 @@ INTEL_VGA_DEVICE(0x3EA8, info), /* ULT GT3 */ \ INTEL_VGA_DEVICE(0x3EA5, info) /* ULT GT3 */ +#define INTEL_CFL_IDS(info) \ + INTEL_CFL_S_GT1_IDS(info), \ + INTEL_CFL_S_GT2_IDS(info), \ + INTEL_CFL_H_GT2_IDS(info), \ + INTEL_CFL_U_GT3_IDS(info) + /* CNL U 2+2 */ #define INTEL_CNL_U_GT2_IDS(info) \ INTEL_VGA_DEVICE(0x5A52, info), \
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> --- Like it was done for other platforms, ideally we should get an ack from x86 maintainers and apply this through the drm-intel tree. arch/x86/kernel/early-quirks.c | 1 + include/drm/i915_pciids.h | 6 ++++++ 2 files changed, 7 insertions(+)