Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <1533662247-17575-1-git-send-email-kan.liang@linux.intel.com>
 <1b7cb461-5321-86cf-3031-5ff545c3dc42@linux.intel.com> <20180807174851.GJ2494@hirez.programming.kicks-ass.net>
 <20180807183736.GR4238@tassilo.jf.intel.com> <alpine.DEB.2.21.1808072257080.1672@nanos.tec.linutronix.de>
 <20180807221725.GU4238@tassilo.jf.intel.com> <alpine.DEB.2.21.1808080653120.1672@nanos.tec.linutronix.de>
In-Reply-To: <alpine.DEB.2.21.1808080653120.1672@nanos.tec.linutronix.de>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Wed, 8 Aug 2018 16:07:04 +0200
Message-ID: <CAK8P3a2wfZvDTuHEfYBCa7w2whAbUVU1SsLNkMqHU0EVt8q50w@mail.gmail.com>
Subject: Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake
To:     Thomas Gleixner <tglx@linutronix.de>
Cc:     Andi Kleen <ak@linux.intel.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        kan.liang@linux.intel.com, Ingo Molnar <mingo@redhat.com>,
        Len Brown <len.brown@intel.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        "the arch/x86 maintainers" <x86@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Aug 8, 2018 at 7:16 AM Thomas Gleixner <tglx@linutronix.de> wrote:
> On Tue, 7 Aug 2018, Andi Kleen wrote:
> > > It's even worse with Silvermont.
> > >
> > > So no, the interesting information is the UARCH and the variant of that,
> >
> > With Uarch you mean the core uarch?  That doesn't really work for
> > something like Silvermont or Goldmont.
> >
> > > e.g. UARCH_CLIENT, UARCH_SERVER, UARCH_WHATEVER. All the magic Code Names
> >
> > Right your scheme totally doesn't work on Silvermont because there
> > are multiple client variants.
>
> We have that for the big cores as well:
>
> #define INTEL_FAM6_HASWELL_CORE         0x3C
> #define INTEL_FAM6_HASWELL_X            0x3F
> #define INTEL_FAM6_HASWELL_ULT          0x45
> #define INTEL_FAM6_HASWELL_GT3E         0x46
>
> Why would we treat ATOM differently? It's all the same scheme:
>
> SILVERMONT_CLIENT       0x37         Baytrail, Valleyview
> SILVERMONT_SERVER       0x40         Avaton, Rangely

0x5D SoFIA is another Silvermont variant on the client side, and doesn't
fit well in that scheme I'd say. Calling it SILVERMONT_SOFIA would
probably be best here so people can figure out what it is.

     Arnd