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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 11 Feb 2015 14:14:37 +0000
From:	Mark Rutland <mark.rutland@....com>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Boris Brezillon <boris.brezillon@...e-electrons.com>,
	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

On Wed, Feb 11, 2015 at 02:31:18PM +0000, Rafael J. Wysocki wrote:
> On Wednesday, February 11, 2015 11:15:17 AM Mark Rutland wrote:
> > On Wed, Feb 11, 2015 at 09:11:59AM +0000, Peter Zijlstra wrote:
> > > On Tue, Feb 10, 2015 at 08:48:36PM +0000, Mark Rutland wrote:
> > > > From f390ccbb31f06efee49b4469943c8d85d963bfb5 Mon Sep 17 00:00:00 2001
> > > > From: Mark Rutland <mark.rutland@....com>
> > > > Date: Tue, 10 Feb 2015 20:14:33 +0000
> > > > Subject: [PATCH] genirq: allow mixed IRQF_NO_SUSPEND requests
> > > > 
> > > > In some cases a physical IRQ line may be shared between devices from
> > > > which we expect interrupts during suspend (e.g. timers) and those we do
> > > > not (e.g. anything we cut the power to). Where a driver did not request
> > > > the interrupt with IRQF_NO_SUSPEND, it's unlikely that it can handle
> > > > being called during suspend, and it may bring down the system.
> > > > 
> > > > This patch adds logic to automatically mark the irqactions for these
> > > > potentially unsafe handlers as disabled during suspend, leaving actions
> > > > with IRQF_NO_SUSPEND enabled. If an interrupt is raised on a shared line
> > > > during suspend, only the handlers requested with IRQF_NO_SUSPEND will be
> > > > called. The handlers requested without IRQF_NO_SUSPEND will be skipped
> > > > as if they had immediately returned IRQF_NONE.
> > > > 
> > > > Cc: Boris Brezillon <boris.brezillon@...e-electrons.com>
> > > > Cc: Jason Cooper <jason@...edaemon.net>
> > > > Cc: Nicolas Ferre <nicolas.ferre@...el.com>
> > > > Cc: Peter Zijlstra <peterz@...radead.org>
> > > > Cc: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> > > > Cc: Thomas Gleixner <tglx@...utronix.de>
> > > > Signed-off-by: Mark Rutland <mark.rutland@....com>
> > > 
> > > Aw gawd.. not that again.
> > 
> > I agree this isn't pretty, but at least it doesn't require the HW
> > description to know about Linux internals, and it can work for !DT
> > systems.
> > 
> > I'm really not happy with placing Linux implementation details into
> > DTBs.
> > 
> > > So Rafael and tglx went over this a few months ago I think:
> > > 
> > >   lkml.kernel.org/r/26580319.OZP7jvJnA9@...tro.rjw.lan
> > > 
> > > is the last series I could find. Maybe Rafael can summarize?
> > 
> > I can't get at any commentary from that link, unfortunately.
> > 
> > Rafael?
> 
> Well, the commentary is not there, because both I and Thomas implicitly agreed
> on one thing: We cannot add any suspend-related checks to the interrupt handling
> hot path, because that will affect everyone including people who don't use
> suspend at all and who *really* care about interrupt handling performance.

That's fair enough, and I'm happy to avoid that by other means.

My fundamental objection(s) to the current approach is that we create a
binding for a non-existent device that people will abuse without
considering the consequences. All we will end up with is more DTBs
containing the mux regardless of wether the drivers (or hardware) are
actually safe with a shared line.

So with the changes moves out of the hot-path (e.g. with shuffling
to/from a suspended_actions list in the pm code), is there some issue
that I have not considered?

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/