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 9:26 PM Paul Walmsley <pjw@xxxxxxxxxx> wrote:
>
> 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.
>

We can't use FFH interface to read and write custom CSRs
from any part of the kernel. This is because ACPI FFH encoding
is specific to a subsystem. Currently, RISC-V ACPI FFH encoding
is only defined for LPI states and CPPC registers. Out of these,
only CPPC FFH encoding allows specifying custom CSRs.

Regards,
Anup