Re: [PATCH v2 1/7] dt-bindings: iommu: riscv: Add bindings for RISC-V IOMMU

Rob Herring
2024-04-22T14:04:18Z

On Thu, Apr 18, 2024 at 09:32:19AM -0700, Tomasz Jeznach wrote:
> Add bindings for the RISC-V IOMMU device drivers.
>
> Co-developed-by: Anup Patel <apatel@ventanamicro.com>
> Signed-off-by: Anup Patel <apatel@ventanamicro.com>
> Signed-off-by: Tomasz Jeznach <tjeznach@rivosinc.com>
> ---
> .../bindings/iommu/riscv,iommu.yaml | 149 ++++++++++++++++++
> MAINTAINERS | 7 +
> 2 files changed, 156 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iommu/riscv,iommu.yaml
>
> diff --git a/Documentation/devicetree/bindings/iommu/riscv,iommu.yaml b/Documentation/devicetree/bindings/iommu/riscv,iommu.yaml
> new file mode 100644
> index 000000000000..d6522ddd43fa
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/riscv,iommu.yaml
> @@ -0,0 +1,149 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iommu/riscv,iommu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: RISC-V IOMMU Architecture Implementation
> +
> +maintainers:
> + - Tomasz Jeznach <tjeznach@rivosinc.com>
> +
> +description: |+
> + The RISC-V IOMMU provides memory address translation and isolation for
> + input and output devices, supporting per-device translation context,
> + shared process address spaces including the ATS and PRI components of
> + the PCIe specification, two stage address translation and MSI remapping.
> + It supports identical translation table format to the RISC-V address
> + translation tables with page level access and protection attributes.
> + Hardware uses in-memory command and fault reporting queues with wired
> + interrupt or MSI notifications.
> +
> + Visit https://github.com/riscv-non-isa/riscv-iommu for more details.
> +
> + For information on assigning RISC-V IOMMU to its peripheral devices,
> + see generic IOMMU bindings.
> +
> +properties:
> + # For PCIe IOMMU hardware compatible property should contain the vendor
> + # and device ID according to the PCI Bus Binding specification.
> + # Since PCI provides built-in identification methods, compatible is not
> + # actually required. For non-PCIe hardware implementations 'riscv,iommu'
> + # should be specified along with 'reg' property providing MMIO location.
> + compatible:
> + oneOf:
> + - items:
> + - const: riscv,pci-iommu
> + - const: pci1efd,edf1

Given the PCI compatible string is a specific vendor and device, it is
more specific than "riscv,pci-iommu" and should come first.

> + - items:
> + - const: pci1efd,edf1

Why do you need to support this without riscv,pci-iommu?

> + - items:
> + - const: riscv,iommu

I agree with what Conor said on this.

Rob