[PATCH v2 0/3] Bug Fixes for PRUSS irqchip driver

[PATCH v2 0/3] Bug Fixes for PRUSS irqchip driver

[Meghana Malladi]

Hi All,
This series adds some bug fixes for PRUSS irqchip driver.

v1: https://lore.kernel.org/all/20230919061900.369300-1-danishanwar@ti.com/

v2-v1:
- Rebased to the latest tip

Grygorii Strashko (1):
  irqchip/irq-pruss-intc: Fix listed IRQ type in /proc/interrupts

Suman Anna (2):
  irqchip/irq-pruss-intc: Fix enabling of intc events
  irqchip/irq-pruss-intc: Fix processing of IEP interrupts

 drivers/irqchip/irq-pruss-intc.c | 47 ++++++++++++++++++++++++++++----
 1 file changed, 41 insertions(+), 6 deletions(-)


base-commit: 37a93dd5c49b5fda807fd204edf2547c3493319c
-- 
2.43.0

[PATCH v2 1/3] irqchip/irq-pruss-intc: Fix enabling of intc events

[Meghana Malladi]

From: Suman Anna <s-anna@ti.com>

PRUSS INTC events are enabled by default once IRQ events are mapped to
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().

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/
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>
---
 drivers/irqchip/irq-pruss-intc.c | 24 ++++++++++++++++++------
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/irqchip/irq-pruss-intc.c b/drivers/irqchip/irq-pruss-intc.c
index 81078d56f38d..4ec1f4fc491f 100644
--- a/drivers/irqchip/irq-pruss-intc.c
+++ b/drivers/irqchip/irq-pruss-intc.c
@@ -101,6 +101,7 @@ struct pruss_intc_match_data {
  * @soc_config: cached PRUSS INTC IP configuration data
  * @dev: PRUSS INTC device pointer
  * @lock: mutex to serialize interrupts mapping
+ * @irqs_reserved: bit-mask of reserved host interrupts
  */
 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;
 };
 
 /**
@@ -178,6 +180,7 @@ static void pruss_intc_update_hmr(struct pruss_intc *intc, u8 ch, u8 host)
 static void pruss_intc_map(struct pruss_intc *intc, unsigned long hwirq)
 {
 	struct device *dev = intc->dev;
+	bool enable_hwirq = false;
 	u8 ch, host, reg_idx;
 	u32 val;
 
@@ -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));
 
 	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 */
+	if (enable_hwirq)
+		pruss_intc_write_reg(intc, PRU_INTC_ESR(reg_idx), val);
 
 	if (++intc->channel_host[ch].ref_count == 1) {
 		pruss_intc_update_hmr(intc, ch, host);
@@ -204,7 +212,8 @@ static void pruss_intc_map(struct pruss_intc *intc, unsigned long hwirq)
 		pruss_intc_write_reg(intc, PRU_INTC_HIEISR, host);
 	}
 
-	dev_dbg(dev, "mapped system_event = %lu channel = %d host = %d",
+	dev_dbg(dev, "mapped%s system_event = %lu channel = %d host = %d",
+		enable_hwirq ? " and enabled" : "",
 		hwirq, ch, host);
 
 	mutex_unlock(&intc->lock);
@@ -268,11 +277,14 @@ static void pruss_intc_init(struct pruss_intc *intc)
 
 	/*
 	 * configure polarity (SIPR register) to active high and
-	 * type (SITR register) to level interrupt for all system events
+	 * type (SITR register) to level interrupt for all system events,
+	 * and disable and clear all the system events
 	 */
 	for (i = 0; i < num_event_type_regs; i++) {
 		pruss_intc_write_reg(intc, PRU_INTC_SIPR(i), 0xffffffff);
 		pruss_intc_write_reg(intc, PRU_INTC_SITR(i), 0);
+		pruss_intc_write_reg(intc, PRU_INTC_ECR(i), 0xffffffff);
+		pruss_intc_write_reg(intc, PRU_INTC_SECR(i), 0xffffffff);
 	}
 
 	/* clear all interrupt channel map registers, 4 events per register */
@@ -521,7 +533,7 @@ static int pruss_intc_probe(struct platform_device *pdev)
 	struct pruss_intc *intc;
 	struct pruss_host_irq_data *host_data;
 	int i, irq, ret;
-	u8 max_system_events, irqs_reserved = 0;
+	u8 max_system_events;
 
 	data = of_device_get_match_data(dev);
 	if (!data)
@@ -542,7 +554,7 @@ static int pruss_intc_probe(struct platform_device *pdev)
 		return PTR_ERR(intc->base);
 
 	ret = of_property_read_u8(dev->of_node, "ti,irqs-reserved",
-				  &irqs_reserved);
+				  &intc->irqs_reserved);
 
 	/*
 	 * The irqs-reserved is used only for some SoC's therefore not having
@@ -561,7 +573,7 @@ static int pruss_intc_probe(struct platform_device *pdev)
 		return -ENOMEM;
 
 	for (i = 0; i < MAX_NUM_HOST_IRQS; i++) {
-		if (irqs_reserved & BIT(i))
+		if (intc->irqs_reserved & BIT(i))
 			continue;
 
 		irq = platform_get_irq_byname(pdev, irq_names[i]);
-- 
2.43.0

Re: [PATCH v2 1/3] irqchip/irq-pruss-intc: Fix enabling of intc events

[Thomas Gleixner]

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

[PATCH v2 2/3] irqchip/irq-pruss-intc: Fix listed IRQ type in /proc/interrupts

[Meghana Malladi]

From: Grygorii Strashko <grygorii.strashko@ti.com>

The PRUSS INTC driver doesn't have .irq_set_type() callback implemented and
supports only IRQ_TYPE_LEVEL_HIGH. This resulted in the IRQ properties not
being updated properly and the PRUSS INTC IRQs were listed incorrectly in
/proc/interrupts as Edge.

Example:
  218:          0  4b220000.interrupt-controller  26 Edge      pru10

Fix this by adding a simple .irq_set_type() implementation which checks the
requested IRQ triggering type.

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-3-danishanwar@ti.com/
Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Meghana Malladi <m-malladi@ti.com>
---
 drivers/irqchip/irq-pruss-intc.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/irqchip/irq-pruss-intc.c b/drivers/irqchip/irq-pruss-intc.c
index 4ec1f4fc491f..1fdf110d94ed 100644
--- a/drivers/irqchip/irq-pruss-intc.c
+++ b/drivers/irqchip/irq-pruss-intc.c
@@ -373,6 +373,14 @@ static int pruss_intc_irq_set_irqchip_state(struct irq_data *data,
 	return 0;
 }
 
+static int pruss_intc_irq_irq_set_type(struct irq_data *data, unsigned int type)
+{
+	if (type != IRQ_TYPE_LEVEL_HIGH)
+		return -EINVAL;
+
+	return 0;
+}
+
 static struct irq_chip pruss_irqchip = {
 	.name			= "pruss-intc",
 	.irq_ack		= pruss_intc_irq_ack,
@@ -382,6 +390,7 @@ static struct irq_chip pruss_irqchip = {
 	.irq_release_resources	= pruss_intc_irq_relres,
 	.irq_get_irqchip_state	= pruss_intc_irq_get_irqchip_state,
 	.irq_set_irqchip_state	= pruss_intc_irq_set_irqchip_state,
+	.irq_set_type		= pruss_intc_irq_irq_set_type,
 };
 
 static int pruss_intc_validate_mapping(struct pruss_intc *intc, int event,
-- 
2.43.0

Re: [PATCH v2 2/3] irqchip/irq-pruss-intc: Fix listed IRQ type in /proc/interrupts

[Thomas Gleixner]

On Wed, Feb 18 2026 at 15:07, Meghana Malladi wrote:
> From: Grygorii Strashko <grygorii.strashko@ti.com>
>
> The PRUSS INTC driver doesn't have .irq_set_type() callback implemented and
> supports only IRQ_TYPE_LEVEL_HIGH. This resulted in the IRQ properties not
> being updated properly and the PRUSS INTC IRQs were listed incorrectly in
> /proc/interrupts as Edge.

That's again incomprehensible word salad. If the driver only supports
edge then obviously all interrupts belonging to this chip are marked
edge. How should they be listed?

> Example:
>   218:          0  4b220000.interrupt-controller  26 Edge      pru10

That's really useful information because nobody knows how
/proc/interrupt output looks like.

> Fix this by adding a simple .irq_set_type() implementation which checks the
> requested IRQ triggering type.

And how does that list the the PRUSS interrupts magically with some
other type than edge?

> 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-3-danishanwar@ti.com/
> Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
> Reviewed-by: Roger Quadros <rogerq@kernel.org>
> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
> Signed-off-by: Meghana Malladi <m-malladi@ti.com>

Amazing how many people it takes to get such a trivial fix to LKML and
that none of them noticed that the change log does not make any sense at all.
  
Thanks,

        tglx

Re: [PATCH v2 2/3] irqchip/irq-pruss-intc: Fix listed IRQ type in /proc/interrupts

[Thomas Gleixner]

On Sun, Feb 22 2026 at 23:39, Thomas Gleixner wrote:

> On Wed, Feb 18 2026 at 15:07, Meghana Malladi wrote:
>> From: Grygorii Strashko <grygorii.strashko@ti.com>
>>
>> The PRUSS INTC driver doesn't have .irq_set_type() callback implemented and
>> supports only IRQ_TYPE_LEVEL_HIGH. This resulted in the IRQ properties not
>> being updated properly and the PRUSS INTC IRQs were listed incorrectly in
>> /proc/interrupts as Edge.
>
> That's again incomprehensible word salad. If the driver only supports
> edge then obviously all interrupts belonging to this chip are marked
> edge. How should they be listed?

Oops. Sorry. I misread the IRQ_TYPE_LEVEL_HIGH as EDGE_HIGH. Need new
glasses.

        Thomas

[PATCH v2 3/3] irqchip/irq-pruss-intc: Fix processing of IEP interrupts

[Meghana Malladi]

From: Suman Anna <s-anna@ti.com>

IEP compare/capture events are level-triggered and remain asserted until
the IEP CMP/CAP status register is cleared. The PRUSS INTC acknowledges
this event (via SICR) before the IEP source is actually cleared, leaving the
SECR latch still set. When linux unmasks the interrupt after the threaded
handler completes, the INTC still sees the event as pending, resulting in
an unintended second interrupt.

The solution is to actually ack these IRQs from pruss_intc_irq_unmask()
after the IRQ source is cleared in HW.

The interrupt handling sequence is as follows:
IEP hardware
============
[1] Compare match occurs
[2] IEP sets CMP/CAP status bit = 1
[3] Output level stays HIGH until software clears IEP status

PRUSS INTC
==========
[4] Detects level HIGH → sets SECR[event] = 1
[5] Raises host IRQ to Linux

Linux interrupt flow (oneshot)
==============================
 HARD IRQ:
   [6] pruss_intc_irq_handler()
   [7] mask_ack_irq()
         → writes SICR = event
         → tries to clear SECR
         BUT level still HIGH → INTC still sees it pending

 THREAD HANDLER:
   [8] icss_iep_cap_cmp_handler()
         → clears IEP CMP/CAP status bit
         → IEP output level goes LOW

 IRQ FINALIZATION:
   [9] irq_finalize_oneshot()
  [10] pruss_intc_irq_unmask():
         Without fix:
             - EISR reenables event
             - INTC still thinks event pending (stale SECR)
             → SECOND IRQ (spurious)

         With fix:
             - Write SICR again (now level LOW → INTC clears latch)
             - Then EISR enables event cleanly
             → No spurious IRQ

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>
Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
Link: https://lore.kernel.org/all/20230919061900.369300-4-danishanwar@ti.com/
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Meghana Malladi <m-malladi@ti.com>
---

v2-v1:
- Updated the commit message with more details on the fix as per comments
  from Marc Zyngier <maz@kernel.org>

 drivers/irqchip/irq-pruss-intc.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/drivers/irqchip/irq-pruss-intc.c b/drivers/irqchip/irq-pruss-intc.c
index 1fdf110d94ed..17b03e0d012e 100644
--- a/drivers/irqchip/irq-pruss-intc.c
+++ b/drivers/irqchip/irq-pruss-intc.c
@@ -70,6 +70,8 @@
 #define MAX_PRU_SYS_EVENTS 160
 #define MAX_PRU_CHANNELS 20
 
+#define MAX_PRU_INT_EVENTS	64
+
 /**
  * struct pruss_intc_map_record - keeps track of actual mapping state
  * @value: The currently mapped value (channel or host)
@@ -85,10 +87,13 @@ struct pruss_intc_map_record {
  * @num_system_events: number of input system events handled by the PRUSS INTC
  * @num_host_events: number of host events (which is equal to number of
  *		     channels) supported by the PRUSS INTC
+ * @quirky_events: bitmask of events that need quirky IRQ handling (limited to
+ *		   (internal sources only for now, so 64 bits suffice)
  */
 struct pruss_intc_match_data {
 	u8 num_system_events;
 	u8 num_host_events;
+	u64 quirky_events;
 };
 
 /**
@@ -304,6 +309,10 @@ static void pruss_intc_irq_ack(struct irq_data *data)
 	struct pruss_intc *intc = irq_data_get_irq_chip_data(data);
 	unsigned int hwirq = data->hwirq;
 
+	if (hwirq < MAX_PRU_INT_EVENTS &&
+	    intc->soc_config->quirky_events & BIT_ULL(hwirq))
+		return;
+
 	pruss_intc_write_reg(intc, PRU_INTC_SICR, hwirq);
 }
 
@@ -320,6 +329,9 @@ static void pruss_intc_irq_unmask(struct irq_data *data)
 	struct pruss_intc *intc = irq_data_get_irq_chip_data(data);
 	unsigned int hwirq = data->hwirq;
 
+	if (hwirq < MAX_PRU_INT_EVENTS &&
+	    intc->soc_config->quirky_events & BIT_ULL(hwirq))
+		pruss_intc_write_reg(intc, PRU_INTC_SICR, hwirq);
 	pruss_intc_write_reg(intc, PRU_INTC_EISR, hwirq);
 }
 
@@ -641,11 +653,13 @@ static void pruss_intc_remove(struct platform_device *pdev)
 static const struct pruss_intc_match_data pruss_intc_data = {
 	.num_system_events = 64,
 	.num_host_events = 10,
+	.quirky_events = BIT_ULL(7), /* IEP capture/compare event */
 };
 
 static const struct pruss_intc_match_data icssg_intc_data = {
 	.num_system_events = 160,
 	.num_host_events = 20,
+	.quirky_events = BIT_ULL(7) | BIT_ULL(56), /* IEP{0,1} capture/compare events */
 };
 
 static const struct of_device_id pruss_intc_of_match[] = {
-- 
2.43.0

Re: [PATCH v2 3/3] irqchip/irq-pruss-intc: Fix processing of IEP interrupts

[Thomas Gleixner]

On Wed, Feb 18 2026 at 15:07, Meghana Malladi wrote:
> IEP compare/capture events are level-triggered and remain asserted until
> the IEP CMP/CAP status register is cleared. The PRUSS INTC acknowledges

The INTC does not acknowledge anything. The driver does.

> this event (via SICR) before the IEP source is actually cleared, leaving the
> SECR latch still set. When linux unmasks the interrupt after the threaded
> handler completes, the INTC still sees the event as pending, resulting in
> an unintended second interrupt.
>
> The solution is to actually ack these IRQs from pruss_intc_irq_unmask()

s/IRQ/interrupt/g

> after the IRQ source is cleared in HW.
>
> The interrupt handling sequence is as follows:
> IEP hardware
> ============
> [1] Compare match occurs
> [2] IEP sets CMP/CAP status bit = 1
> [3] Output level stays HIGH until software clears IEP status
>
> PRUSS INTC
> ==========
> [4] Detects level HIGH → sets SECR[event] = 1
> [5] Raises host IRQ to Linux
>
> Linux interrupt flow (oneshot)
> ==============================
>  HARD IRQ:
>    [6] pruss_intc_irq_handler()
>    [7] mask_ack_irq()
>          → writes SICR = event
>          → tries to clear SECR
>          BUT level still HIGH → INTC still sees it pending
>
>  THREAD HANDLER:
>    [8] icss_iep_cap_cmp_handler()
>          → clears IEP CMP/CAP status bit
>          → IEP output level goes LOW
>
>  IRQ FINALIZATION:
>    [9] irq_finalize_oneshot()
>   [10] pruss_intc_irq_unmask():
>          Without fix:
>              - EISR reenables event
>              - INTC still thinks event pending (stale SECR)
>              → SECOND IRQ (spurious)
>
>          With fix:
>              - Write SICR again (now level LOW → INTC clears latch)
>              - Then EISR enables event cleanly
>              → No spurious IRQ

Having the ACK in the unmask is fundamentally wrong and a horrible hack.

The driver uses the wrong handler. That's what handle_fasteoi_irq() is
for.

All you need is to set the IRQCHIP_EOI_THREADED flag on the interrupt
chip and implement irq_eoi() instead of irq_ack().

For the non-threaded cases this spares the mask/unmask dance
completely. For the threaded oneshot case it masks on entry and
irq_finalize_oneshot() does the EOI and the unmask via
unmask_threaded_irq().

No?

Thanks,

        tglx