Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
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
In-Reply-To: <5e3b279f.1c69fb81.383f9.1da3@mx.google.com>
References: <20200205060953.49167-1-swboyd@chromium.org> <87zhdxrzhh.fsf@nanos.tec.linutronix.de> <5e3b279f.1c69fb81.383f9.1da3@mx.google.com>
Date:   Thu, 06 Feb 2020 09:42:47 +0000
Message-ID: <87r1z8rqzs.fsf@nanos.tec.linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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