From: Punit Agrawal <punitagrawal@gmail.com>
To: Borislav Petkov <bp@alien8.de>
Cc: rjw@rjwysocki.net, wei.huang2@amd.com,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
x86@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
Yazen Ghannam <yazen.ghannam@amd.com>
Subject: Re: [RFC PATCH 3/4] x86/cpu: amd: Define processor families
Date: Wed, 02 Dec 2020 23:13:02 +0900 [thread overview]
Message-ID: <87pn3s2t5d.fsf@stealth> (raw)
In-Reply-To: <20201130140018.GC6019@zn.tnic> (Borislav Petkov's message of "Mon, 30 Nov 2020 15:00:18 +0100")
Hi Boris,
Borislav Petkov <bp@alien8.de> writes:
> On Wed, Nov 25, 2020 at 11:48:46PM +0900, Punit Agrawal wrote:
>> So far, the AMD processor identifier (family, models, stepping) are
>> referred to by raw values making it easy to make mistakes. It is also
>> harder to read and maintain. Additionally, these values are also being
>> used in subsystems outside the arch code where not everybody maybe be
>> as familiar with the processor identifiers.
>>
>> As a first step towards improving the status quo, add macros for the
>> AMD processor families and propagate them through the existing
>> cpu_device_id.h header used for this purpose.
>>
>> Signed-off-by: Punit Agrawal <punitagrawal@gmail.com>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Ingo Molnar <mingo@redhat.com>
>> Cc: Borislav Petkov <bp@alien8.de>
>> Cc: x86@kernel.org
>> ---
>> arch/x86/include/asm/amd-family.h | 18 ++++++++++++++++++
>> arch/x86/include/asm/cpu_device_id.h | 2 ++
>> 2 files changed, 20 insertions(+)
>> create mode 100644 arch/x86/include/asm/amd-family.h
>>
>> diff --git a/arch/x86/include/asm/amd-family.h b/arch/x86/include/asm/amd-family.h
>> new file mode 100644
>> index 000000000000..dff4d13b8e74
>> --- /dev/null
>> +++ b/arch/x86/include/asm/amd-family.h
>> @@ -0,0 +1,18 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +#ifndef _ASM_X86_AMD_FAMILY_H
>> +#define _ASM_X86_AMD_FAMILY_H
>> +
>> +#define AMD_FAM_K5 0x04
>> +#define AMD_FAM_K6 0x05
>> +#define AMD_FAM_K7 0x06
>> +#define AMD_FAM_K8 0x0F
>> +#define AMD_FAM_K10 0x10
>
> Fam 0x10 is Greyhound and a lot more core names. I'd let the AMD folks
> on Cc say what they wanna call it but I don't think K10 was used
> anywhere except outside of AMD. :)
Didn't realize the core was internal only. There are a couple of
instances where the family does shows up arch/x86/kernel/cpu/amd.c so
atleast some of the patches did make it upstream.
>> +#define AMD_FAM_K8_K10_HYBRID 0x11
>
> That was called Griffin so AMD_FAM_GRIFFIN I guess. If not used anywhere
> in the tree, no need to add the define.
I haven't looked to deeply but there's one instance in
arch/x86/kernel/cpu/amd.c - though I wonder if that could be re-written
to rely on a hardware / firmware interface instead.
> Same holds true for the rest of the defines - add them only when
> they're used.
Makes sense - I will follow your suggestion in the next version.
>> +#define AMD_FAM_LLANO 0x12
>> +#define AMD_FAM_BOBCAT 0x14
>> +#define AMD_FAM_BULLDOZER 0x15
>> +#define AMD_FAM_JAGUAR 0x16
>> +#define AMD_FAM_ZEN 0x17
>
> ZEN2 is also 0x17 but different models so this is where the family
> matching scheme doesn't work - you'd need the models too.
Yes, I wasn't sure the best way to handle this so went with the earlier
generation name. I think for such cases, something that looks at the
cpuinfo_x86 structure and decides the family / generation is probably
the way to go.
> 0x18 is HYGON
I missed this one. I'll add it to the list.
Thanks for the review and your comments. I'll wait a bit to see if
there's any further feedback.
Cheers,
Punit
[...]
next prev parent reply other threads:[~2020-12-02 14:14 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-25 14:48 [RFC PATCH 0/4] Add processor to the ignore PSD override list Punit Agrawal
2020-11-25 14:48 ` [RFC PATCH 1/4] cpufreq: acpi-cpufreq: Re-factor overriding ACPI PSD Punit Agrawal
2020-12-07 19:29 ` Wei Huang
2020-12-08 23:31 ` Punit Agrawal
2020-11-25 14:48 ` [RFC PATCH 2/4] cpufreq: acpi-cpufreq: Add processor to the ignore PSD override list Punit Agrawal
2020-12-07 20:20 ` Wei Huang
2020-12-07 20:26 ` Borislav Petkov
2020-12-07 22:07 ` Wei Huang
2020-12-07 22:30 ` Borislav Petkov
2020-12-08 3:44 ` Wei Huang
2020-12-08 23:21 ` Punit Agrawal
2020-12-08 23:32 ` Borislav Petkov
2020-12-11 23:36 ` Punit Agrawal
2020-12-14 12:40 ` Borislav Petkov
2020-12-14 13:27 ` Punit Agrawal
2020-12-14 14:25 ` Borislav Petkov
2020-12-17 13:27 ` Punit Agrawal
2020-11-25 14:48 ` [RFC PATCH 3/4] x86/cpu: amd: Define processor families Punit Agrawal
2020-11-30 14:00 ` Borislav Petkov
2020-12-02 14:13 ` Punit Agrawal [this message]
2020-12-02 16:57 ` Borislav Petkov
2020-11-25 14:48 ` [RFC PATCH 4/4] cpufreq: acpi-cpufreq: Use identifiers for AMD processor family Punit Agrawal
2020-11-30 14:02 ` Borislav Petkov
2020-12-02 14:30 ` Punit Agrawal
2020-12-04 22:44 ` [RFC PATCH 0/4] Add processor to the ignore PSD override list Punit Agrawal
2020-12-07 13:55 ` Rafael J. Wysocki
2020-12-08 23:25 ` Punit Agrawal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pn3s2t5d.fsf@stealth \
--to=punitagrawal@gmail.com \
--cc=bp@alien8.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rjw@rjwysocki.net \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=wei.huang2@amd.com \
--cc=x86@kernel.org \
--cc=yazen.ghannam@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).