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]

Date:	Fri, 20 Feb 2015 14:22:08 +0000
From:	Mark Rutland <mark.rutland@....com>
To:	Boris Brezillon <boris.brezillon@...e-electrons.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 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.

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

  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.

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

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.

Thanks,
Mark.
--
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/