[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3d65c4cc-c002-9e6a-c6ea-fd776968a178@intel.com>
Date: Thu, 20 Oct 2022 10:18:47 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Peter Zijlstra <peterz@...radead.org>,
Rishabh Agrawal <rishabhagr@...omium.org>
Cc: LKML <linux-kernel@...r.kernel.org>, len.brown@...el.com,
drake@...lessm.com, rafael.j.wysocki@...el.com, mingo@...hat.com,
tglx@...utronix.de, vaibhav.shankar@...el.com,
biernacki@...gle.com, zwisler@...gle.com, mattedavis@...gle.com,
Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Feng Tang <feng.tang@...el.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org
Subject: Re: [PATCH v2] Add hardcoded crystal clock for KabyLake
On 10/20/22 10:13, Peter Zijlstra wrote:
> And why, pray *WHY* can't Intel simply write the correct information in
> CPUID leaf 15h. I mean, they defined the leaf, might as well use it, no?
Is the data that's in the leaf just wrong? Doesn't that mean that the
CPUID leaf on these models is violating the architecture contract? That
sounds like something that deserves an erratum.
Is there a documented erratum?
Powered by blists - more mailing lists