From: "Pali Rohár" <pali@kernel.org>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@bootlin.com>,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
Marc Zyngier <maz@kernel.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] irqchip/armada-370-xp: Do not allow mapping IRQ 0 and 1
Date: Sun, 1 May 2022 14:02:33 +0200 [thread overview]
Message-ID: <20220501120233.xfzh62tbuuvatx3v@pali> (raw)
In-Reply-To: <YmvafYwhtIoaOMmk@lunn.ch>
On Friday 29 April 2022 14:30:53 Andrew Lunn wrote:
> On Mon, Apr 25, 2022 at 01:37:06PM +0200, Pali Rohár wrote:
> > IRQs 0 and 1 cannot be mapped, they are handled internally by this driver
> > and this driver does not call generic_handle_domain_irq() for these IRQs.
> > So do not allow mapping these IRQs and correctly propagate error from the
> > .irq_map callback.
>
> So you are referring to this?
>
> /* Check if the interrupt is not masked on current CPU.
> * Test IRQ (0-1) and FIQ (8-9) mask bits.
> */
> if (!(irqsrc & ARMADA_370_XP_INT_IRQ_FIQ_MASK(cpuid)))
> continue;
>
> if (irqn == 1) {
> armada_370_xp_handle_msi_irq(NULL, true);
> continue;
> }
I'm referring to irqn, which is not handled on armada_370_xp_mpic_domain
via generic_handle_domain_irq() when it is == 1.
Also I'm referring to another section:
if (irqnr > 1) {
generic_handle_domain_irq(armada_370_xp_mpic_domain,
irqnr);
continue;
}
/* MSI handling */
if (irqnr == 1)
armada_370_xp_handle_msi_irq(regs, false);
#ifdef CONFIG_SMP
/* IPI Handling */
if (irqnr == 0) {
unsigned long ipimask;
int ipi;
ipimask = readl_relaxed(per_cpu_int_base +
ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS)
& IPI_DOORBELL_MASK;
for_each_set_bit(ipi, &ipimask, IPI_DOORBELL_END)
generic_handle_domain_irq(ipi_domain, ipi);
}
#endif
First 'if (irqnr > 1)' just cause that irqnr 0 and 1 are not handled on
armada_370_xp_mpic_domain via generic_handle_domain_irq().
>
> Should the two FIQ interrupts also return -EINVAL?
>
> Andrew
No. Following code
irqsrc = readl_relaxed(main_int_base +
ARMADA_370_XP_INT_SOURCE_CTL(irqn));
/* Check if the interrupt is not masked on current CPU.
* Test IRQ (0-1) and FIQ (8-9) mask bits.
*/
if (!(irqsrc & ARMADA_370_XP_INT_IRQ_FIQ_MASK(cpuid)))
continue;
skips processing irqn interrupt if it is masked for the current CPU.
Interrupt irqn is **unmasked** on CPU0 if either bit 0 or 8 is set in
register ARMADA_370_XP_INT_IRQ_FIQ_MASK. And **unmasked** on CPU1 if
either bit 1 or 9 is set.
The reason for this check and skipping is because some per-cpu
interrupts on A375, A38x and A39x can be handled directly via GIC and
also via MPIC subhierarchy (it depends what you put into DTS, both
options are possible and working, just some interrupts are MPIC-only).
So if you unmask some interrupt on GIC and interrupt is triggered then
also MPIC per-CPU cause register contains in bit for that triggered
interrupt (even you have not asked MPIC to unmask interrupt). And once
another MPIC interrupt is triggered then routine for handling MPIC
subhierarchy see that some cause bits are set and tried to call
generic_handle_domain_irq() for all of them, also for those which are
masked. That is why it is needed to check if MPIC interrupt is masked on
the current CPU or not prior processing it.
So those bits 0-1 and 8-9 have nothing with mapping interrupts.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-05-01 12:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-25 11:37 [PATCH 1/2] irqchip/armada-370-xp: Do not touch Performance Counter Overflow on A375, A38x, A39x Pali Rohár
2022-04-25 11:37 ` [PATCH 2/2] irqchip/armada-370-xp: Do not allow mapping IRQ 0 and 1 Pali Rohár
2022-04-29 12:30 ` Andrew Lunn
2022-05-01 12:02 ` Pali Rohár [this message]
2022-05-06 11:22 ` Marc Zyngier
2022-04-29 12:23 ` [PATCH 1/2] irqchip/armada-370-xp: Do not touch Performance Counter Overflow on A375, A38x, A39x Andrew Lunn
2022-04-29 13:05 ` Pali Rohár
2022-04-29 22:23 ` Andrew Lunn
2022-04-29 22:31 ` Pali Rohár
2022-04-29 22:39 ` Andrew Lunn
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=20220501120233.xfzh62tbuuvatx3v@pali \
--to=pali@kernel.org \
--cc=andrew@lunn.ch \
--cc=gregory.clement@bootlin.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=sebastian.hesselbarth@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox