On Mon, Sep 30, 2013 at 06:17:16PM +0100, Andreas Herrmann wrote:

On Mon, Sep 30, 2013 at 12:06:15PM -0400, Will Deacon wrote:

quoted

On Mon, Sep 30, 2013 at 02:56:21PM +0100, Andreas Herrmann wrote:

quoted

After reset these registers have unknown values.
This might cause problems when evaluating SMMU_GFSR and/or SMMU_CB_FSR
in handlers for combined interrupts.

Signed-off-by: Andreas Herrmann <redacted>
---
 drivers/iommu/arm-smmu.c |   27 ++++++++++++++++++++-------
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 579b6f8..cbbf597 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c

@@ -631,6 +631,12 @@ static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
 	return IRQ_HANDLED;
 }
 
+static void arm_smmu_clear_cb_fsr(struct arm_smmu_device *smmu, u8 cbndx)
+{
+	void __iomem *cb_base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, cbndx);
+	writel_relaxed(FSR_FAULT, cb_base + ARM_SMMU_CB_FSR);
+}

Hmm, why not just stick this in arm_smmu_init_context_bank...

Because we should clear the FSR before we call request_irq.
Otherwise we might handle interrupts although the context bank is not
enabled.

Moving request_irq after arm_smmu_init_context_bank is not optimal
either. (We should have configured the context interrupt before
translation is enabled. Otherwise it's possible to miss a fault.)

How would you miss a fault? If the device can start issuing transactions
before the SMMU has set up the mapping, then there's a race in the caller
code which we shouldn't attempt to resolve here.

Will