From: mitchelh@codeaurora•org (Mitchel Humpherys)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH] iommu/arm-smmu: Only return IRQ_NONE if FSR is not set
Date: Tue, 06 Oct 2015 13:40:33 -0700 [thread overview]
Message-ID: <vnkwzizv688u.fsf@codeaurora.org> (raw)
In-Reply-To: <20151005142402.GF8818@arm.com> (Will Deacon's message of "Mon, 5 Oct 2015 15:24:03 +0100")
On Mon, Oct 05 2015 at 03:24:03 PM, Will Deacon <will.deacon@arm•com> wrote:
> Hi Mitch,
>
> On Sat, Sep 26, 2015 at 01:12:05AM +0100, Mitchel Humpherys wrote:
>> Currently we return IRQ_NONE from the context fault handler if the FSR
>> doesn't actually have the fault bit set (some sort of miswired
>> interrupt?) or if the client doesn't register an IOMMU fault handler.
>> However, registering a client fault handler is optional, so telling the
>> interrupt framework that the interrupt wasn't for this device if the
>> client doesn't register a handler isn't exactly accurate. Fix this by
>> returning IRQ_HANDLED even if the client doesn't register a handler.
>>
>> Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora•org>
>> ---
>> drivers/iommu/arm-smmu.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index 48a39dfa9777..95560d447a54 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -653,7 +653,7 @@ static irqreturn_t arm_smmu_context_fault(int irq, void *dev)
>> dev_err_ratelimited(smmu->dev,
>> "Unhandled context fault: iova=0x%08lx, fsynr=0x%x, cb=%d\n",
>> iova, fsynr, cfg->cbndx);
>> - ret = IRQ_NONE;
>> + ret = IRQ_HANDLED;
>> resume = RESUME_TERMINATE;
>
> Hmm, but if we haven't actually done anything to rectify the cause of the
> fault, what means that we won't take it again immediately? I guess I'm not
> understanding the use-case that triggered you to write this patch...
Does returning IRQ_NONE actually prevent us from taking another
interrupt (despite clearing the FSR below)? We definitely take more
interrupts on our platform despite returning IRQ_NONE, but maybe we have
something misconfigured...
I thought that returning IRQ_NONE would simply affect spurious interrupt
accounting (only disabling the interrupt if we took enough of them in
close enough succession to flag a misbehaving device).
As far as a valid use case, I can't think of one. I just thought we
were messing up the spurious interrupt accounting.
-Mitch
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2015-10-06 20:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-26 0:12 [PATCH] iommu/arm-smmu: Only return IRQ_NONE if FSR is not set Mitchel Humpherys
2015-10-05 14:24 ` Will Deacon
2015-10-06 20:40 ` Mitchel Humpherys [this message]
2015-10-07 9:27 ` Will Deacon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=vnkwzizv688u.fsf@codeaurora.org \
--to=mitchelh@codeaurora$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox