Re: Add IRQS_PENDING for nested and simple irq handler as well

[Ning Jiang]

Sorry that I do not make myself clear.

First, we should keep all the handle_*_irq behave in pretty much the
same way even just for the beauty of it. Every interrupt disabled in
suspend operation needs the ability to abort suspend if there is a
pending irq.

Second, let's take look at a example:

              |
       +---------+
        |   INTC  |
       +---------+
                  |  GPIO_IRQ
            +------------+
             | gpio-exp  |
            +------------+
               |            |
   GPIO0_IRQ  GPIO1_IRQ

In the above diagram, gpio expander has irq number GPIO_IRQ, it is
connected with two sub GPIO pins, GPIO0 and GPIO1.

During suspend, normally we want to set IRQF_NO_SUSPEND for GPIO_IRQ
so that gpio expander driver can handle the sub irq GPIO0_IRQ and
GPIO1_IRQ, and these two irqs themselves are handled by simple or
nested irq in some drivers(typically gpio and mfd driver), if they are
disabled during suspend, we want them to be able to abort suspend too.

2012/5/22 Thomas Gleixner <tglx@xxxxxxxxxxxxx>:
> On Tue, 22 May 2012, Ning Jiang wrote:
>
>> >From eb72d4c573b482f85b227558deca297d8a8de1df Mon Sep 17 00:00:00 2001
>> From: Ning Jiang <ning.n.jiang@xxxxxxxxx>
>> Date: Tue, 22 May 2012 00:19:20 +0800
>> Subject: [PATCH] genirq: Add IRQS_PENDING for nested and simple irq
>> handler as well
>>
>> Usually nested and simple irq act as second level in interrupt
>> distribution tree, in suspend, we need to keep first level irq
>> functional by irq flag IRQF_NO_SUSPEND and check the 'pending'
>> state in the second level.
>>
>> More information can be found in the log of commit:
>
> Please provide a proper explanation why you think that handling the
> flag for those interrupts is important as well, rather than refering
> to an explanation of something different.
>
> Thanks,
>
>        tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/