From: Ben Dooks <ben.dooks@codethink.co.uk>
To: Anup Patel <anup@brainfault.org>
Cc: Anup Patel <apatel@ventanamicro.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Arnd Bergmann <arnd@arndb.de>,
linux-kernel@vger.kernel.org,
Heinrich Schuchardt <heinrich.schuchardt@canonical.com>,
Atish Patra <atishp@atishpatra.org>,
linux-riscv@lists.infradead.org,
Nikita Shubin <n.shubin@yadro.com>
Subject: Re: [PATCH v2] RISC-V: Add mvendorid, marchid, and mimpid to /proc/cpuinfo output
Date: Wed, 27 Jul 2022 11:12:14 +0100 [thread overview]
Message-ID: <20a94c3c-85ed-2227-458e-60c780fd4ad7@codethink.co.uk> (raw)
In-Reply-To: <CAAhSdy1tnTDv0AVyo=5FD=aE070ds6qYGGhdup+8jUqr3M66qA@mail.gmail.com>
On 27/07/2022 11:06, Anup Patel wrote:
> On Wed, Jul 27, 2022 at 2:25 PM Ben Dooks <ben.dooks@codethink.co.uk> wrote:
>>
>> On 27/07/2022 05:38, Anup Patel wrote:
>>> Identifying the underlying RISC-V implementation can be important
>>> for some of the user space applications. For example, the perf tool
>>> uses arch specific CPU implementation id (i.e. CPUID) to select a
>>> JSON file describing custom perf events on a CPU.
>>>
>>> Currently, there is no way to identify RISC-V implementation so we
>>> add mvendorid, marchid, and mimpid to /proc/cpuinfo output.
>>>
>>> Signed-off-by: Anup Patel <apatel@ventanamicro.com>
>>> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
>>> Tested-by: Nikita Shubin <n.shubin@yadro.com>
>>> ---
>>> Changes since v1:
>>> - Use IS_ENABLED() to check CONFIG defines
>>> - Added RB and TB tags in commit description
>>> ---
>>> arch/riscv/kernel/cpu.c | 51 +++++++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 51 insertions(+)
>>>
>>> diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c
>>> index fba9e9f46a8c..04bcc91c91ea 100644
>>> --- a/arch/riscv/kernel/cpu.c
>>> +++ b/arch/riscv/kernel/cpu.c
>>> @@ -3,10 +3,13 @@
>>> * Copyright (C) 2012 Regents of the University of California
>>> */
>>>
>>> +#include <linux/cpu.h>
>>> #include <linux/init.h>
>>> #include <linux/seq_file.h>
>>> #include <linux/of.h>
>>> +#include <asm/csr.h>
>>> #include <asm/hwcap.h>
>>> +#include <asm/sbi.h>
>>> #include <asm/smp.h>
>>> #include <asm/pgtable.h>
>>>
>>> @@ -64,6 +67,50 @@ int riscv_of_parent_hartid(struct device_node *node)
>>> }
>>>
>>> #ifdef CONFIG_PROC_FS
>>> +
>>> +struct riscv_cpuinfo {
>>> + unsigned long mvendorid;
>>> + unsigned long marchid;
>>> + unsigned long mimpid;
>>> +};
>>> +static DEFINE_PER_CPU(struct riscv_cpuinfo, riscv_cpuinfo);
>>> +
>>> +static int riscv_cpuinfo_starting(unsigned int cpu)
>>> +{
>>> + struct riscv_cpuinfo *ci = this_cpu_ptr(&riscv_cpuinfo);
>>> +
>>> +#if IS_ENABLED(CONFIG_RISCV_SBI)
>>> + ci->mvendorid = sbi_spec_is_0_1() ? 0 : sbi_get_mvendorid();
>>> + ci->marchid = sbi_spec_is_0_1() ? 0 : sbi_get_marchid();
>>> + ci->mimpid = sbi_spec_is_0_1() ? 0 : sbi_get_mimpid();
>>
>> how about:
>>
>> if (IS_ENABLED(CONFIG_RISCV_SBI)) {
>> ...
>> } ... {
>>
>> or maybe even:
>>
>>
>> if (IS_ENABLED(CONFIG_RISCV_SBI)) {
>> if (sbi_spec_is_0_1()) {
>> ...
>> }
>> } ... {
>>
>> would mean better compile coverage (at the slight exepnese of
>> having "false" sbi_spec_is_0_1() implemenation
>
> Most of the sbi_xyz() functions are not available for NoMMU
> kernel so using "if (IS_ENABLED())" results in compile error.
How about defining "false" versions for no-mmu case and try
and avoid these #if mountains?
>>
>>> +#elif IS_ENABLED(CONFIG_RISCV_M_MODE)
>>> + ci->mvendorid = csr_read(CSR_MVENDORID);
>>> + ci->marchid = csr_read(CSR_MARCHID);
>>> + ci->mimpid = csr_read(CSR_MIMPID);
>>> +#else
>>> + ci->mvendorid = 0;
>>> + ci->marchid = 0;
>>> + ci->mimpid = 0;
>>> +#endif
>>
>> Would it be easier to zero out all the fields first and then fill them
>> in if supported?
>
> Clearing out fields before "#if" ladder results in dead assignments.
Not sure which is worse here, the #if ladder or some possibly dead
assignments.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
https://www.codethink.co.uk/privacy.html
next prev parent reply other threads:[~2022-07-27 10:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-27 4:38 Anup Patel
2022-07-27 8:31 ` Conor.Dooley
2022-07-27 8:55 ` Ben Dooks
2022-07-27 10:06 ` Anup Patel
2022-07-27 10:12 ` Ben Dooks [this message]
2022-07-27 11:53 ` Anup Patel
2022-08-11 5:05 ` Anup Patel
2022-10-04 2:54 ` Palmer Dabbelt
2022-10-04 3:44 ` Anup Patel
2022-10-04 4:35 ` Palmer Dabbelt
2022-10-13 21:25 ` Palmer Dabbelt
2022-10-04 4:30 ` Anup Patel
2022-10-11 7:59 ` Heiko Stuebner
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=20a94c3c-85ed-2227-458e-60c780fd4ad7@codethink.co.uk \
--to=ben.dooks@codethink.co.uk \
--cc=anup@brainfault.org \
--cc=apatel@ventanamicro.com \
--cc=arnd@arndb.de \
--cc=atishp@atishpatra.org \
--cc=heinrich.schuchardt@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=n.shubin@yadro.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.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
all inboxes | Powered by JetHome®