From: Thomas Gleixner <tglx@kernel.org>
To: Meghana Malladi <m-malladi@ti.com>,
grzegorz.jaszczyk@linaro.org, maz@kernel.org, rogerq@ti.com,
david@lechnology.com, afd@ti.com
Cc: linux-kernel@vger.kernel.org, srk@ti.com,
Vignesh Raghavendra <vigneshr@ti.com>,
Roger Quadros <rogerq@kernel.org>,
danishanwar@ti.com, m-malladi@ti.com, Suman Anna <s-anna@ti.com>,
Grygorii Strashko <grygorii.strashko@ti.com>
Subject: Re: [PATCH v2 1/3] irqchip/irq-pruss-intc: Fix enabling of intc events
Date: Sun, 22 Feb 2026 23:32:20 +0100 [thread overview]
Message-ID: <874in8wgsr.ffs@tglx> (raw)
In-Reply-To: <20260218093730.3123342-2-m-malladi@ti.com>
On Wed, Feb 18 2026 at 15:07, Meghana Malladi wrote:
> From: Suman Anna <s-anna@ti.com>
>
> PRUSS INTC events are enabled by default once IRQ events are mapped to
Please s/IRQ/interrupt/
Change logs are prosa and not twatter messages.
> channel:host pair. This may cause issues with undesirable IRQs triggering
> even before a PRU IRQ is requested which are silently processed by
> pruss_intc_irq_handler().
This sentence does not make any sense.
> Fix it by masking all events by default except those which are routed to
> various PRU cores (Host IRQs 0, 1; 10 through 19 on K3 SoCs), and any
> other reserved IRQs routed to other processors. The unmasking of IRQs is
> the responsibility of Linux IRQ core when IRQ is actually requested.
>
> Fixes: 04e2d1e06978 ("irqchip/irq-pruss-intc: Add a PRUSS irqchip driver for PRUSS interrupts")
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> Link: https://lore.kernel.org/all/20230919061900.369300-2-danishanwar@ti.com/
What's this link for? Put a link into the cover letter which points to
the V1 submission.
> Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
> Signed-off-by: Meghana Malladi <m-malladi@ti.com>
This S-O-B chain is completely broken. Please read:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
and the subsequent chapters.
> struct pruss_intc {
> struct pruss_intc_map_record event_channel[MAX_PRU_SYS_EVENTS];
> @@ -111,6 +112,7 @@ struct pruss_intc {
> const struct pruss_intc_match_data *soc_config;
> struct device *dev;
> struct mutex lock; /* PRUSS INTC lock */
> + u8 irqs_reserved;
In the changelog you explain that host interrupt 0,1 and on K3 SoCs
interrupts 10-19 are reserved and treated differently. How do they fit
into an u8? I'm probably failing to understand the word salad in the
change log, but that doesn't make any better.
> @@ -187,6 +190,9 @@ static void pruss_intc_map(struct pruss_intc *intc, unsigned long hwirq)
>
> ch = intc->event_channel[hwirq].value;
> host = intc->channel_host[ch].value;
> + enable_hwirq = (host < FIRST_PRU_HOST_INT ||
> + host >= FIRST_PRU_HOST_INT + MAX_NUM_HOST_IRQS ||
> + intc->irqs_reserved & BIT(host - FIRST_PRU_HOST_INT));
Seriously? This is incomprehensible. What's wrong with doing the
obvious:
struct pruss_intc {
...
u32 irqs_reserved;
};
Fill that in the probe function with all bits which are reserved and do
enable = !!(intc->irqs_reserved & BIT(host_irq));
That'd be not convoluted enough, right?
> pruss_intc_update_cmr(intc, hwirq, ch);
>
> @@ -194,8 +200,10 @@ static void pruss_intc_map(struct pruss_intc *intc, unsigned long hwirq)
> val = BIT(hwirq % 32);
>
> /* clear and enable system event */
> - pruss_intc_write_reg(intc, PRU_INTC_ESR(reg_idx), val);
> pruss_intc_write_reg(intc, PRU_INTC_SECR(reg_idx), val);
> + /* unmask only events going to various PRU and other cores by default */
Sentences start with an upper case letter.
> + if (enable_hwirq)
> + pruss_intc_write_reg(intc, PRU_INTC_ESR(reg_idx), val);
Thanks,
tglx
next prev parent reply other threads:[~2026-02-22 22:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-18 9:37 [PATCH v2 0/3] Bug Fixes for PRUSS irqchip driver Meghana Malladi
2026-02-18 9:37 ` [PATCH v2 1/3] irqchip/irq-pruss-intc: Fix enabling of intc events Meghana Malladi
2026-02-22 22:32 ` Thomas Gleixner [this message]
2026-02-18 9:37 ` [PATCH v2 2/3] irqchip/irq-pruss-intc: Fix listed IRQ type in /proc/interrupts Meghana Malladi
2026-02-22 22:39 ` Thomas Gleixner
2026-02-22 22:46 ` Thomas Gleixner
2026-02-18 9:37 ` [PATCH v2 3/3] irqchip/irq-pruss-intc: Fix processing of IEP interrupts Meghana Malladi
2026-02-22 22:55 ` 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=874in8wgsr.ffs@tglx \
--to=tglx@kernel.org \
--cc=afd@ti.com \
--cc=danishanwar@ti.com \
--cc=david@lechnology.com \
--cc=grygorii.strashko@ti.com \
--cc=grzegorz.jaszczyk@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m-malladi@ti.com \
--cc=maz@kernel.org \
--cc=rogerq@kernel.org \
--cc=rogerq@ti.com \
--cc=s-anna@ti.com \
--cc=srk@ti.com \
--cc=vigneshr@ti.com \
/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.