From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8113019539F for ; Sun, 22 Feb 2026 22:32:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771799544; cv=none; b=rkVdOMgFMH+pQyvM8e6BmdbZxt17edBqmRnCzLVxoHKN5k//a/Dp5vK3Af9EiqP+WE9HR+Vclt4YacPQXRclso7J6qL2g6Fa4vhLzS/BVV983gfJjDLuGOh7YD8gzIxuybQ4oPIi0BdXekF9iiVvzgiskgsndt7nv24Qgihw14c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771799544; c=relaxed/simple; bh=vbrJZia3+vAjtx/x5+OdH43kR1bxnljbxU4mEGtmu2M=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=MEntPetCrCvMbKUErXeK+TG2Qsc2a1xPTtFmhDDJuXxYN+lGaXOPb7MuwFuXrbEUDli7InYIFWie8Si+O/0D+XKUELik/JhU8wKDMq9o1eXKaeBC/Ty+TNXUMF5C0Y5gzsSGN98TiqhEOtl8E9L4HwDikfsDuQ8BvmDkyEGrHLo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MpJJ8Eu1; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MpJJ8Eu1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 41222C116D0; Sun, 22 Feb 2026 22:32:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771799544; bh=vbrJZia3+vAjtx/x5+OdH43kR1bxnljbxU4mEGtmu2M=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=MpJJ8Eu1XbuuBm6dcL9yqIrS5rKK41YA8vCsM0n81TJQ7Gjp7GvtrwffgImmqWDxl 0xDtPhWSP9HAkzEd92qlBfxjn386l1tO7kuSyklLjqNmieBx6pHpb0c4aXZtoZ7YA4 GlqrERkq96Alb3Nk3+otJqYqvsAn7Segmj12bKj1/nmqYhgkDTwqfpIXqiUUWO8nt5 mtFdvcGZj+OqSmEr7n8p4prpjsM0Duz25MHe1ypbMRaASZiIyFBQZT8qUS6rpCQpcT Hs0FgKfaRPlRx5kzr8CNFWXMTsZLUgSkbXOHGRljFtcEIyTJ7s2rdcsv57eR9yHad4 dWf1S5MGmlB/g== From: Thomas Gleixner To: Meghana Malladi , 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 , Roger Quadros , danishanwar@ti.com, m-malladi@ti.com, Suman Anna , Grygorii Strashko Subject: Re: [PATCH v2 1/3] irqchip/irq-pruss-intc: Fix enabling of intc events In-Reply-To: <20260218093730.3123342-2-m-malladi@ti.com> References: <20260218093730.3123342-1-m-malladi@ti.com> <20260218093730.3123342-2-m-malladi@ti.com> Date: Sun, 22 Feb 2026 23:32:20 +0100 Message-ID: <874in8wgsr.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Wed, Feb 18 2026 at 15:07, Meghana Malladi wrote: > From: Suman Anna > > 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 > Signed-off-by: Suman Anna > 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 > Signed-off-by: Vignesh Raghavendra > Signed-off-by: Meghana Malladi 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