[PATCH v2 0/3] x86/cpu: Add new Airmont CPU model

[PATCH v2 0/3] x86/cpu: Add new Airmont CPU model

[Rahul Tanwar]

A forthcoming product uses a new variant of Atom Airmont CPU model.
This series adds support for this new CPU model.

Patches are baselined upon Linux 5.3-rc4 at below Git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/core

v2:
* Address review concerns about incorrect patch prefixes & redundant comments.
* Improve summary in cover letter and commit messages.

Rahul Tanwar (3):
  x86/cpu: Use constant definitions for CPU type
  x86/cpu: Add new Intel Atom CPU model name
  x86/cpu: Update init data for new Atom CPU model

 arch/x86/include/asm/intel-family.h | 1 +
 arch/x86/kernel/cpu/common.c        | 1 +
 arch/x86/kernel/cpu/intel.c         | 7 ++++---
 arch/x86/kernel/tsc_msr.c           | 5 +++++
 4 files changed, 11 insertions(+), 3 deletions(-)

-- 
2.11.0

[PATCH v2 1/3] x86/cpu: Use constant definitions for CPU type

[Rahul Tanwar]

Replace direct values usage with constant definitions when access CPU models.

Signed-off-by: Rahul Tanwar <rahul.tanwar@linux.intel.com>
Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
---
 arch/x86/kernel/cpu/intel.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 8d6d92ebeb54..66de4b84c369 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -265,9 +265,9 @@ static void early_init_intel(struct cpuinfo_x86 *c)
 	/* Penwell and Cloverview have the TSC which doesn't sleep on S3 */
 	if (c->x86 == 6) {
 		switch (c->x86_model) {
-		case 0x27:	/* Penwell */
-		case 0x35:	/* Cloverview */
-		case 0x4a:	/* Merrifield */
+		case INTEL_FAM6_ATOM_SALTWELL_MID:
+		case INTEL_FAM6_ATOM_SALTWELL_TABLET:
+		case INTEL_FAM6_ATOM_SILVERMONT_MID:
 			set_cpu_cap(c, X86_FEATURE_NONSTOP_TSC_S3);
 			break;
 		default:
-- 
2.11.0

[tip:x86/cleanups] x86/cpu: Use constant definitions for CPU models

[tip-bot for Rahul Tanwar]

Commit-ID:  bba10c5cab4ddd8725a7998e064fc72c9770c667
Gitweb:     https://git.kernel.org/tip/bba10c5cab4ddd8725a7998e064fc72c9770c667
Author:     Rahul Tanwar <rahul.tanwar@linux.intel.com>
AuthorDate: Fri, 16 Aug 2019 16:18:57 +0800
Committer:  Borislav Petkov <bp@suse.de>
CommitDate: Sat, 17 Aug 2019 10:34:09 +0200

x86/cpu: Use constant definitions for CPU models

Replace model numbers with their respective macro definitions when
comparing CPU models.

Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Rahul Tanwar <rahul.tanwar@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: alan@linux.intel.com
Cc: cheol.yong.kim@intel.com
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: qi-ming.wu@intel.com
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Cc: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/f7a0e142faa953a53d5f81f78055e1b3c793b134.1565940653.git.rahul.tanwar@linux.intel.com
---
 arch/x86/kernel/cpu/intel.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 8d6d92ebeb54..66de4b84c369 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -265,9 +265,9 @@ static void early_init_intel(struct cpuinfo_x86 *c)
 	/* Penwell and Cloverview have the TSC which doesn't sleep on S3 */
 	if (c->x86 == 6) {
 		switch (c->x86_model) {
-		case 0x27:	/* Penwell */
-		case 0x35:	/* Cloverview */
-		case 0x4a:	/* Merrifield */
+		case INTEL_FAM6_ATOM_SALTWELL_MID:
+		case INTEL_FAM6_ATOM_SALTWELL_TABLET:
+		case INTEL_FAM6_ATOM_SILVERMONT_MID:
 			set_cpu_cap(c, X86_FEATURE_NONSTOP_TSC_S3);
 			break;
 		default:

[PATCH v2 2/3] x86/cpu: Add new Intel Atom CPU model name

[Rahul Tanwar]

Add a new variant of Intel Atom Airmont CPU model.

Signed-off-by: Rahul Tanwar <rahul.tanwar@linux.intel.com>
---
 arch/x86/include/asm/intel-family.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h
index 0278aa66ef62..cbbb8250370f 100644
--- a/arch/x86/include/asm/intel-family.h
+++ b/arch/x86/include/asm/intel-family.h
@@ -73,6 +73,7 @@
 
 #define INTEL_FAM6_ATOM_AIRMONT		0x4C /* Cherry Trail, Braswell */
 #define INTEL_FAM6_ATOM_AIRMONT_MID	0x5A /* Moorefield */
+#define INTEL_FAM6_ATOM_AIRMONT_NP	0x75 /* Lightning Mountain */
 
 #define INTEL_FAM6_ATOM_GOLDMONT	0x5C /* Apollo Lake */
 #define INTEL_FAM6_ATOM_GOLDMONT_X	0x5F /* Denverton */
-- 
2.11.0

Re: [PATCH v2 2/3] x86/cpu: Add new Intel Atom CPU model name

[Peter Zijlstra]

On Fri, Aug 16, 2019 at 04:18:58PM +0800, Rahul Tanwar wrote:
> Add a new variant of Intel Atom Airmont CPU model.
> 
> Signed-off-by: Rahul Tanwar <rahul.tanwar@linux.intel.com>
> ---
>  arch/x86/include/asm/intel-family.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h
> index 0278aa66ef62..cbbb8250370f 100644
> --- a/arch/x86/include/asm/intel-family.h
> +++ b/arch/x86/include/asm/intel-family.h
> @@ -73,6 +73,7 @@
>  
>  #define INTEL_FAM6_ATOM_AIRMONT		0x4C /* Cherry Trail, Braswell */
>  #define INTEL_FAM6_ATOM_AIRMONT_MID	0x5A /* Moorefield */
> +#define INTEL_FAM6_ATOM_AIRMONT_NP	0x75 /* Lightning Mountain */

What's _NP ?

Re: [PATCH v2 2/3] x86/cpu: Add new Intel Atom CPU model name

[Luck, Tony]

>> +#define INTEL_FAM6_ATOM_AIRMONT_NP    0x75 /* Lightning Mountain */
> 
> What's _NP ?

Network Processor. But that is too narrow a descriptor. This is going to be used in
other areas besides networking. 

I’m contemplating calling it AIRMONT2

-Tony

Re: [PATCH v2 2/3] x86/cpu: Add new Intel Atom CPU model name

[Shevchenko, Andriy]

On Tue, Aug 20, 2019 at 03:48:05PM +0300, Luck, Tony wrote:
> 
> >> +#define INTEL_FAM6_ATOM_AIRMONT_NP    0x75 /* Lightning Mountain */
> > 
> > What's _NP ?
> 
> Network Processor. But that is too narrow a descriptor. This is going to be used in
> other areas besides networking. 
> 
> I’m contemplating calling it AIRMONT2

We used to have something like that for Silvermont. It was confusing.

commit f2c4db1bd80720cd8cb2a5aa220d9bc9f374f04e
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Aug 7 10:17:27 2018 -0700

    x86/cpu: Sanitize FAM6_ATOM naming


What 2 or 3 or other number means?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 2/3] x86/cpu: Add new Intel Atom CPU model name

[Luck, Tony]

> Author: Peter Zijlstra <peterz@infradead.org>
> Date:   Tue Aug 7 10:17:27 2018 -0700
> 
>    x86/cpu: Sanitize FAM6_ATOM naming
> 
> 
> What 2 or 3 or other number means?

In this case I want it to mean “This is an Airmont derived core. Mostly like original Airmont, so you might see some places where we have the same model specific actions. But enough different that it has a new model ID so places where it is different can do something else”.

-Tony

Re: [PATCH v2 2/3] x86/cpu: Add new Intel Atom CPU model name

[Peter Zijlstra]

On Tue, Aug 20, 2019 at 12:48:05PM +0000, Luck, Tony wrote:
> 
> >> +#define INTEL_FAM6_ATOM_AIRMONT_NP    0x75 /* Lightning Mountain */
> > 
> > What's _NP ?
> 
> Network Processor. But that is too narrow a descriptor. This is going to be used in
> other areas besides networking. 
> 
> I’m contemplating calling it AIRMONT2

What would describe the special sause that warranted a new SOC? If this
thing is marketed as 'Network Processor' then I suppose we can actually
use it, esp. if we're going to see this more, like the MID thing -- that
lived for a while over multiple uarchs.

Note that for the big cores we added the NNPI thing, which was for
Neural Network Processing something.

Re: [PATCH v2 2/3] x86/cpu: Add new Intel Atom CPU model name

[Tanwar, Rahul]

On 20/8/2019 10:57 PM, Peter Zijlstra wrote:
> On Tue, Aug 20, 2019 at 12:48:05PM +0000, Luck, Tony wrote:
>>>> +#define INTEL_FAM6_ATOM_AIRMONT_NP    0x75 /* Lightning Mountain */
>>> What's _NP ?
>> Network Processor. But that is too narrow a descriptor. This is going to be used in
>> other areas besides networking.
>>
>> I’m contemplating calling it AIRMONT2
> What would describe the special sause that warranted a new SOC? If this
> thing is marketed as 'Network Processor' then I suppose we can actually
> use it, esp. if we're going to see this more, like the MID thing -- that
> lived for a while over multiple uarchs.
>
> Note that for the big cores we added the NNPI thing, which was for
> Neural Network Processing something.


INTEL_FAM6_ATOM_AIRMONT_NP was used keeping in mind the recommended

symbol naming form i.e. INTEL_FAM6{OPTFAMILY}_{MICROARCH}{OPTDIFF}

where OPTDIFF is supposed to be the market segment.


This SoC uses AMT (Admantium/Airmont) configuration which is supposed to be

a higher configuration. Looking at other existing examples, it seems that

INTEL_FAM6_ATOM_AIRMONT_PLUS is most appropriate. Would you have any

concerns with _PLUS name ? Thanks.

Re: [PATCH v2 2/3] x86/cpu: Add new Intel Atom CPU model name

[Peter Zijlstra]

On Wed, Aug 21, 2019 at 11:21:43AM +0800, Tanwar, Rahul wrote:
> On 20/8/2019 10:57 PM, Peter Zijlstra wrote:

> > What would describe the special sause that warranted a new SOC? If this
> > thing is marketed as 'Network Processor' then I suppose we can actually
> > use it, esp. if we're going to see this more, like the MID thing -- that
> > lived for a while over multiple uarchs.

> This SoC uses AMT (Admantium/Airmont) configuration which is supposed to be
> a higher configuration.

That's just words without meaning on this end. What's an Adamantium ?
Google doesn't seem to give any sort of clues..

And will we see more of these things, or is it a one off SOC?

> Looking at other existing examples, it seems that
> INTEL_FAM6_ATOM_AIRMONT_PLUS is most appropriate. Would you have any
> concerns with _PLUS name ? Thanks.

Yes, _PLUS is not an existing _OPTDIFF, the uarch is called "Goldmont
Plus", it is the 14nm refresh of the 14nm Goldmont, and predecessor of
Tremont.

Re: [PATCH v2 2/3] x86/cpu: Add new Intel Atom CPU model name

[Luck, Tony]

On Tue, Aug 20, 2019 at 04:57:35PM +0200, Peter Zijlstra wrote:
> On Tue, Aug 20, 2019 at 12:48:05PM +0000, Luck, Tony wrote:
> > 
> > >> +#define INTEL_FAM6_ATOM_AIRMONT_NP    0x75 /* Lightning Mountain */
> > > 
> > > What's _NP ?
> > 
> > Network Processor. But that is too narrow a descriptor. This is going to be used in
> > other areas besides networking. 
> > 
> > I’m contemplating calling it AIRMONT2
> 
> What would describe the special sause that warranted a new SOC? If this
> thing is marketed as 'Network Processor' then I suppose we can actually
> use it, esp. if we're going to see this more, like the MID thing -- that
> lived for a while over multiple uarchs.

The reasons for allocating a new model number are a mystery.
I've seen cases where I thought we'd get a new numnber for sure,
but then just bumped the stepping. I've also seen us allocate a
new number when it didn't look needed (to me, from my OS perspective).

As I mentioned above, there are some folks internally that think
NP == Network Processor is too narrow a pigeonhole for this CPU.

But _NPAOS (Network Processor And Other Stuff) doesn't sound helpful.

> Note that for the big cores we added the NNPI thing, which was for
> Neural Network Processing something.

I'm sure that we will invent all sorts of strings for the "OPTDIFF"
part of the name (many of which will only be used once or twice).

Rationale for "AIRMONT2" is that this is derived from Airmont. So
you'd expect many model specific bits of code to do the same for
this as they did for plain AIRMONT. But in a few corner cases there
will be separate code.

Perhaps I need to update the rubric that I just added to the
head on intel-family.h to say that the MICROARCH element may
be followed by an optional number to differentiate SOCs that
use essentially the same core, but have different model numbers
because of SOC differences outside of the core.

-Tony

Re: [PATCH v2 2/3] x86/cpu: Add new Intel Atom CPU model name

[Thomas Gleixner]

[-- Attachment #1: Type: text/plain, Size: 2265 bytes --]

On Wed, 21 Aug 2019, Luck, Tony wrote:
> On Tue, Aug 20, 2019 at 04:57:35PM +0200, Peter Zijlstra wrote:
> > On Tue, Aug 20, 2019 at 12:48:05PM +0000, Luck, Tony wrote:
> > > 
> > > >> +#define INTEL_FAM6_ATOM_AIRMONT_NP    0x75 /* Lightning Mountain */
> > > > 
> > > > What's _NP ?
> > > 
> > > Network Processor. But that is too narrow a descriptor. This is going to be used in
> > > other areas besides networking. 
> > > 
> > > I’m contemplating calling it AIRMONT2
> > 
> > What would describe the special sause that warranted a new SOC? If this
> > thing is marketed as 'Network Processor' then I suppose we can actually
> > use it, esp. if we're going to see this more, like the MID thing -- that
> > lived for a while over multiple uarchs.
> 
> The reasons for allocating a new model number are a mystery.
> I've seen cases where I thought we'd get a new numnber for sure,
> but then just bumped the stepping. I've also seen us allocate a
> new number when it didn't look needed (to me, from my OS perspective).
> 
> As I mentioned above, there are some folks internally that think
> NP == Network Processor is too narrow a pigeonhole for this CPU.
> 
> But _NPAOS (Network Processor And Other Stuff) doesn't sound helpful.
> 
> > Note that for the big cores we added the NNPI thing, which was for
> > Neural Network Processing something.
> 
> I'm sure that we will invent all sorts of strings for the "OPTDIFF"
> part of the name (many of which will only be used once or twice).
> 
> Rationale for "AIRMONT2" is that this is derived from Airmont. So
> you'd expect many model specific bits of code to do the same for
> this as they did for plain AIRMONT. But in a few corner cases there
> will be separate code.
> 
> Perhaps I need to update the rubric that I just added to the
> head on intel-family.h to say that the MICROARCH element may
> be followed by an optional number to differentiate SOCs that
> use essentially the same core, but have different model numbers
> because of SOC differences outside of the core.

Well, that kinda defeats the idea that the MICROARCH element is about the
micro architecture. If the uarch is the same and it's just the SOC which is
different then it would be better to say AIRMONT_CLIENT_V2 or such

Thanks,

	tglx

Re: [PATCH v2 2/3] x86/cpu: Add new Intel Atom CPU model name

[Peter Zijlstra]

On Wed, Aug 21, 2019 at 01:18:46PM -0700, Luck, Tony wrote:
> On Tue, Aug 20, 2019 at 04:57:35PM +0200, Peter Zijlstra wrote:

> As I mentioned above, there are some folks internally that think
> NP == Network Processor is too narrow a pigeonhole for this CPU.
> 
> But _NPAOS (Network Processor And Other Stuff) doesn't sound helpful.

So what is 'other stuff'; is there really no general term that describes
well what's been done to this SoC; or is it secret and we're in a catch
22 here?

> > Note that for the big cores we added the NNPI thing, which was for
> > Neural Network Processing something.
> 
> I'm sure that we will invent all sorts of strings for the "OPTDIFF"
> part of the name (many of which will only be used once or twice).

That's a bit sad; because as shown by the patches just send out; there
really isn't _that_ much variation right now.

Anyway, lets just give the thing a name; _NP whatever, and we can
rename it if needed.

Re: [PATCH v2 2/3] x86/cpu: Add new Intel Atom CPU model name

[Luck, Tony]

On Thu, Aug 22, 2019 at 12:29:55PM +0200, Peter Zijlstra wrote:
> On Wed, Aug 21, 2019 at 01:18:46PM -0700, Luck, Tony wrote:
> > On Tue, Aug 20, 2019 at 04:57:35PM +0200, Peter Zijlstra wrote:
> 
> > As I mentioned above, there are some folks internally that think
> > NP == Network Processor is too narrow a pigeonhole for this CPU.
> > 
> > But _NPAOS (Network Processor And Other Stuff) doesn't sound helpful.
> 
> So what is 'other stuff'; is there really no general term that describes
> well what's been done to this SoC; or is it secret and we're in a catch
> 22 here?

Since CPU model number is one of the early bits of disclosure
in order to get support upstream in time for launch, safe to
assume that some products will not want to advertise everything
that far ahead.

> > > Note that for the big cores we added the NNPI thing, which was for
> > > Neural Network Processing something.
> > 
> > I'm sure that we will invent all sorts of strings for the "OPTDIFF"
> > part of the name (many of which will only be used once or twice).
> 
> That's a bit sad; because as shown by the patches just send out; there
> really isn't _that_ much variation right now.
> 
> Anyway, lets just give the thing a name; _NP whatever, and we can
> rename it if needed.

Your other patch series shows that you aren't afraid
of a little churn. So sure, we can go with _NP for now
and fix it up later.  It's not like some OEM is going
to make a CPU selection based on the #define name that
we gave it in Linux :-)

-Tony

[PATCH] x86/cpu: Add new Airmont variant to Intel family

[Luck, Tony]

On Thu, Aug 22, 2019 at 11:53:47AM -0700, Luck, Tony wrote:
> On Thu, Aug 22, 2019 at 12:29:55PM +0200, Peter Zijlstra wrote:
> > On Wed, Aug 21, 2019 at 01:18:46PM -0700, Luck, Tony wrote:
> > > On Tue, Aug 20, 2019 at 04:57:35PM +0200, Peter Zijlstra wrote:
> > 
> > > As I mentioned above, there are some folks internally that think
> > > NP == Network Processor is too narrow a pigeonhole for this CPU.
> > > 
> > > But _NPAOS (Network Processor And Other Stuff) doesn't sound helpful.
> > 
> > So what is 'other stuff'; is there really no general term that describes
> > well what's been done to this SoC; or is it secret and we're in a catch
> > 22 here?
> 
> Since CPU model number is one of the early bits of disclosure
> in order to get support upstream in time for launch, safe to
> assume that some products will not want to advertise everything
> that far ahead.
> 
> > > > Note that for the big cores we added the NNPI thing, which was for
> > > > Neural Network Processing something.
> > > 
> > > I'm sure that we will invent all sorts of strings for the "OPTDIFF"
> > > part of the name (many of which will only be used once or twice).
> > 
> > That's a bit sad; because as shown by the patches just send out; there
> > really isn't _that_ much variation right now.
> > 
> > Anyway, lets just give the thing a name; _NP whatever, and we can
> > rename it if needed.
> 
> Your other patch series shows that you aren't afraid
> of a little churn. So sure, we can go with _NP for now
> and fix it up later.  It's not like some OEM is going
> to make a CPU selection based on the #define name that
> we gave it in Linux :-)

From: Tony Luck <tony.luck@intel.com>

One of the use cases for this processor is as a network
processor. So give it an "_NP" tag for now. Could be changed
later if it turns out to group with some other tag.

Signed-off-by: Tony Luck <tony.luck@intel.com>
---
 arch/x86/include/asm/intel-family.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h
index 5c05b2d389c3..23ed388a3a56 100644
--- a/arch/x86/include/asm/intel-family.h
+++ b/arch/x86/include/asm/intel-family.h
@@ -95,6 +95,7 @@
 
 #define INTEL_FAM6_ATOM_AIRMONT		0x4C /* Cherry Trail, Braswell */
 #define INTEL_FAM6_ATOM_AIRMONT_MID	0x5A /* Moorefield */
+#define INTEL_FAM6_ATOM_AIRMONT_NP	0x75 /* Lightning Mountain */
 
 #define INTEL_FAM6_ATOM_GOLDMONT	0x5C /* Apollo Lake */
 #define INTEL_FAM6_ATOM_GOLDMONT_D	0x5F /* Denverton */
-- 
2.20.1

Re: [PATCH] x86/cpu: Add new Airmont variant to Intel family

[Peter Zijlstra]

On Thu, Aug 22, 2019 at 01:35:44PM -0700, Luck, Tony wrote:

> From: Tony Luck <tony.luck@intel.com>
> 
> One of the use cases for this processor is as a network
> processor. So give it an "_NP" tag for now. Could be changed
> later if it turns out to group with some other tag.
> 
> Signed-off-by: Tony Luck <tony.luck@intel.com>
> ---
>  arch/x86/include/asm/intel-family.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h
> index 5c05b2d389c3..23ed388a3a56 100644
> --- a/arch/x86/include/asm/intel-family.h
> +++ b/arch/x86/include/asm/intel-family.h
> @@ -95,6 +95,7 @@
>  
>  #define INTEL_FAM6_ATOM_AIRMONT		0x4C /* Cherry Trail, Braswell */
>  #define INTEL_FAM6_ATOM_AIRMONT_MID	0x5A /* Moorefield */
> +#define INTEL_FAM6_ATOM_AIRMONT_NP	0x75 /* Lightning Mountain */
>  
>  #define INTEL_FAM6_ATOM_GOLDMONT	0x5C /* Apollo Lake */
>  #define INTEL_FAM6_ATOM_GOLDMONT_D	0x5F /* Denverton */

Since it is 'just another airmont' with bits on, should we not then also
add it to all ATOM_AIRMONT sites already present in the kernel?

something like the below; except there were a few sites I skipped
because 'no clue'.

Also, while going over that, it looked like we missed AIRMONT_MID from a
few sites.

I'm thinking we want to add as many of these sites as possible and
correct when adding a new define; esp. for older microarchs that are
already well supported.

---

diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 648260b5f367..56e6875b6882 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -4647,6 +4647,7 @@ __init int intel_pmu_init(void)
 	case INTEL_FAM6_ATOM_SILVERMONT_MID:
 	case INTEL_FAM6_ATOM_AIRMONT:
 	case INTEL_FAM6_ATOM_AIRMONT_MID:
+	case INTEL_FAM6_ATOM_AIRMONT_NP:
 		memcpy(hw_cache_event_ids, slm_hw_cache_event_ids,
 			sizeof(hw_cache_event_ids));
 		memcpy(hw_cache_extra_regs, slm_hw_cache_extra_regs,
diff --git a/arch/x86/events/intel/cstate.c b/arch/x86/events/intel/cstate.c
index 688592b34564..1e999092de22 100644
--- a/arch/x86/events/intel/cstate.c
+++ b/arch/x86/events/intel/cstate.c
@@ -602,6 +602,7 @@ static const struct x86_cpu_id intel_cstates_match[] __initconst = {
 	X86_CSTATES_MODEL(INTEL_FAM6_ATOM_SILVERMONT, slm_cstates),
 	X86_CSTATES_MODEL(INTEL_FAM6_ATOM_SILVERMONT_X, slm_cstates),
 	X86_CSTATES_MODEL(INTEL_FAM6_ATOM_AIRMONT,     slm_cstates),
+	X86_CSTATES_MODEL(INTEL_FAM6_ATOM_AIRMONT_NP,  slm_cstates),
 
 	X86_CSTATES_MODEL(INTEL_FAM6_BROADWELL_CORE,   snb_cstates),
 	X86_CSTATES_MODEL(INTEL_FAM6_BROADWELL_XEON_D, snb_cstates),
diff --git a/arch/x86/events/msr.c b/arch/x86/events/msr.c
index 9431447541e9..fe2323f114c0 100644
--- a/arch/x86/events/msr.c
+++ b/arch/x86/events/msr.c
@@ -72,6 +72,7 @@ static bool test_intel(int idx, void *data)
 	case INTEL_FAM6_ATOM_SILVERMONT:
 	case INTEL_FAM6_ATOM_SILVERMONT_X:
 	case INTEL_FAM6_ATOM_AIRMONT:
+	case INTEL_FAM6_ATOM_AIRMONT_NP:
 
 	case INTEL_FAM6_ATOM_GOLDMONT:
 	case INTEL_FAM6_ATOM_GOLDMONT_X:
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 5cc2d51cc25e..a3ccee6a16a5 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1053,6 +1053,7 @@ static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = {
 	VULNWL_INTEL(ATOM_SILVERMONT_X,		NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS),
 	VULNWL_INTEL(ATOM_SILVERMONT_MID,	NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS),
 	VULNWL_INTEL(ATOM_AIRMONT,		NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS),
+	VULNWL_INTEL(ATOM_AIRMONT_NP,		NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS),
 	VULNWL_INTEL(XEON_PHI_KNL,		NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS),
 	VULNWL_INTEL(XEON_PHI_KNM,		NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS),
 
diff --git a/arch/x86/kernel/tsc_msr.c b/arch/x86/kernel/tsc_msr.c
index 067858fe4db8..bde7a0c8fa8b 100644
--- a/arch/x86/kernel/tsc_msr.c
+++ b/arch/x86/kernel/tsc_msr.c
@@ -64,6 +64,7 @@ static const struct x86_cpu_id tsc_msr_cpu_ids[] = {
 	INTEL_CPU_FAM6(ATOM_SILVERMONT,		freq_desc_byt),
 	INTEL_CPU_FAM6(ATOM_SILVERMONT_MID,	freq_desc_tng),
 	INTEL_CPU_FAM6(ATOM_AIRMONT,		freq_desc_cht),
+	INTEL_CPU_FAM6(ATOM_AIRMONT_NP,		freq_desc_cht),
 	INTEL_CPU_FAM6(ATOM_AIRMONT_MID,	freq_desc_ann),
 	{}
 };
diff --git a/arch/x86/platform/atom/punit_atom_debug.c b/arch/x86/platform/atom/punit_atom_debug.c
index ee6b0780bea1..52990f68af70 100644
--- a/arch/x86/platform/atom/punit_atom_debug.c
+++ b/arch/x86/platform/atom/punit_atom_debug.c
@@ -125,6 +125,7 @@ static const struct x86_cpu_id intel_punit_cpu_ids[] = {
 	ICPU(INTEL_FAM6_ATOM_SILVERMONT, punit_device_byt),
 	ICPU(INTEL_FAM6_ATOM_SILVERMONT_MID,  punit_device_tng),
 	ICPU(INTEL_FAM6_ATOM_AIRMONT,	  punit_device_cht),
+	ICPU(INTEL_FAM6_ATOM_AIRMONT_NP,	  punit_device_cht),
 	{}
 };
 
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index d696f165a50e..4da3aef37836 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -313,6 +313,7 @@ static const struct lpss_device_desc bsw_spi_dev_desc = {
 static const struct x86_cpu_id lpss_cpu_ids[] = {
 	ICPU(INTEL_FAM6_ATOM_SILVERMONT),	/* Valleyview, Bay Trail */
 	ICPU(INTEL_FAM6_ATOM_AIRMONT),	/* Braswell, Cherry Trail */
+	ICPU(INTEL_FAM6_ATOM_AIRMONT_NP),	/* Braswell, Cherry Trail */
 	{}
 };
 
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index cc27d4c59dca..878f5dcce41b 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -1879,6 +1879,7 @@ static const struct x86_cpu_id intel_pstate_cpu_ids[] = {
 	ICPU(INTEL_FAM6_HASWELL_GT3E,		core_funcs),
 	ICPU(INTEL_FAM6_BROADWELL_GT3E,		core_funcs),
 	ICPU(INTEL_FAM6_ATOM_AIRMONT,		airmont_funcs),
+	ICPU(INTEL_FAM6_ATOM_AIRMONT_NP,	airmont_funcs),
 	ICPU(INTEL_FAM6_SKYLAKE_MOBILE,		core_funcs),
 	ICPU(INTEL_FAM6_BROADWELL_X,		core_funcs),
 	ICPU(INTEL_FAM6_SKYLAKE_DESKTOP,	core_funcs),
diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index fa5ff77b8fe4..277757386ddc 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -1070,6 +1070,7 @@ static const struct x86_cpu_id intel_idle_ids[] __initconst = {
 	INTEL_CPU_FAM6(ATOM_SILVERMONT,		idle_cpu_byt),
 	INTEL_CPU_FAM6(ATOM_SILVERMONT_MID,	idle_cpu_tangier),
 	INTEL_CPU_FAM6(ATOM_AIRMONT,		idle_cpu_cht),
+	INTEL_CPU_FAM6(ATOM_AIRMONT_NP,		idle_cpu_cht),
 	INTEL_CPU_FAM6(IVYBRIDGE,		idle_cpu_ivb),
 	INTEL_CPU_FAM6(IVYBRIDGE_X,		idle_cpu_ivt),
 	INTEL_CPU_FAM6(HASWELL_CORE,		idle_cpu_hsw),
diff --git a/drivers/powercap/intel_rapl_common.c b/drivers/powercap/intel_rapl_common.c
index 6df481896b5f..3104ada7d046 100644
--- a/drivers/powercap/intel_rapl_common.c
+++ b/drivers/powercap/intel_rapl_common.c
@@ -981,6 +981,7 @@ static const struct x86_cpu_id rapl_ids[] __initconst = {
 
 	INTEL_CPU_FAM6(ATOM_SILVERMONT, rapl_defaults_byt),
 	INTEL_CPU_FAM6(ATOM_AIRMONT, rapl_defaults_cht),
+	INTEL_CPU_FAM6(ATOM_AIRMONT_NP, rapl_defaults_cht),
 	INTEL_CPU_FAM6(ATOM_SILVERMONT_MID, rapl_defaults_tng),
 	INTEL_CPU_FAM6(ATOM_AIRMONT_MID, rapl_defaults_ann),
 	INTEL_CPU_FAM6(ATOM_GOLDMONT, rapl_defaults_core),
diff --git a/tools/power/x86/turbostat/turbostat.c b/tools/power/x86/turbostat/turbostat.c
index 75fc4fb9901c..3ba4f2a77d3e 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -3228,6 +3228,7 @@ int probe_nhm_msrs(unsigned int family, unsigned int model)
 		pkg_cstate_limits = slv_pkg_cstate_limits;
 		break;
 	case INTEL_FAM6_ATOM_AIRMONT:	/* AMT */
+	case INTEL_FAM6_ATOM_AIRMONT_NP:	/* AMT */
 		pkg_cstate_limits = amt_pkg_cstate_limits;
 		no_MSR_MISC_PWR_MGMT = 1;
 		break;

Re: [PATCH] x86/cpu: Add new Airmont variant to Intel family

[Tanwar, Rahul]

Hi Peter,

On 23/8/2019 5:03 PM, Peter Zijlstra wrote:
> On Thu, Aug 22, 2019 at 01:35:44PM -0700, Luck, Tony wrote:
>
>> From: Tony Luck <tony.luck@intel.com>
>>
>> One of the use cases for this processor is as a network
>> processor. So give it an "_NP" tag for now. Could be changed
>> later if it turns out to group with some other tag.
>>
>> Signed-off-by: Tony Luck <tony.luck@intel.com>
>> ---
>>   arch/x86/include/asm/intel-family.h | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h
>> index 5c05b2d389c3..23ed388a3a56 100644
>> --- a/arch/x86/include/asm/intel-family.h
>> +++ b/arch/x86/include/asm/intel-family.h
>> @@ -95,6 +95,7 @@
>>   
>>   #define INTEL_FAM6_ATOM_AIRMONT		0x4C /* Cherry Trail, Braswell */
>>   #define INTEL_FAM6_ATOM_AIRMONT_MID	0x5A /* Moorefield */
>> +#define INTEL_FAM6_ATOM_AIRMONT_NP	0x75 /* Lightning Mountain */
>>   
>>   #define INTEL_FAM6_ATOM_GOLDMONT	0x5C /* Apollo Lake */
>>   #define INTEL_FAM6_ATOM_GOLDMONT_D	0x5F /* Denverton */
> Since it is 'just another airmont' with bits on, should we not then also
> add it to all ATOM_AIRMONT sites already present in the kernel?
>
> something like the below; except there were a few sites I skipped
> because 'no clue'.
>
> Also, while going over that, it looked like we missed AIRMONT_MID from a
> few sites.
>
> I'm thinking we want to add as many of these sites as possible and
> correct when adding a new define; esp. for older microarchs that are
> already well supported.


[PATCH v2 3/3] that i had sent with this series adds these changes which

are applicable to _NP. Please see below link:

https://lkml.org/lkml/2019/8/16/170

Above patch might have missed few additional points which still apply.

Regards,

Rahul



> ---
>
> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> index 648260b5f367..56e6875b6882 100644
> --- a/arch/x86/events/intel/core.c
> +++ b/arch/x86/events/intel/core.c
> @@ -4647,6 +4647,7 @@ __init int intel_pmu_init(void)
>   	case INTEL_FAM6_ATOM_SILVERMONT_MID:
>   	case INTEL_FAM6_ATOM_AIRMONT:
>   	case INTEL_FAM6_ATOM_AIRMONT_MID:
> +	case INTEL_FAM6_ATOM_AIRMONT_NP:
>   		memcpy(hw_cache_event_ids, slm_hw_cache_event_ids,
>   			sizeof(hw_cache_event_ids));
>   		memcpy(hw_cache_extra_regs, slm_hw_cache_extra_regs,
> diff --git a/arch/x86/events/intel/cstate.c b/arch/x86/events/intel/cstate.c
> index 688592b34564..1e999092de22 100644
> --- a/arch/x86/events/intel/cstate.c
> +++ b/arch/x86/events/intel/cstate.c
> @@ -602,6 +602,7 @@ static const struct x86_cpu_id intel_cstates_match[] __initconst = {
>   	X86_CSTATES_MODEL(INTEL_FAM6_ATOM_SILVERMONT, slm_cstates),
>   	X86_CSTATES_MODEL(INTEL_FAM6_ATOM_SILVERMONT_X, slm_cstates),
>   	X86_CSTATES_MODEL(INTEL_FAM6_ATOM_AIRMONT,     slm_cstates),
> +	X86_CSTATES_MODEL(INTEL_FAM6_ATOM_AIRMONT_NP,  slm_cstates),
>   
>   	X86_CSTATES_MODEL(INTEL_FAM6_BROADWELL_CORE,   snb_cstates),
>   	X86_CSTATES_MODEL(INTEL_FAM6_BROADWELL_XEON_D, snb_cstates),
> diff --git a/arch/x86/events/msr.c b/arch/x86/events/msr.c
> index 9431447541e9..fe2323f114c0 100644
> --- a/arch/x86/events/msr.c
> +++ b/arch/x86/events/msr.c
> @@ -72,6 +72,7 @@ static bool test_intel(int idx, void *data)
>   	case INTEL_FAM6_ATOM_SILVERMONT:
>   	case INTEL_FAM6_ATOM_SILVERMONT_X:
>   	case INTEL_FAM6_ATOM_AIRMONT:
> +	case INTEL_FAM6_ATOM_AIRMONT_NP:
>   
>   	case INTEL_FAM6_ATOM_GOLDMONT:
>   	case INTEL_FAM6_ATOM_GOLDMONT_X:
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 5cc2d51cc25e..a3ccee6a16a5 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -1053,6 +1053,7 @@ static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = {
>   	VULNWL_INTEL(ATOM_SILVERMONT_X,		NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS),
>   	VULNWL_INTEL(ATOM_SILVERMONT_MID,	NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS),
>   	VULNWL_INTEL(ATOM_AIRMONT,		NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS),
> +	VULNWL_INTEL(ATOM_AIRMONT_NP,		NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS),
>   	VULNWL_INTEL(XEON_PHI_KNL,		NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS),
>   	VULNWL_INTEL(XEON_PHI_KNM,		NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS),
>   
> diff --git a/arch/x86/kernel/tsc_msr.c b/arch/x86/kernel/tsc_msr.c
> index 067858fe4db8..bde7a0c8fa8b 100644
> --- a/arch/x86/kernel/tsc_msr.c
> +++ b/arch/x86/kernel/tsc_msr.c
> @@ -64,6 +64,7 @@ static const struct x86_cpu_id tsc_msr_cpu_ids[] = {
>   	INTEL_CPU_FAM6(ATOM_SILVERMONT,		freq_desc_byt),
>   	INTEL_CPU_FAM6(ATOM_SILVERMONT_MID,	freq_desc_tng),
>   	INTEL_CPU_FAM6(ATOM_AIRMONT,		freq_desc_cht),
> +	INTEL_CPU_FAM6(ATOM_AIRMONT_NP,		freq_desc_cht),
>   	INTEL_CPU_FAM6(ATOM_AIRMONT_MID,	freq_desc_ann),
>   	{}
>   };
> diff --git a/arch/x86/platform/atom/punit_atom_debug.c b/arch/x86/platform/atom/punit_atom_debug.c
> index ee6b0780bea1..52990f68af70 100644
> --- a/arch/x86/platform/atom/punit_atom_debug.c
> +++ b/arch/x86/platform/atom/punit_atom_debug.c
> @@ -125,6 +125,7 @@ static const struct x86_cpu_id intel_punit_cpu_ids[] = {
>   	ICPU(INTEL_FAM6_ATOM_SILVERMONT, punit_device_byt),
>   	ICPU(INTEL_FAM6_ATOM_SILVERMONT_MID,  punit_device_tng),
>   	ICPU(INTEL_FAM6_ATOM_AIRMONT,	  punit_device_cht),
> +	ICPU(INTEL_FAM6_ATOM_AIRMONT_NP,	  punit_device_cht),
>   	{}
>   };
>   
> diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
> index d696f165a50e..4da3aef37836 100644
> --- a/drivers/acpi/acpi_lpss.c
> +++ b/drivers/acpi/acpi_lpss.c
> @@ -313,6 +313,7 @@ static const struct lpss_device_desc bsw_spi_dev_desc = {
>   static const struct x86_cpu_id lpss_cpu_ids[] = {
>   	ICPU(INTEL_FAM6_ATOM_SILVERMONT),	/* Valleyview, Bay Trail */
>   	ICPU(INTEL_FAM6_ATOM_AIRMONT),	/* Braswell, Cherry Trail */
> +	ICPU(INTEL_FAM6_ATOM_AIRMONT_NP),	/* Braswell, Cherry Trail */
>   	{}
>   };
>   
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index cc27d4c59dca..878f5dcce41b 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -1879,6 +1879,7 @@ static const struct x86_cpu_id intel_pstate_cpu_ids[] = {
>   	ICPU(INTEL_FAM6_HASWELL_GT3E,		core_funcs),
>   	ICPU(INTEL_FAM6_BROADWELL_GT3E,		core_funcs),
>   	ICPU(INTEL_FAM6_ATOM_AIRMONT,		airmont_funcs),
> +	ICPU(INTEL_FAM6_ATOM_AIRMONT_NP,	airmont_funcs),
>   	ICPU(INTEL_FAM6_SKYLAKE_MOBILE,		core_funcs),
>   	ICPU(INTEL_FAM6_BROADWELL_X,		core_funcs),
>   	ICPU(INTEL_FAM6_SKYLAKE_DESKTOP,	core_funcs),
> diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
> index fa5ff77b8fe4..277757386ddc 100644
> --- a/drivers/idle/intel_idle.c
> +++ b/drivers/idle/intel_idle.c
> @@ -1070,6 +1070,7 @@ static const struct x86_cpu_id intel_idle_ids[] __initconst = {
>   	INTEL_CPU_FAM6(ATOM_SILVERMONT,		idle_cpu_byt),
>   	INTEL_CPU_FAM6(ATOM_SILVERMONT_MID,	idle_cpu_tangier),
>   	INTEL_CPU_FAM6(ATOM_AIRMONT,		idle_cpu_cht),
> +	INTEL_CPU_FAM6(ATOM_AIRMONT_NP,		idle_cpu_cht),
>   	INTEL_CPU_FAM6(IVYBRIDGE,		idle_cpu_ivb),
>   	INTEL_CPU_FAM6(IVYBRIDGE_X,		idle_cpu_ivt),
>   	INTEL_CPU_FAM6(HASWELL_CORE,		idle_cpu_hsw),
> diff --git a/drivers/powercap/intel_rapl_common.c b/drivers/powercap/intel_rapl_common.c
> index 6df481896b5f..3104ada7d046 100644
> --- a/drivers/powercap/intel_rapl_common.c
> +++ b/drivers/powercap/intel_rapl_common.c
> @@ -981,6 +981,7 @@ static const struct x86_cpu_id rapl_ids[] __initconst = {
>   
>   	INTEL_CPU_FAM6(ATOM_SILVERMONT, rapl_defaults_byt),
>   	INTEL_CPU_FAM6(ATOM_AIRMONT, rapl_defaults_cht),
> +	INTEL_CPU_FAM6(ATOM_AIRMONT_NP, rapl_defaults_cht),
>   	INTEL_CPU_FAM6(ATOM_SILVERMONT_MID, rapl_defaults_tng),
>   	INTEL_CPU_FAM6(ATOM_AIRMONT_MID, rapl_defaults_ann),
>   	INTEL_CPU_FAM6(ATOM_GOLDMONT, rapl_defaults_core),
> diff --git a/tools/power/x86/turbostat/turbostat.c b/tools/power/x86/turbostat/turbostat.c
> index 75fc4fb9901c..3ba4f2a77d3e 100644
> --- a/tools/power/x86/turbostat/turbostat.c
> +++ b/tools/power/x86/turbostat/turbostat.c
> @@ -3228,6 +3228,7 @@ int probe_nhm_msrs(unsigned int family, unsigned int model)
>   		pkg_cstate_limits = slv_pkg_cstate_limits;
>   		break;
>   	case INTEL_FAM6_ATOM_AIRMONT:	/* AMT */
> +	case INTEL_FAM6_ATOM_AIRMONT_NP:	/* AMT */
>   		pkg_cstate_limits = amt_pkg_cstate_limits;
>   		no_MSR_MISC_PWR_MGMT = 1;
>   		break;

Re: [PATCH v2 2/3] x86/cpu: Add new Intel Atom CPU model name

[Thomas Gleixner]

On Tue, 20 Aug 2019, Peter Zijlstra wrote:
> On Fri, Aug 16, 2019 at 04:18:58PM +0800, Rahul Tanwar wrote:
> > Add a new variant of Intel Atom Airmont CPU model.
> > 
> > Signed-off-by: Rahul Tanwar <rahul.tanwar@linux.intel.com>
> > ---
> >  arch/x86/include/asm/intel-family.h | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h
> > index 0278aa66ef62..cbbb8250370f 100644
> > --- a/arch/x86/include/asm/intel-family.h
> > +++ b/arch/x86/include/asm/intel-family.h
> > @@ -73,6 +73,7 @@
> >  
> >  #define INTEL_FAM6_ATOM_AIRMONT		0x4C /* Cherry Trail, Braswell */
> >  #define INTEL_FAM6_ATOM_AIRMONT_MID	0x5A /* Moorefield */
> > +#define INTEL_FAM6_ATOM_AIRMONT_NP	0x75 /* Lightning Mountain */
> 
> What's _NP ?

  Nuked Product

[PATCH v2 3/3] x86/cpu: Update init data for new Atom CPU model

[Rahul Tanwar]

Update vulnerability init data for the newly added CPU model.
Enable setting CPU feature applicable for newly added CPU model.
Add TSC MSR freq_desc entry for newly added CPU model.

Signed-off-by: Rahul Tanwar <rahul.tanwar@linux.intel.com>
---
 arch/x86/kernel/cpu/common.c | 1 +
 arch/x86/kernel/cpu/intel.c  | 1 +
 arch/x86/kernel/tsc_msr.c    | 5 +++++
 3 files changed, 7 insertions(+)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 5cc2d51cc25e..c6b4a578b280 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1059,6 +1059,7 @@ static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = {
 	VULNWL_INTEL(CORE_YONAH,		NO_SSB),
 
 	VULNWL_INTEL(ATOM_AIRMONT_MID,		NO_L1TF | MSBDS_ONLY | NO_SWAPGS),
+	VULNWL_INTEL(ATOM_AIRMONT_NP,		NO_L1TF | NO_SWAPGS),
 
 	VULNWL_INTEL(ATOM_GOLDMONT,		NO_MDS | NO_L1TF | NO_SWAPGS),
 	VULNWL_INTEL(ATOM_GOLDMONT_X,		NO_MDS | NO_L1TF | NO_SWAPGS),
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 66de4b84c369..d618be5ed0e2 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -268,6 +268,7 @@ static void early_init_intel(struct cpuinfo_x86 *c)
 		case INTEL_FAM6_ATOM_SALTWELL_MID:
 		case INTEL_FAM6_ATOM_SALTWELL_TABLET:
 		case INTEL_FAM6_ATOM_SILVERMONT_MID:
+		case INTEL_FAM6_ATOM_AIRMONT_NP:
 			set_cpu_cap(c, X86_FEATURE_NONSTOP_TSC_S3);
 			break;
 		default:
diff --git a/arch/x86/kernel/tsc_msr.c b/arch/x86/kernel/tsc_msr.c
index 067858fe4db8..e0cbe4f2af49 100644
--- a/arch/x86/kernel/tsc_msr.c
+++ b/arch/x86/kernel/tsc_msr.c
@@ -58,6 +58,10 @@ static const struct freq_desc freq_desc_ann = {
 	1, { 83300, 100000, 133300, 100000, 0, 0, 0, 0 }
 };
 
+static const struct freq_desc freq_desc_lgm = {
+	1, { 78000, 78000, 78000, 78000, 78000, 78000, 78000, 78000 }
+};
+
 static const struct x86_cpu_id tsc_msr_cpu_ids[] = {
 	INTEL_CPU_FAM6(ATOM_SALTWELL_MID,	freq_desc_pnw),
 	INTEL_CPU_FAM6(ATOM_SALTWELL_TABLET,	freq_desc_clv),
@@ -65,6 +69,7 @@ static const struct x86_cpu_id tsc_msr_cpu_ids[] = {
 	INTEL_CPU_FAM6(ATOM_SILVERMONT_MID,	freq_desc_tng),
 	INTEL_CPU_FAM6(ATOM_AIRMONT,		freq_desc_cht),
 	INTEL_CPU_FAM6(ATOM_AIRMONT_MID,	freq_desc_ann),
+	INTEL_CPU_FAM6(ATOM_AIRMONT_NP,		freq_desc_lgm),
 	{}
 };
 
-- 
2.11.0