Re: [PATCH v5 1/1] RISC-V: Add common csr_read_num() and csr_write_num() functions

[Anup Patel]

On Fri, Apr 3, 2026 at 1:55 PM Paul Walmsley <pjw@xxxxxxxxxx> wrote:
>
> Hi Anup,
>
> On Wed, 4 Feb 2026, Anup Patel wrote:
>
> > From: Anup Patel <apatel@xxxxxxxxxxxxxxxx>
> >
> > 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.
> >
> > Also, the RISC-V ACPI FFH specification allows arbitrary CSR number
> > as CPPC register and the RISC-V SBI specification allows arbitrary
> > CSR number as PMU hardware counter. This means ACPI CPPC driver and
> > RISC-V PMU driver no longer need to do sanity checks on CSR number
> > which are now done by the common csr_read_num() and csr_write_num()
> > functions.
>
> I recall that when we discussed this patch on a call a few months ago, it
> was brought up that it seemed useful to restrict which CSRs could be read
> or written at runtime, on a per-vendor basis.  That way, the FFH interface
> couldn't be used to read or write custom CSRs that had nothing to do with
> CPPC or PMU functions.
>
> Are you still planning to implement that change?
>

The current csr_read_num() and csr_write_num() only allows
HPM counters and custom CSR space (as defined by the Priv
spec) to be accessible via ACPI FFH. The ACPI FFH interface
is very flexible and allows vendors to specify the CSR number
in the ACPI table itself so we don't need to compile kernel on
per-vendor basis.

In other words, the current approach allows same Linux kernel
image for multiple vendor even if they use custom CSRs in their
ACPI FFH interface.

Regards,
Anup