[PATCH v1] iommu/riscv: Support 32-bit register accesses

[Guo Ren]

On Thu, Jun 18, 2026 at 11:20 AM Vivian Wang <wangruikang at iscas.ac.cn> wrote:
>
> On 6/15/26 20:38, Guo Ren wrote:
> > Hi Zhanpeng Zhang,
> >
> > I noticed you posted a similar fix recently. However, I had already
> > submitted a similar solution back in September 2025 [1]. It would be
> > great if you could review it. A few concerns with the current patch:
> >
> > 1. Using spin_lock_irqsave in such a small semantic structure is
> > unnecessary. IRQ protection should be provided by the higher-level
> > IOMMU driver interfaces. Many existing call sites already handle IRQ
> > disabling, so adding it here feels redundant and adds avoidable
> > overhead.
> >
> > 2. More critically, the RISCV_IOMMU_32BIT_ACCESS Kconfig option is
> > problematic. According to the RISC-V IOMMU specification (Software
> > Guidelines, “Reading and writing IOMMU registers”):
> >
> >> Registers that are 64-bit wide may be accessed using either a 32-bit
> >> or a 64-bit access.
> > This clearly requires that any hardware supporting 64-bit MMIO access
> > must also support 32-bit MMIO access. Therefore, the IOMMU driver should
> > be built on a 32-bit access base for maximum hardware compatibility.
>
> I agree that the driver should be build with 32-bit accesses to support
> these hardware. However there's one minor thing that I want to propose
> regarding this, for the sake of clarity:
>
> RISC-V IOMMU implementations that do not support 64-bit accesses are not
> fully compliant with the RISC-V IOMMU specification and should not use
> the standard RISC-V identifiers, namely:
>
> - Devicetree compatible riscv,iommu
> - ACPI HID RSCV0004
>
> This, in my opinion, is not only the right thing to do (not claiming to
> be standard hardware without actually being standard hardware), but also
> saves a lot of trouble for operating system developers (yes, there are
> RISC-V operating systems other than Linux out there), since invalid IO
> accesses usually manifest as mysterious access faults (that would
> usually suggest an incorrect IOMMU address), or worse, system hangs.
>
> I would appreciate if the hardware vendors shipping 32-bit-access-only
> IOMMUs would consider this.
>
> Vivian "dramforever" Wang
>

32-bit MMIO access is explicitly supported by the RISC-V IOMMU
specification and is a valid choice (64-bit MMIO access is optional).
64-bit MMIO access is not "free" — it consumes additional interconnect
hardware resources.

Could you elaborate on the concrete benefit of using 64-bit MMIO
access in this driver, for these non-PMU registers? A clear
justification would help evaluate whether the trade-off is worthwhile.


-- 
Best Regards
 Guo Ren