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

[Vivian Wang]

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