linux-kernel - Re: [PATCH v4 3/5] irqchip: Add DT binding doc for the virtual irq demuxer chip

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: <20150220155347.1477b02d@bbrezillon>
Date:	Fri, 20 Feb 2015 15:53:47 +0100
From:	Boris Brezillon <boris.brezillon@...e-electrons.com>
To:	Mark Rutland <mark.rutland@....com>
Cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Jason Cooper <jason@...edaemon.net>,
	Nicolas Ferre <nicolas.ferre@...el.com>,
	Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>,
	Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <Pawel.Moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 3/5] irqchip: Add DT binding doc for the virtual irq
 demuxer chip

Hi Mark,

On Fri, 20 Feb 2015 14:22:08 +0000
Mark Rutland <mark.rutland@....com> wrote:

> Hi Boris,
> 
> On Wed, Feb 11, 2015 at 04:38:23PM +0000, Boris Brezillon wrote:
> 
> [...]
> 
> > For the list of impacted drivers, you can have a look at this series [1]
> > (patches 2 to 5), and I'll take care of the testing part once every one
> > has agreed on the solution ;-).
> > 
> > [1]https://lkml.org/lkml/2014/12/15/552
> 
> Looking at those:
> 
> * The pmc looks like it could be a valid use of the new flag. It also
>   seems to function as an irqchip.
>   
>   Do any of its child IRQs need to be handled during the suspend-resume
>   cycle? If so using IRQF_NO_SUSPEND would seem to be valid.

No they don't, they are used for clock activation only, and thus should
be disabled on suspend.

> 
> * atmel_serial seems to be intended to be used as a wakeup device (given
>   it calls device_set_wakeup_enable). Therefore it needs to call
>   enable_irq_wake, and when it does so it can share an IRQ with other
>   interrupts, just not IRQF_NO_SUSPEND interrupts.

I'll have a look, but AFAIR serial core already taking care of that.

>   
>   None of the approaches thus far can fix the fundamental mismatch
>   between wakeup interrupts and IRQF_NO_SUSPEND interrupts.
> 
> * Similarly, rtc-at91rm9200 and rtc-at91sam9 are intended to be used as 
>   wakeup devices. They call enable_irq_wake (though don't bother
>   checking the return value). They can share an IRQ with other
>   interrupts, just not IRQF_NO_SUSPEND interrupts.

Yep.

> 
> * at91sam9_wdt seems to be fundamentally incompatible with suspend. If
>   the watchdog cannot be disabled, and you need to handle it during
>   suspend, then it needs to be a wakeup interrupt, not an
>   IRQF_NO_SUSPEND interrupt.

You forgot the PIT timer, which is the one in cause here (no other
drivers are specifying this IRQF_NO_SUSPEND flag), and, as you already
know, a timer sets the IRQF_NO_SUSPEND flag.

> 
> As far as I can see, the flag or virtual irqchip approaches only help
> the PMC case, and even then might not be necessary. All the others seem
> to be relying on guarantees the genirq layer don't provide, and fixing
> that would mean moving them further from IRQF_NO_SUSPEND.

I don't know what you're trying to prove here, but I never said my goal
was to set IRQF_NO_SUSPEND flags on existing at91 drivers ?
The problem here, is that all those IPs are sharing the irq line with a
timer which sets IRQF_NO_SUSPEND.

I just want to be able to share an irq line with a timer and other
devices that do not set IRQF_NO_SUSPEND.
Could we focus on that ?

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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/