[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161215191748.3xkv252ratsy2tum@pd.tnic>
Date: Thu, 15 Dec 2016 20:17:48 +0100
From: Borislav Petkov <bp@...en8.de>
To: Andy Lutomirski <luto@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>
Cc: x86@...nel.org,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Brian Gerst <brgerst@...il.com>
Subject: Re: [PATCH] x86/cpu: Probe CPUID leaf 6 even when cpuid_level == 6
On Thu, Dec 15, 2016 at 10:14:42AM -0800, Andy Lutomirski wrote:
> A typo (or mis-merge?) resulted in leaf 6 only being probed if
> cpuid_level >= 7.
>
> Fixes: 2ccd71f1b278 ("x86/cpufeature: Move some of the scattered feature bits to x86_capability")
> Signed-off-by: Andy Lutomirski <luto@...nel.org>
> ---
>
> I don't know what CPUs, if any, are affected, and the bug is minor anyway,
> so the major advantage of applying this is to remove a head-scratcher when
> reading the code, I think.
>
> arch/x86/kernel/cpu/common.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index cc9e980c68ec..d61722821b7b 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -667,13 +667,14 @@ void get_cpu_cap(struct cpuinfo_x86 *c)
> c->x86_capability[CPUID_1_EDX] = edx;
> }
>
> + /* Thermal and Power Management Leaf: level 0x00000006 (eax) */
> + if (c->cpuid_level >= 0x00000006)
> + c->x86_capability[CPUID_6_EAX] = cpuid_eax(0x00000006);
> +
> /* Additional Intel-defined flags: level 0x00000007 */
> if (c->cpuid_level >= 0x00000007) {
> cpuid_count(0x00000007, 0, &eax, &ebx, &ecx, &edx);
> -
> c->x86_capability[CPUID_7_0_EBX] = ebx;
> -
> - c->x86_capability[CPUID_6_EAX] = cpuid_eax(0x00000006);
> c->x86_capability[CPUID_7_ECX] = ecx;
> }
>
> --
Yeah,
Acked-by: Borislav Petkov <bp@...e.de>
However, as we talked already, this whole code needs a serious cleanup
so that it reads the max leaf and then read *all* and cache those we
need and do it only once.
Future work anyway.
Thanks.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Powered by blists - more mailing lists