public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox