-config IOMMU_DEFAULT_PASSTHROUGH
-    bool "IOMMU passthrough by default"
+choice
+    prompt "IOMMU default DMA mode"
     depends on IOMMU_API
-        help
-      Enable passthrough by default, removing the need to pass in
-      iommu.passthrough=on or iommu=pt through command line. If this
-      is enabled, you can still disable with iommu.passthrough=off
-      or iommu=nopt depending on the architecture.
+    default IOMMU_DEFAULT_STRICT
+    help
+      This option allows IOMMU DMA mode to be chose at build time, to

As before:
/s/chose/chosen/, /s/allows IOMMU/allows an IOMMU/
I'm sorry that the previous version was not modified.


+      override the default DMA mode of each ARCHs, removing the need to

Again, as before:
ARCHs should be singular
OK


+      pass in kernel parameters through command line. You can still use
+      ARCHs specific boot options to override this option again.

*

+
+config IOMMU_DEFAULT_PASSTHROUGH
+    bool "passthrough"
+    help
+      In this mode, the DMA access through IOMMU without any addresses
+      translation. That means, the wrong or illegal DMA access can not
+      be caught, no error information will be reported.

       If unsure, say N here.

+config IOMMU_DEFAULT_LAZY
+    bool "lazy"
+    help
+      Support lazy mode, where for every IOMMU DMA unmap operation, the
+      flush operation of IOTLB and the free operation of IOVA are deferred.
+      They are only guaranteed to be done before the related IOVA will be
+      reused.

why no advisory on how to set if unsure?
Because the LAZY and STRICT have their own advantages and disadvantages.

Should I say: If unsure, keep the default。

Maybe. So you could put this in the help for the choice, * above, and remove the advisory on IOMMU_DEFAULT_PASSTHROUGH.

However the maintainer may have a different view.

Thanks,
John



+
+config IOMMU_DEFAULT_STRICT
+    bool "strict"
+    help
+      For every IOMMU DMA unmap operation, the flush operation of IOTLB and
+      the free operation of IOVA are guaranteed to be done in the unmap
+      function.
+
+      This mode is safer than the two above, but it maybe slower in some
+      high performace scenarios.

and here?

Reply via email to