From: Yao Zi <ziyao@disroot.org>
To: Anup Patel <apatel@ventanamicro.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
Alexandre Ghiti <alex@ghiti.fr>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Anup Patel <anup@brainfault.org>,
Atish Patra <atish.patra@linux.dev>,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
linux-riscv@lists.infradead.org,
Andrew Jones <ajones@ventanamicro.com>,
Will Deacon <will@kernel.org>, Len Brown <lenb@kernel.org>
Subject: Re: [PATCH v2 2/2] RISC-V: Add common csr_read_num() and csr_write_num() functions
Date: Tue, 19 Aug 2025 04:13:27 +0000 [thread overview]
Message-ID: <aKP553e1S5RCYNhU@pie> (raw)
In-Reply-To: <CAK9=C2XmDGOz9_euC4vtchOxr+8f+m+9zZYVewCc2s7GZhd4Pw@mail.gmail.com>
On Tue, Aug 19, 2025 at 09:00:03AM +0530, Anup Patel wrote:
> On Tue, Aug 19, 2025 at 8:56 AM Yao Zi <ziyao@disroot.org> wrote:
> >
> > On Mon, Aug 18, 2025 at 08:06:00PM +0530, Anup Patel wrote:
> > > In RISC-V, there is no CSR read/write instruction which takes CSR
> > > number via register so add common csr_read_num() and csr_write_num()
> > > functions which allow accessing certain CSRs by passing CSR number
> > > as parameter. These common functions will be first used by the
> > > ACPI CPPC driver and RISC-V PMU driver.
> > >
> > > Signed-off-by: Anup Patel <apatel@ventanamicro.com>
> > > Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
> > > ---
> > > arch/riscv/include/asm/csr.h | 3 +
> > > arch/riscv/kernel/Makefile | 1 +
> > > arch/riscv/kernel/csr.c | 165 +++++++++++++++++++++++++++++++++++
> > > drivers/acpi/riscv/cppc.c | 17 ++--
> > > drivers/perf/riscv_pmu.c | 54 ++----------
> > > 5 files changed, 184 insertions(+), 56 deletions(-)
> > > create mode 100644 arch/riscv/kernel/csr.c
> > >
> > > diff --git a/arch/riscv/include/asm/csr.h b/arch/riscv/include/asm/csr.h
> > > index 6fed42e37705..1540626b3540 100644
> > > --- a/arch/riscv/include/asm/csr.h
> > > +++ b/arch/riscv/include/asm/csr.h
> > > @@ -575,6 +575,9 @@
> > > : "memory"); \
> > > })
> > >
> > > +extern unsigned long csr_read_num(unsigned long csr_num, int *out_err);
> > > +extern void csr_write_num(unsigned long csr_num, unsigned long val, int *out_err);
> >
> > I think it's more consistent to directly return the error code, and for
> > csr_read_num, we could pass out the read value by a pointer. e.g.
> >
> > int csr_read_num(unsigned long csr_num, unsigned long *val);
> > int csr_write_num(unsigned long csr_num, unsigned long val);
> >
> > This allows the caller to eliminate a variable for temporarily storing
> > the error code if they use it just after the invokation, and fits the
> > common convention of Linux better.
>
> Drew had similar comments so see my response in the previous
> patch revision. (Refer, https://www.spinics.net/lists/kernel/msg5808113.html)
Thanks for the reference.
> I had considered this but the problem with this approach is that
> individual switch cases in csr_read_num() become roughly 4
> instructions because value read from CSR has to written to a memory
> location.
You could return a structure smaller than or equal to 2 * XLEN from
csr_read_num(), according to the ABI it could be passed in a0 and a1 and
thus should require no memory operation.
Let's assume we have
struct __csr_read_ret {
long error;
unsigned long value;
};
struct __csr_read_ret __csr_read_num(unsigned long csr_num);
Then a wrapper like
/* piece of untested code */
static inline int csr_read_num(unsigned long csr_num,
unsigned long *val)
{
struct __csr_read_ret ret = __csr_read_num(csr_num);
*val = ret.value;
return ret.error;
}
could provide an interface that I've talked about earlier, and it
follows the kernel's convention.
> The current approach results in just 2 instructions for each
> switch-case. Additionally, the current prototypes of csr_read_num()
> and csr_write_num() are closer to csr_read() and csr_write()
> respectively.
But csr_read() and csr_write() never directly raise errors that is
expected to be handled by the caller. I don't think it's a fair
comparison.
> Regards,
> Anup
Best regards,
Yao Zi
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2025-08-19 4:16 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-18 14:35 [PATCH v2 0/2] Common csr_read_num() and csr_write_num() for RISC-V Anup Patel
2025-08-18 14:35 ` [PATCH v2 1/2] ACPI: RISC-V: Fix FFH_CPPC_CSR error handling Anup Patel
2025-08-18 19:26 ` Atish Patra
2025-08-19 4:02 ` Nutty.Liu
2025-08-19 4:25 ` Sunil V L
2025-08-20 7:12 ` Alexandre Ghiti
2025-08-18 14:36 ` [PATCH v2 2/2] RISC-V: Add common csr_read_num() and csr_write_num() functions Anup Patel
2025-08-18 14:56 ` Andrew Jones
2025-08-18 19:29 ` Atish Patra
2025-08-19 3:26 ` Yao Zi
2025-08-19 3:30 ` Anup Patel
2025-08-19 4:13 ` Yao Zi [this message]
2025-08-19 11:01 ` Anup Patel
2025-08-19 4:04 ` Nutty.Liu
2025-09-17 2:40 ` [PATCH v2 0/2] Common csr_read_num() and csr_write_num() for RISC-V patchwork-bot+linux-riscv
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=aKP553e1S5RCYNhU@pie \
--to=ziyao@disroot.org \
--cc=ajones@ventanamicro.com \
--cc=alex@ghiti.fr \
--cc=anup@brainfault.org \
--cc=apatel@ventanamicro.com \
--cc=atish.patra@linux.dev \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=rafael@kernel.org \
--cc=will@kernel.org \
/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