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@xxxxxxxxx/
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
