linux-kernel - Re: [PATCH] genirq: Clarify that irq wake state is orthogonal to enable/disable

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: <87r1z8rqzs.fsf@nanos.tec.linutronix.de>
Date:   Thu, 06 Feb 2020 09:42:47 +0000
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Stephen Boyd <swboyd@...omium.org>
Cc:     linux-kernel@...r.kernel.org, Marc Zyngier <maz@...nel.org>,
        Douglas Anderson <dianders@...omium.org>,
        Lina Iyer <ilina@...eaurora.org>,
        Maulik Shah <mkshah@...eaurora.org>
Subject: Re: [PATCH] genirq: Clarify that irq wake state is orthogonal to enable/disable

Stephen Boyd <swboyd@...omium.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