From: Thomas Gleixner <tglx@linutronix.de>
To: Stephen Boyd <swboyd@chromium.org>
Cc: linux-kernel@vger.kernel.org, Marc Zyngier <maz@kernel.org>,
Douglas Anderson <dianders@chromium.org>,
Lina Iyer <ilina@codeaurora.org>,
Maulik Shah <mkshah@codeaurora.org>
Subject: Re: [PATCH] genirq: Clarify that irq wake state is orthogonal to enable/disable
Date: Thu, 06 Feb 2020 09:42:47 +0000 [thread overview]
Message-ID: <87r1z8rqzs.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <5e3b279f.1c69fb81.383f9.1da3@mx.google.com>
Stephen Boyd <swboyd@chromium.org> writes:
> Quoting Thomas Gleixner (2020-02-05 04:27:06)
>> > * Wakeup mode lets this IRQ wake the system from sleep
>> > * states like "suspend to RAM".
>> > + *
>> > + * Note: irq enable/disable state is completely orthogonal
>> > + * to the enable/disable state of irq wake. An irq can be
>> > + * disabled with disable_irq() and still wake the system as
>> > + * long as the irq has wake enabled.
>>
>> It clearly should say that this is really depending on the hardware
>> implementation of the particual interrupt chip whether disabled + wake
>> mode is supported.
>>
>
> Ok. I'm having trouble parsing this. Is there a consistent wording that
> can be put here?
See below.
> The API seems fraught with peril if an implementation of an irqchip is
> allowed to ignore wakeup on interrupts that are marked for wakeup while
> the irq is disabled. Driver writers won't be able to write drivers that
> work across implementations if the irq can't wake the system reliably.
It's not really well defined but thats a result of the gazillion
variants of irq chips which all have their own quirks. The wakeup
mechansims are also widely different, some of them are built into the
SOC, others require external logic. And a large part of these things is
completely undocumented. Welcome to my wonderful world.
So versus consistent wording. I'm fine with the paragraph you suggested,
but please amend it with something like this:
If this does not hold, then either the underlying irq chip and the
related driver need to be investigated.
Thanks,
tglx
prev parent reply other threads:[~2020-02-06 9:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-05 6:09 Stephen Boyd
2020-02-05 12:27 ` Thomas Gleixner
2020-02-05 15:34 ` Lina Iyer
2020-02-05 15:52 ` Thomas Gleixner
2020-02-05 20:37 ` Stephen Boyd
2020-02-06 9:42 ` Thomas Gleixner [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=87r1z8rqzs.fsf@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=dianders@chromium.org \
--cc=ilina@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=mkshah@codeaurora.org \
--cc=swboyd@chromium.org \
/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
all inboxes | Powered by JetHome®