archive mirror
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <>
To: Robin Murphy <>
Cc: Bing Fan <>,,,
Subject: Re: [PATCH v6] arm pl011 serial: support multi-irq request
Date: Mon, 16 Aug 2021 11:34:48 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, Aug 13, 2021 at 03:37:16PM +0100, Robin Murphy wrote:
> > +static int pl011_allocate_multi_irqs(struct uart_amba_port *uap)
> > +{
> > +	int ret = 0;
> > +	int i;
> > +	unsigned int virq;
> > +	struct amba_device *amba_dev = container_of(uap->, struct amba_device, dev);
> > +
> > +	pl011_write(uap->im, uap, REG_IMSC);
> > +
> > +	for (i = 0; i < AMBA_NR_IRQS; i++) {
> It's not clear where these extra IRQs are expected to come from given that
> the DT binding explicitly defines only one :/

The DT binding (and driver) was written assuming that people wouldn't
use the individual interrupts - but I guess someone decided it was a
good idea to have a bazillion interrupt signals going to your interrupt
controller from something as simple as a UART (which is permitted by
the PL011 TRM.) It's only taken about 20 years for this to happen, so
I think we should think we're lucky this hasn't come up before! :D

> > +		virq = amba_dev->irq[i];
> > +		if (virq == 0)
> > +			break;
> > +
> > +		ret = request_irq(virq, pl011_int, IRQF_SHARED, dev_name(&amba_dev->dev), uap);
> Note that using dev_name() here technically breaks user ABI - scripts
> looking in /proc for an irq named "uart-pl011" will no longer find it.
> Furthermore, the "dev" cookie passed to request_irq is supposed to be
> globally unique, which "uap" isn't once you start registering it multiple
> times.

There's no difference there.

First, the "private" used with request_irq() only has to be globally
unique for the interrupt number being requested. Secondly, there is
no way for two UARTs to share the same "uap" structure, and finally
there is a 1:1 model between "uap" and "dev". So, I don't see a problem
as far as whether we use "uap" or "dev" here.

> If firmware did describe all the individual PL011 IRQ outputs on a
> system where they are muxed to the same physical IRQ anyway, you'd end up
> registering ambiguous IRQ actions here. Of course in practice you might
> still get away with that, but it is technically wrong.

Yes. This would also make a total nonsense of using multiple interrupt

The whole point of using multiple interrupt lines from the UART is so
the interrupt demultiplexing can be handled at the interrupt controller
and their priorities can be decided there. If we adopt a software
structure where we effectively register our "merged" interrupt handler
for all these signals, then there is absolutely no benefit to using
multiple interrupt signals, since that will override any priority, and
we will still have the extra overhead of decoding which interrupt fired
at the UART level.

RMK's Patch system:
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

      parent reply	other threads:[~2021-08-16 10:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-13  3:31 [PATCH v6] arm pl011 serial: support multi-irq request Bing Fan
2021-08-13  7:19 ` Greg KH
     [not found]   ` <>
2021-08-13  8:17     ` Greg KH
2021-08-13 14:08       ` Robin Murphy
2021-08-13 15:04         ` Greg KH
2021-08-13 15:17           ` Robin Murphy
2021-08-13 14:37 ` Robin Murphy
     [not found]   ` <>
2021-08-16 10:19     ` Robin Murphy
2021-08-16 10:34   ` Russell King (Oracle) [this message]

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).