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

[Paul Walmsley]

On Fri, 3 Apr 2026, Anup Patel wrote:

> On Fri, Apr 3, 2026 at 1:55 PM Paul Walmsley <pjw@xxxxxxxxxx> wrote:
> >
> > 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.

I understand that part.  The part that I don't like is that with this 
patch, the FFH interface could also be used to read and write custom CSRs 
that have nothing to do with CPPC or PMU functions.  That doesn't seem 
like a good idea.  What I had in mind was to add a way to restrict the 
custom CSRs that the kernel would allow FFH to use, via a mechanism other 
than the ACPI table - e.g., sysfs, or the kernel command line, etc.


- Paul