linux-kernel - Re: [RFC] irqchip: gic: always mask interrupts during suspend

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] [day] [month] [year] [list]

Message-ID: <5398766D.1070900@wwwdotorg.org>
Date:	Wed, 11 Jun 2014 09:31:57 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Brian Norris <computersforpeace@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>
CC:	Florian Fainelli <f.fainelli@...il.com>,
	Tony Lindgren <tony@...mide.com>,
	Thierry Reding <thierry.reding@...il.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Michal Simek <michal.simek@...inx.com>,
	Jason Cooper <jason@...edaemon.net>,
	linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, linux-tegra@...r.kernel.org
Subject: Re: [RFC] irqchip: gic: always mask interrupts during suspend

On 06/10/2014 05:48 PM, Brian Norris wrote:
> On Wed, Jun 11, 2014 at 01:34:39AM +0200, Thomas Gleixner wrote:
>> On Tue, 10 Jun 2014, Brian Norris wrote:
>>> Other random thought: it seems like any irqchip driver which does lazy IRQ
>>> masking ought to use IRQCHIP_MASK_ON_SUSPEND. So maybe the IRQ core should just
>>> do something like:
>>>
>>> 	if (!chip->irq_disable)
>>> 		chip->flags |= IRQCHIP_MASK_ON_SUSPEND;
>>
>> No. Lazy irq disable and the suspend logic are different beasts.
> 
> OK, fair enough. Drop that random thought then. It's not in the patch
> content anyway.
> 
>> That's up to the platform to decide this. Just for the record: there
>> is a world outside of ARM...
> 
> OK. But GIC is ARM-specific, so we can still constrain this patch and
> related topics to the world of ARM.
> 
>> But that brings me to a different question:
>>
>>     Why are you not putting that customization into the device tree
>>     instead of trying to add this to some random arch/arm/mach-foo
>>     files?
> 
> I'm not adding customization to arch/arm/mach-foo files. I'm trying to
> remove it.
> 
> This property could be added to device tree, if there was really a valid
> use case for a GIC which leaves its interrupts unmasked for suspend. My
> question in this patch is essentially: does such a use case exist?

DT should genernally only contain data that's expected to vary between
boards, or just possibly between SoCs. Anything that the kernel knows
simply because it knows what HW model it's driving has no place in DT,
since it just adds redundant work to parse the DT and end up with the
same data.

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