On 24/04/2024 10:59 pm, Tomasz Jeznach wrote:
[...]
diff --git a/MAINTAINERS b/MAINTAINERS
index 2657f9eae84c..051599c76585 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18972,6 +18972,12 @@ L: iommu@xxxxxxxxxxxxxxx
L: linux-riscv@xxxxxxxxxxxxxxxxxxx
S: Maintained
F: Documentation/devicetree/bindings/iommu/riscv,iommu.yaml
+F: drivers/iommu/riscv/Kconfig
+F: drivers/iommu/riscv/Makefile
+F: drivers/iommu/riscv/iommu-bits.h
+F: drivers/iommu/riscv/iommu-platform.c
+F: drivers/iommu/riscv/iommu.c
+F: drivers/iommu/riscv/iommu.h
I'm pretty sure a single "F: drivers/iommu/riscv/" pattern will suffice.
Correct. But will required a workaround for pretty naive MAINTAINERS update
check in scripts/checkpatch.pl:3014 in next patch.
As long as what you're doing is clearly reasonable to humans, the
correct workaround for any checkpatch complaint is to ignore checkpatch.
[...]
+static int riscv_iommu_init_check(struct riscv_iommu_device *iommu)
+{
+ u64 ddtp;
+
+ /* Hardware must be configured in OFF | BARE mode at system initialization. */
+ riscv_iommu_readq_timeout(iommu, RISCV_IOMMU_REG_DDTP,
+ ddtp, !(ddtp & RISCV_IOMMU_DDTP_BUSY),
+ 10, RISCV_IOMMU_DDTP_TIMEOUT);
+ if (FIELD_GET(RISCV_IOMMU_DDTP_MODE, ddtp) > RISCV_IOMMU_DDTP_MODE_BARE)
+ return -EBUSY;
It looks like RISC-V already supports kdump, so you probably want to be
prepared to find the IOMMU with its pants down and deal with it from day
one.
This is the simplest check/fail for the kexec and/or boot loaders
leaving IOMMU translations active.
I've been already looking into kexec path to quiesce all devices and
IOMMU in shutdown path.
I'm not convinced it's ready for the prime time on RISC-V, will
address this in follow up patches.
Yeah, for regular kexec you definitely want an orderly shutdown of the
IOMMU, although there's still a bit of an open question about whether
it's better to actively block any remaining traffic from devices whose
drivers haven't cleanly stopped them. It's in the kdump crash kernel
case that you can't have any expectations and need to be able to recover
the IOMMU into a usable state, since it's likely to be in the way of
devices which the crash kernel wants to take over and use.
Thanks,
Robin.
