Messages in this thread | | | Date | Wed, 26 Jul 2023 09:17:26 -0300 | From | Jason Gunthorpe <> | Subject | Re: [PATCH 03/11] dt-bindings: Add RISC-V IOMMU bindings |
| |
On Wed, Jul 26, 2023 at 12:26:14PM +0800, Zong Li wrote: > On Wed, Jul 26, 2023 at 11:21 AM Baolu Lu <baolu.lu@linux.intel.com> wrote: > > > > On 2023/7/24 21:23, Zong Li wrote: > > >>>>> In RISC-V IOMMU, certain devices can be set to bypass mode when the > > >>>>> IOMMU is in translation mode. To identify the devices that require > > >>>>> bypass mode by default, does it be sensible to add a property to > > >>>>> indicate this behavior? > > >>>> Bypass mode for a device is a property of that device (similar to dma-coherent) > > >>>> and not of the IOMMU. Other architectures (ARM and x86) never added such > > >>>> a device property for bypass mode so I guess it is NOT ADVISABLE to do it. > > >>>> > > >>>> If this is REALLY required then we can do something similar to the QCOM > > >>>> SMMU driver where they have a whitelist of devices which are allowed to > > >>>> be in bypass mode (i.e. IOMMU_DOMAIN_IDENTITY) based their device > > >>>> compatible string and any device outside this whitelist is > > >>>> blocked by default.
I have a draft patch someplace that consolidated all this quirk checking into the core code. Generally the expectation is that any device behind an iommu is fully functional in all modes. The existing quirks are for HW defects that make some devices not work properly. In this case the right outcome seems to be effectively blocking them from using the iommu.
So, you should explain a lot more what "require bypass mode" means in the RISCV world and why any device would need it.
Jason
| |