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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.02.1205221048140.3231@ionos>
Date:	Tue, 22 May 2012 10:49:48 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Ning Jiang <ning.n.jiang@...il.com>
cc:	rjw@...k.pl, linux-kernel@...r.kernel.org
Subject: Re: Add IRQS_PENDING for nested and simple irq handler as well

On Tue, 22 May 2012, Ning Jiang wrote:

Please do not top post.

> 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.

Ok, that makes a lot of sense and should be part of the changelog, so
we know in a year from now why we did this change. Care to resend with
a fixed up changelog ?

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/