Thread (25 messages) flat view 25 messages, 4 authors, 2021-03-03

Re: [RFC 09/13] iommu/arm-smmu: Make use of dev_64bit_mmio_supported()

From: Robin Murphy <robin.murphy@arm.com>
Date: 2021-03-02 11:22:41
Also in: linux-devicetree, lkml

On 2021-02-26 14:03, Nicolas Saenz Julienne wrote:
quoted hunk ↗ jump to hunk
Some arm SMMU implementations might sit on a bus that doesn't support
64bit memory accesses. In that case default to using hi_lo_{readq,
writeq}() and BUG if such platform tries to use AArch64 formats as they
rely on writeq()'s atomicity.

Signed-off-by: Nicolas Saenz Julienne <redacted>
---
  drivers/iommu/arm/arm-smmu/arm-smmu.c | 9 +++++++++
  drivers/iommu/arm/arm-smmu/arm-smmu.h | 9 +++++++--
  2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index d8c6bfde6a61..239ff42b20c3 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -1889,6 +1889,15 @@ static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
  			smmu->features |= ARM_SMMU_FEAT_FMT_AARCH64_64K;
  	}
  
+	/*
+	 * 64bit accesses not possible through the interconnect, AArch64
+	 * formats depend on it.
+	 */
+	BUG_ON(!dev_64bit_mmio_supported(smmu->dev) &&
+	       smmu->features & (ARM_SMMU_FEAT_FMT_AARCH64_4K |
+				ARM_SMMU_FEAT_FMT_AARCH64_16K |
+				ARM_SMMU_FEAT_FMT_AARCH64_64K));
No. Crashing the kernel in a probe routine which is free to fail is 
unacceptable either way, but guaranteeing failure in the case that the 
workaround *would* be required is doubly so.

Basically, this logic is backwards - if you really wanted to handle it 
generically, this would be the point at which you'd need to actively 
suppress all the detected hardware features which depend on 64-bit 
atomicity, not complain about them.
quoted hunk ↗ jump to hunk
+
  	if (smmu->impl && smmu->impl->cfg_probe) {
  		ret = smmu->impl->cfg_probe(smmu);
  		if (ret)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h b/drivers/iommu/arm/arm-smmu/arm-smmu.h
index d2a2d1bc58ba..997d13a21717 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
@@ -477,15 +477,20 @@ static inline void arm_smmu_writel(struct arm_smmu_device *smmu, int page,
  {
  	if (smmu->impl && unlikely(smmu->impl->write_reg))
  		smmu->impl->write_reg(smmu, page, offset, val);
-	else
+	else if (dev_64bit_mmio_supported(smmu->dev))
  		writel_relaxed(val, arm_smmu_page(smmu, page) + offset);
+	else
+		hi_lo_writeq_relaxed(val, arm_smmu_page(smmu, page) + offset);
As Arnd pointed out, this is in completely the wrong place. Also, in 
general it doesn't work if the implementation already needs a hook to 
filter or override register accesses for any other reason. TBH I'm not 
convinced that this isn't *more* of a mess than handling it on a 
SoC-specific basis...

Robin.
  }
  
  static inline u64 arm_smmu_readq(struct arm_smmu_device *smmu, int page, int offset)
  {
  	if (smmu->impl && unlikely(smmu->impl->read_reg64))
  		return smmu->impl->read_reg64(smmu, page, offset);
-	return readq_relaxed(arm_smmu_page(smmu, page) + offset);
+	else if (dev_64bit_mmio_supported(smmu->dev))
+		return readq_relaxed(arm_smmu_page(smmu, page) + offset);
+	else
+		return hi_lo_readq_relaxed(arm_smmu_page(smmu, page) + offset);
  }
  
  static inline void arm_smmu_writeq(struct arm_smmu_device *smmu, int page,
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help