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(-)
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;
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), {} };
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), {} };
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
linux-stable-mirror@lists.linaro.org