From: Stephen Warren <swarren@wwwdotorg.org>
To: Brian Norris <computersforpeace@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
Tony Lindgren <tony@atomide.com>,
Thierry Reding <thierry.reding@gmail.com>,
Linus Walleij <linus.walleij@linaro.org>,
Michal Simek <michal.simek@xilinx.com>,
Jason Cooper <jason@lakedaemon.net>,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org
Subject: Re: [RFC] irqchip: gic: always mask interrupts during suspend
Date: Wed, 11 Jun 2014 09:31:57 -0600 [thread overview]
Message-ID: <5398766D.1070900@wwwdotorg.org> (raw)
In-Reply-To: <20140610234826.GK3599@ld-irv-0074>
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.
prev parent reply other threads:[~2014-06-11 15:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-10 23:14 [RFC] irqchip: gic: always mask interrupts during suspend Brian Norris
2014-06-10 23:34 ` Thomas Gleixner
2014-06-10 23:48 ` Brian Norris
2014-06-11 15:31 ` Stephen Warren [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5398766D.1070900@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=computersforpeace@gmail.com \
--cc=f.fainelli@gmail.com \
--cc=jason@lakedaemon.net \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=michal.simek@xilinx.com \
--cc=tglx@linutronix.de \
--cc=thierry.reding@gmail.com \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox