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
