Thread (59 messages) 59 messages, 8 authors, 2021-11-30

Re: [patch 33/37] iommu/arm-smmu-v3: Use msi_get_virq()

From: Robin Murphy <robin.murphy@arm.com>
Date: 2021-11-29 13:15:24
Also in: linux-arm-kernel, linux-iommu, linux-pci, lkml

On 2021-11-29 10:55, Will Deacon wrote:
Hi Thomas,

On Sat, Nov 27, 2021 at 02:20:59AM +0100, Thomas Gleixner wrote:
quoted
Let the core code fiddle with the MSI descriptor retrieval.

Signed-off-by: Thomas Gleixner <redacted>
---
  drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c |   19 +++----------------
  1 file changed, 3 insertions(+), 16 deletions(-)
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -3154,7 +3154,6 @@ static void arm_smmu_write_msi_msg(struc
  
  static void arm_smmu_setup_msis(struct arm_smmu_device *smmu)
  {
-	struct msi_desc *desc;
  	int ret, nvec = ARM_SMMU_MAX_MSIS;
  	struct device *dev = smmu->dev;
  
@@ -3182,21 +3181,9 @@ static void arm_smmu_setup_msis(struct a
  		return;
  	}
  
-	for_each_msi_entry(desc, dev) {
-		switch (desc->msi_index) {
-		case EVTQ_MSI_INDEX:
-			smmu->evtq.q.irq = desc->irq;
-			break;
-		case GERROR_MSI_INDEX:
-			smmu->gerr_irq = desc->irq;
-			break;
-		case PRIQ_MSI_INDEX:
-			smmu->priq.q.irq = desc->irq;
-			break;
-		default:	/* Unknown */
-			continue;
-		}
-	}
+	smmu->evtq.q.irq = msi_get_virq(dev, EVTQ_MSI_INDEX);
+	smmu->gerr_irq = msi_get_virq(dev, GERROR_MSI_INDEX);
+	smmu->priq.q.irq = msi_get_virq(dev, PRIQ_MSI_INDEX);
Prviously, if retrieval of the MSI failed then we'd fall back to wired
interrupts. Now, I think we'll clobber the interrupt with 0 instead. Can
we make the assignments to smmu->*irq here conditional on the MSI being
valid, please?
I was just looking at that too, but reached the conclusion that it's 
probably OK, since consumption of this value later is gated on 
ARM_SMMU_FEAT_PRI, so the fact that it changes from 0 to an error value 
in the absence of PRI should make no practical difference. If we don't 
have MSIs at all, we'd presumably still fail earlier either at the 
dev->msi_domain check or upon trying to allocate the vectors, so we'll 
still fall back to any previously-set wired values before getting here. 
The only remaining case is if we've *successfully* allocated the 
expected number of vectors yet are then somehow unable to retrieve one 
or more of them - presumably the system has to be massively borked for 
that to happen, at which point do we really want to bother trying to 
reason about anything?

Robin.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help