From: Marc Zyngier <maz@kernel.org>
To: Sander Vanheule <sander@svanheule.net>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Rob Herring <robh+dt@kernel.org>,
devicetree@vger.kernel.org,
Birger Koblitz <mail@birger-koblitz.de>,
Bert Vermeulen <bert@biot.com>, John Crispin <john@phrozen.org>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 2/5] irqchip/realtek-rtl: fix off-by-one in routing
Date: Mon, 27 Dec 2021 10:16:01 +0000 [thread overview]
Message-ID: <87tueuz732.wl-maz@kernel.org> (raw)
In-Reply-To: <2235a7748b8f7689a96b1e0f91461e36a946a4ef.1640548009.git.sander@svanheule.net>
On Sun, 26 Dec 2021 19:59:25 +0000,
Sander Vanheule <sander@svanheule.net> wrote:
>
> There is an offset between routing values (1..6) and the connected MIPS
> CPU interrupts (2..7), but no distinction was made between these two
> values.
>
> This issue was previously hidden during testing, because an interrupt
> mapping was used where for each required interrupt another (unused)
> routing was configured, with an offset of +1.
Where does this 'other routing' come from?
>
> Offset the CPU IRQ numbers by -1 to retrieve the correct routing value.
>
> Fixes: 9f3a0f34b84a ("irqchip: Add support for Realtek RTL838x/RTL839x interrupt controller")
> Signed-off-by: Sander Vanheule <sander@svanheule.net>
> ---
> drivers/irqchip/irq-realtek-rtl.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/irqchip/irq-realtek-rtl.c b/drivers/irqchip/irq-realtek-rtl.c
> index d6788dd93c7b..568614edd88f 100644
> --- a/drivers/irqchip/irq-realtek-rtl.c
> +++ b/drivers/irqchip/irq-realtek-rtl.c
> @@ -95,7 +95,8 @@ static void realtek_irq_dispatch(struct irq_desc *desc)
> * SoC interrupts are cascaded to MIPS CPU interrupts according to the
> * interrupt-map in the device tree. Each SoC interrupt gets 4 bits for
> * the CPU interrupt in an Interrupt Routing Register. Max 32 SoC interrupts
> - * thus go into 4 IRRs.
> + * thus go into 4 IRRs. A routing value of '0' means the interrupt is left
> + * disconnected. Routing values {1..15} connect to output lines {0..14}.
> */
> static int __init map_interrupts(struct device_node *node, struct irq_domain *domain)
> {
> @@ -134,7 +135,7 @@ static int __init map_interrupts(struct device_node *node, struct irq_domain *do
> of_node_put(cpu_ictl);
>
> cpu_int = be32_to_cpup(imap + 2);
> - if (cpu_int > 7)
> + if (cpu_int > 7 || cpu_int < 2)
How many output lines do you have? The comment above says something
about having 15 output lines, but you limit it to 7...
> return -EINVAL;
>
> if (!(mips_irqs_set & BIT(cpu_int))) {
> @@ -143,7 +144,8 @@ static int __init map_interrupts(struct device_node *node, struct irq_domain *do
> mips_irqs_set |= BIT(cpu_int);
> }
>
> - regs[(soc_int * 4) / 32] |= cpu_int << (soc_int * 4) % 32;
> + /* Use routing values (1..6) for CPU interrupts (2..7) */
> + regs[(soc_int * 4) / 32] |= (cpu_int - 1) << (soc_int * 4) % 32;
> imap += 3;
> }
>
What I don't understand is how this worked so far if all mappings were
off my one. Or the mapping really doesn't matter, because this is all
under SW control?
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2021-12-27 10:16 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-26 19:59 [RFC PATCH v2 0/5] Rework realtek-rtl IRQ driver Sander Vanheule
2021-12-26 19:59 ` [RFC PATCH v2 1/5] irqchip/realtek-rtl: map control data to virq Sander Vanheule
2021-12-26 19:59 ` [RFC PATCH v2 2/5] irqchip/realtek-rtl: fix off-by-one in routing Sander Vanheule
2021-12-27 10:16 ` Marc Zyngier [this message]
2021-12-28 10:13 ` Sander Vanheule
2021-12-28 10:59 ` Marc Zyngier
2021-12-28 16:21 ` Sander Vanheule
2021-12-26 19:59 ` [RFC PATCH v2 3/5] irqchip/realtek-rtl: use per-parent irq handling Sander Vanheule
2021-12-27 10:38 ` Marc Zyngier
2021-12-26 19:59 ` [RFC PATCH v2 4/5] dt-bindings: interrupt-controller: realtek,rtl-intc: map output lines Sander Vanheule
2021-12-27 11:17 ` Marc Zyngier
2021-12-28 16:21 ` Sander Vanheule
2021-12-28 16:53 ` Birger Koblitz
2021-12-29 19:32 ` Sander Vanheule
2021-12-26 19:59 ` [RFC PATCH v2 5/5] irqchip/realtek-rtl: add explicit output routing Sander Vanheule
2021-12-27 9:06 ` [RFC PATCH v2 0/5] Rework realtek-rtl IRQ driver Birger Koblitz
2021-12-27 10:39 ` Sander Vanheule
2021-12-28 8:09 ` Birger Koblitz
2021-12-29 20:03 ` Sander Vanheule
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=87tueuz732.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=bert@biot.com \
--cc=devicetree@vger.kernel.org \
--cc=john@phrozen.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mail@birger-koblitz.de \
--cc=robh+dt@kernel.org \
--cc=sander@svanheule.net \
--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.