All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <marc.zyngier@arm.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Bjorn Helgaas <bhelgaas@google.com>, <linux-pci@vger.kernel.org>,
	Christoph Hellwig <hch@lst.de>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] PCI: let pci_request_irq properly deal with threaded interrupts
Date: Tue, 31 Jul 2018 07:15:22 +0100	[thread overview]
Message-ID: <86d0v4x75x.wl-marc.zyngier@arm.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1807310015170.1725@nanos.tec.linutronix.de>

On Mon, 30 Jul 2018 23:36:57 +0100,
Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> On Mon, 30 Jul 2018, Bjorn Helgaas wrote:
> 
> > [+cc Thomas, Christoph, LKML]
> 
> + Marc
> 
> > On Mon, Jul 30, 2018 at 12:03:42AM +0200, Heiner Kallweit wrote:
> > > If we have a threaded interrupt with the handler being NULL, then
> > > request_threaded_irq() -> __setup_irq() will complain and bail out
> > > if the IRQF_ONESHOT flag isn't set. Therefore check for the handler
> > > being NULL and set IRQF_ONESHOT in this case.
> > > 
> > > This change is needed to migrate the mei_me driver to
> > > pci_alloc_irq_vectors() and pci_request_irq().
> > > 
> > > Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> > 
> > I'd like an ack from Thomas because this requirement about IRQF_ONESHOT
> > usage isn't mentioned in the request_threaded_irq() function doc or
> > Documentation/
> 
> Right. The documentation really needs some love and care. :(
> 
> Yes, request for pure threaded interrupts are rejected if the oneshot flag
> is not set. The reason is that this would be deadly especially with level
> triggered interrupts because the primary default handler just wakes the
> thread and then reenables interrupts, which will make the interrupt come
> back immediately and the thread won't have a chance to actually shut it up
> in the device.
> 
> That made me look into that code again and I found that we added a flag for
> irq chips to tell the core that the interrupt is one shot safe, i.e. that
> it can be requested w/o IRQF_ONESHOT. That was initially added to optimize
> MSI based interrupts which are oneshot safe by implementation.
> 
>   dc9b229a58dc ("genirq: Allow irq chips to mark themself oneshot safe")
> 
> The original patch added that flag to the x86 MSI irqchip code, but that
> part was not applied for reasons which slipped from memory. It might be
> worthwhile to revisit that in order to avoid the mask/unmask overhead for
> such cases.

Yup, that would actually be beneficial to a range of interrupt
controllers (only an obscure GPIO driver makes use of this flag).

We could also consider extending this to support interrupt
hierarchies, as __setup_irq() seems only concerned with the top of the
stack (an IRQ provided by a generic MSI stack and backed by an irqchip
providing IRQCHIP_ONESHOT_SAFE would go unnoticed).

	M.

-- 
Jazz is not dead, it just smell funny.

  reply	other threads:[~2018-07-31  6:15 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-29 22:03 [PATCH] PCI: let pci_request_irq properly deal with threaded interrupts Heiner Kallweit
2018-07-30 21:30 ` Bjorn Helgaas
2018-07-30 21:50   ` Heiner Kallweit
2018-07-30 21:54   ` Andy Shevchenko
2018-07-30 22:36   ` Thomas Gleixner
2018-07-31  6:15     ` Marc Zyngier [this message]
2018-08-01 19:51       ` Heiner Kallweit
2018-08-03 14:09         ` Thomas Gleixner
2018-08-03 19:25           ` Heiner Kallweit
2018-08-03 19:40             ` Thomas Gleixner
2018-08-03 20:55               ` Heiner Kallweit
2018-07-30 22:42   ` Bjorn Helgaas
2018-07-30 22:50     ` Thomas Gleixner
2018-07-31  7:29       ` Lee Jones
2018-07-31  8:01       ` Russell King - ARM Linux
2018-07-31 11:13         ` Bjorn Helgaas
2018-07-31  8:08     ` Krzysztof Kozlowski
2018-07-30 23:05 ` Bjorn Helgaas

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=86d0v4x75x.wl-marc.zyngier@arm.com \
    --to=marc.zyngier@arm.com \
    --cc=bhelgaas@google.com \
    --cc=hch@lst.de \
    --cc=helgaas@kernel.org \
    --cc=hkallweit1@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /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.