From: slash.tmp@free.fr (Mason)
To: linux-arm-kernel@lists.infradead.org
Subject: Disabling an interrupt in the handler locks the system up
Date: Tue, 25 Oct 2016 10:36:34 +0200 [thread overview]
Message-ID: <580F1992.2070602@free.fr> (raw)
In-Reply-To: <580F17E7.5060603@laposte.net>
On 25/10/2016 10:29, Sebastian Frias wrote:
> On 10/24/2016 06:55 PM, Thomas Gleixner wrote:
>
>> On Mon, 24 Oct 2016, Mason wrote:
>>
>>> For the record, setting the IRQ_DISABLE_UNLAZY flag for this device
>>> makes the system lock-up disappear.
>>
>> The way how lazy irq disabling works is:
>>
>> 1) Interrupt is marked disabled in software, but the hardware is not masked
>>
>> 2) If the interrupt fires befor the interrupt is reenabled, then it's
>> masked at the hardware level in the low level interrupt flow handler.
>
> Would you mind explaining what is the intention behind?
> Because it does not seem obvious why there isn't a direct map between
> "disable_irq*()" and "mask_irq()"
I had a similar, but slightly different question:
What is the difference between struct irq_chip's
* @irq_shutdown: shut down the interrupt (defaults to ->disable if NULL)
* @irq_disable: disable the interrupt
* @irq_mask: mask an interrupt source
(enable seems to default to unmask, but disable does not default to mask)
Regards.
WARNING: multiple messages have this Message-ID (diff)
From: Mason <slash.tmp@free.fr>
To: Sebastian Frias <sf84@laposte.net>, Thomas Gleixner <tglx@linutronix.de>
Cc: Marc Zyngier <marc.zyngier@arm.com>,
Jason Cooper <jason@lakedaemon.net>,
LKML <linux-kernel@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: Disabling an interrupt in the handler locks the system up
Date: Tue, 25 Oct 2016 10:36:34 +0200 [thread overview]
Message-ID: <580F1992.2070602@free.fr> (raw)
In-Reply-To: <580F17E7.5060603@laposte.net>
On 25/10/2016 10:29, Sebastian Frias wrote:
> On 10/24/2016 06:55 PM, Thomas Gleixner wrote:
>
>> On Mon, 24 Oct 2016, Mason wrote:
>>
>>> For the record, setting the IRQ_DISABLE_UNLAZY flag for this device
>>> makes the system lock-up disappear.
>>
>> The way how lazy irq disabling works is:
>>
>> 1) Interrupt is marked disabled in software, but the hardware is not masked
>>
>> 2) If the interrupt fires befor the interrupt is reenabled, then it's
>> masked at the hardware level in the low level interrupt flow handler.
>
> Would you mind explaining what is the intention behind?
> Because it does not seem obvious why there isn't a direct map between
> "disable_irq*()" and "mask_irq()"
I had a similar, but slightly different question:
What is the difference between struct irq_chip's
* @irq_shutdown: shut down the interrupt (defaults to ->disable if NULL)
* @irq_disable: disable the interrupt
* @irq_mask: mask an interrupt source
(enable seems to default to unmask, but disable does not default to mask)
Regards.
next prev parent reply other threads:[~2016-10-25 8:36 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-21 16:37 Disabling an interrupt in the handler locks the system up Mason
2016-10-21 16:37 ` Mason
2016-10-21 17:46 ` Marc Zyngier
2016-10-21 17:46 ` Marc Zyngier
2016-10-21 18:39 ` Mason
2016-10-21 18:39 ` Mason
2016-10-21 19:14 ` Marc Zyngier
2016-10-21 19:14 ` Marc Zyngier
2016-10-21 19:47 ` Mason
2016-10-21 19:47 ` Mason
2016-10-21 19:49 ` Thomas Gleixner
2016-10-21 19:49 ` Thomas Gleixner
2016-10-21 20:27 ` Mason
2016-10-21 20:27 ` Mason
2016-10-22 11:37 ` Marc Zyngier
2016-10-22 11:37 ` Marc Zyngier
2016-10-22 23:10 ` Mason
2016-10-22 23:10 ` Mason
2016-10-24 8:17 ` Marc Zyngier
2016-10-24 8:17 ` Marc Zyngier
2016-10-24 16:12 ` Mason
2016-10-24 16:12 ` Mason
2016-10-24 16:55 ` Thomas Gleixner
2016-10-24 16:55 ` Thomas Gleixner
2016-10-25 8:29 ` Sebastian Frias
2016-10-25 8:29 ` Sebastian Frias
2016-10-25 8:36 ` Mason [this message]
2016-10-25 8:36 ` Mason
2016-10-25 10:45 ` Marc Zyngier
2016-10-25 10:45 ` Marc Zyngier
2016-10-25 13:56 ` Mason
2016-10-25 13:56 ` Mason
2016-10-25 13:56 ` Thomas Gleixner
2016-10-25 13:56 ` Thomas Gleixner
2016-10-25 9:20 ` Thomas Gleixner
2016-10-25 9:20 ` Thomas Gleixner
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=580F1992.2070602@free.fr \
--to=slash.tmp@free.fr \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.