[PATCH 5.10.y 0/3] x86: Complete backports for x86_match_cpu()

[PATCH 5.10.y 0/3] x86: Complete backports for x86_match_cpu()

[Ricardo Neri]

Hi,

Upstream commit 93022482b294 ("x86/cpu: Fix x86_match_cpu() to match just
X86_VENDOR_INTEL") introduced a flags member to struct x86_cpu_id. Bit 0
of x86_cpu.id.flags must be set to 1 for x86_match_cpu() to work correctly.
This upstream commit has been backported to 5.10.y.

Callers that use the X86_MATCH_*() family of macros to compose the argument
of x86_match_cpu() function correctly. Callers that use their own custom
mechanisms may not work if they fail to set x86_cpu_id.flags correctly.

There are three remaining callers in 5.10.y that use their own mechanisms:
a) setup_pcid(), b) rapl_msr_probe(), and c) goodix_add_acpi_gpio_
mappings(). a) caused a regression that Thomas Lindroth reported in [1]. b)
works by luck but it still populates its x86_cpu_id[] array incorrectly. I
am not aware of any reports on c), but inspecting the code reveals that it
will fail to identify INTEL_FAM6_ATOM_SILVERMONT for the reason described
above.

I backported three patches that fix these bugs in mainline. Hopefully the
authors and/or maintainers can ack the backports?

I tested patches 2/3 and 3/3 on Tiger Lake, Alder Lake, and Meteor Lake
systems as the two involved callers behave differently on these systems.
I wrote the testing details in each patch separately. I could not test
patch 1/3 because I do not have access to Bay Trail hardware.

Thanks and BR,
Ricardo
[1]. https://lore.kernel.org/all/eb709d67-2a8d-412f-905d-f3777d897bfa@gmail.com/

Hans de Goede (1):
  Input: goodix - use the new soc_intel_is_byt() helper

Sumeet Pawnikar (1):
  powercap: RAPL: fix invalid initialization for pl4_supported field

Tony Luck (1):
  x86/mm: Switch to new Intel CPU model defines

 arch/x86/mm/init.c                 | 16 ++++++----------
 drivers/input/touchscreen/goodix.c | 18 ++----------------
 drivers/powercap/intel_rapl_msr.c  |  2 +-
 3 files changed, 9 insertions(+), 27 deletions(-)

-- 
2.34.1

[PATCH 5.10.y 1/3] Input: goodix - use the new soc_intel_is_byt() helper

[Ricardo Neri]

From: Hans de Goede <hdegoede@redhat.com>

[ Upstream commit: d176708ffc20332d1c730098d2b111e0b77ece82 ]

Use the new soc_intel_is_byt() helper from linux/platform_data/x86/soc.h.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220131143539.109142-5-hdegoede@redhat.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
[Ricardo: Resolved minor cherry-pick conflict. The file linux/regulator/
 consumer.h is not #included in the upstream version but it is in
 v5.10.y. ]
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
---
I could not test this patch because I do not have access to Bay Trail
hardware. I think there is low risk of new bugs as the patch is rather
trivial.
---
 drivers/input/touchscreen/goodix.c | 18 ++----------------
 1 file changed, 2 insertions(+), 16 deletions(-)

diff --git a/drivers/input/touchscreen/goodix.c b/drivers/input/touchscreen/goodix.c
index 53792a1b6ac3..440091064803 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -23,6 +23,7 @@
 #include <linux/delay.h>
 #include <linux/irq.h>
 #include <linux/interrupt.h>
+#include <linux/platform_data/x86/soc.h>
 #include <linux/regulator/consumer.h>
 #include <linux/slab.h>
 #include <linux/acpi.h>
@@ -718,21 +719,6 @@ static int goodix_reset(struct goodix_ts_data *ts)
 }
 
 #ifdef ACPI_GPIO_SUPPORT
-#include <asm/cpu_device_id.h>
-#include <asm/intel-family.h>
-
-static const struct x86_cpu_id baytrail_cpu_ids[] = {
-	{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_SILVERMONT, X86_FEATURE_ANY, },
-	{}
-};
-
-static inline bool is_byt(void)
-{
-	const struct x86_cpu_id *id = x86_match_cpu(baytrail_cpu_ids);
-
-	return !!id;
-}
-
 static const struct acpi_gpio_params first_gpio = { 0, 0, false };
 static const struct acpi_gpio_params second_gpio = { 1, 0, false };
 
@@ -816,7 +802,7 @@ static int goodix_add_acpi_gpio_mappings(struct goodix_ts_data *ts)
 		dev_info(dev, "Using ACPI INTI and INTO methods for IRQ pin access\n");
 		ts->irq_pin_access_method = IRQ_PIN_ACCESS_ACPI_METHOD;
 		gpio_mapping = acpi_goodix_reset_only_gpios;
-	} else if (is_byt() && ts->gpio_count == 2 && ts->gpio_int_idx == -1) {
+	} else if (soc_intel_is_byt() && ts->gpio_count == 2 && ts->gpio_int_idx == -1) {
 		dev_info(dev, "No ACPI GpioInt resource, assuming that the GPIO order is reset, int\n");
 		ts->irq_pin_access_method = IRQ_PIN_ACCESS_ACPI_GPIO;
 		gpio_mapping = acpi_goodix_int_last_gpios;
-- 
2.34.1

[PATCH 5.10.y 2/3] powercap: RAPL: fix invalid initialization for pl4_supported field

[Ricardo Neri]

From: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>

[ Upstream commit d05b5e0baf424c8c4b4709ac11f66ab726c8deaf ]

The current initialization of the struct x86_cpu_id via
pl4_support_ids[] is partial and wrong. It is initializing
"stepping" field with "X86_FEATURE_ANY" instead of "feature" field.

Use X86_MATCH_INTEL_FAM6_MODEL macro instead of initializing
each field of the struct x86_cpu_id for pl4_supported list of CPUs.
This X86_MATCH_INTEL_FAM6_MODEL macro internally uses another macro
X86_MATCH_VENDOR_FAM_MODEL_FEATURE for X86 based CPU matching with
appropriate initialized values.

Reported-by: Dave Hansen <dave.hansen@intel.com>
Link: https://lore.kernel.org/lkml/28ead36b-2d9e-1a36-6f4e-04684e420260@intel.com
Fixes: eb52bc2ae5b8 ("powercap: RAPL: Add Power Limit4 support for Meteor Lake SoC")
Fixes: b08b95cf30f5 ("powercap: RAPL: Add Power Limit4 support for Alder Lake-N and Raptor Lake-P")
Fixes: 515755906921 ("powercap: RAPL: Add Power Limit4 support for RaptorLake")
Fixes: 1cc5b9a411e4 ("powercap: Add Power Limit4 support for Alder Lake SoC")
Fixes: 8365a898fe53 ("powercap: Add Power Limit4 support")
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
[ Ricardo: I only kept TIGERLAKE in pl4_support_ids as only this model is
  enumerated before this changeset. ]
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
---
I tested this backport on Tiger Lake and Meteor Lake systems. printk()
tells me that the former is detected whereas the latter is not. The
stepping and the feature fields in Tiger Lake are 0 as expected.
---
 drivers/powercap/intel_rapl_msr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/powercap/intel_rapl_msr.c b/drivers/powercap/intel_rapl_msr.c
index 6b68e5ed2081..17692b234f42 100644
--- a/drivers/powercap/intel_rapl_msr.c
+++ b/drivers/powercap/intel_rapl_msr.c
@@ -126,7 +126,7 @@ static int rapl_msr_write_raw(int cpu, struct reg_action *ra)
 
 /* List of verified CPUs. */
 static const struct x86_cpu_id pl4_support_ids[] = {
-	{ X86_VENDOR_INTEL, 6, INTEL_FAM6_TIGERLAKE_L, X86_FEATURE_ANY },
+	X86_MATCH_INTEL_FAM6_MODEL(TIGERLAKE_L, NULL),
 	{}
 };
 
-- 
2.34.1

[PATCH 5.10.y 3/3] x86/mm: Switch to new Intel CPU model defines

[Ricardo Neri]

From: Tony Luck <tony.luck@intel.com>

[ Upstream commit 2eda374e883ad297bd9fe575a16c1dc850346075 ]

New CPU #defines encode vendor and family as well as model.

[ dhansen: vertically align 0's in invlpg_miss_ids[] ]

Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/all/20240424181518.41946-1-tony.luck%40intel.com
[ Ricardo: I used the old match macro X86_MATCH_INTEL_FAM6_MODEL()
  instead of X86_MATCH_VFM() as in the upstream commit.
  I also kept the ALDERLAKE_N name instead of ATOM_GRACEMONT. Both refer
  to the same CPU model. ]
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
---
I tested this backport on an Alder Lake system. Now pr_info("Incomplete
global flushes, disabling PCID") is back in dmesg. I also tested on a
Meteor Lake system, which unaffected by the INVLPG issue. The message in
question is not there before and after the backport, as expected.
---
 arch/x86/mm/init.c | 16 ++++++----------
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index dd15fdee4536..17f1a89e26fc 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -257,21 +257,17 @@ static void __init probe_page_size_mask(void)
 	}
 }
 
-#define INTEL_MATCH(_model) { .vendor  = X86_VENDOR_INTEL,	\
-			      .family  = 6,			\
-			      .model = _model,			\
-			    }
 /*
  * INVLPG may not properly flush Global entries
  * on these CPUs when PCIDs are enabled.
  */
 static const struct x86_cpu_id invlpg_miss_ids[] = {
-	INTEL_MATCH(INTEL_FAM6_ALDERLAKE   ),
-	INTEL_MATCH(INTEL_FAM6_ALDERLAKE_L ),
-	INTEL_MATCH(INTEL_FAM6_ALDERLAKE_N ),
-	INTEL_MATCH(INTEL_FAM6_RAPTORLAKE  ),
-	INTEL_MATCH(INTEL_FAM6_RAPTORLAKE_P),
-	INTEL_MATCH(INTEL_FAM6_RAPTORLAKE_S),
+	X86_MATCH_INTEL_FAM6_MODEL(ALDERLAKE,      0),
+	X86_MATCH_INTEL_FAM6_MODEL(ALDERLAKE_L,    0),
+	X86_MATCH_INTEL_FAM6_MODEL(ALDERLAKE_N,    0),
+	X86_MATCH_INTEL_FAM6_MODEL(RAPTORLAKE,     0),
+	X86_MATCH_INTEL_FAM6_MODEL(RAPTORLAKE_P,   0),
+	X86_MATCH_INTEL_FAM6_MODEL(RAPTORLAKE_S,   0),
 	{}
 };
 
-- 
2.34.1

Re: [PATCH 5.10.y 0/3] x86: Complete backports for x86_match_cpu()

[Greg KH]

On Sat, Sep 28, 2024 at 09:24:28AM -0700, Ricardo Neri wrote:
> Hi,
> 
> Upstream commit 93022482b294 ("x86/cpu: Fix x86_match_cpu() to match just
> X86_VENDOR_INTEL") introduced a flags member to struct x86_cpu_id. Bit 0
> of x86_cpu.id.flags must be set to 1 for x86_match_cpu() to work correctly.
> This upstream commit has been backported to 5.10.y.
> 
> Callers that use the X86_MATCH_*() family of macros to compose the argument
> of x86_match_cpu() function correctly. Callers that use their own custom
> mechanisms may not work if they fail to set x86_cpu_id.flags correctly.
> 
> There are three remaining callers in 5.10.y that use their own mechanisms:
> a) setup_pcid(), b) rapl_msr_probe(), and c) goodix_add_acpi_gpio_
> mappings(). a) caused a regression that Thomas Lindroth reported in [1]. b)
> works by luck but it still populates its x86_cpu_id[] array incorrectly. I
> am not aware of any reports on c), but inspecting the code reveals that it
> will fail to identify INTEL_FAM6_ATOM_SILVERMONT for the reason described
> above.
> 
> I backported three patches that fix these bugs in mainline. Hopefully the
> authors and/or maintainers can ack the backports?
> 
> I tested patches 2/3 and 3/3 on Tiger Lake, Alder Lake, and Meteor Lake
> systems as the two involved callers behave differently on these systems.
> I wrote the testing details in each patch separately. I could not test
> patch 1/3 because I do not have access to Bay Trail hardware.

This and the 5.15 series now queued up, thanks.

greg k-h