[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=FV=VX1Kh0UhJBX2JcSjSo7KaSQggicnVFYV8M31ocx3PYpg@mail.gmail.com>
Date: Fri, 7 Feb 2020 10:59:06 -0800
From: Doug Anderson <dianders@...omium.org>
To: Lina Iyer <ilina@...eaurora.org>
Cc: Stephen Boyd <swboyd@...omium.org>,
Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>,
Marc Zyngier <maz@...nel.org>,
Maulik Shah <mkshah@...eaurora.org>
Subject: Re: [PATCH v2] genirq: Clarify that irq wake state is orthogonal to enable/disable
Hi,
On Thu, Feb 6, 2020 at 11:57 AM Lina Iyer <ilina@...eaurora.org> wrote:
>
> On Thu, Feb 06 2020 at 12:15 -0700, Stephen Boyd wrote:
> >There's some confusion around if an irq that's disabled with
> >disable_irq() can still wake the system from sleep states such as
> >"suspend to RAM". Let's clarify this in the kernel documentation for
> >irq_set_irq_wake() so that it's clear that an irq can be disabled and
> >still wake the system if it has been marked for wakeup.
> >
> Thomas also mentioned that hardware could work either way and probably
> should not be assumed to work one way or the other.
Right...
...and then (paraphrasing) Stephen pointed out that policy makes it
really hard for clients of the API to work properly.
...and then (paraphrasing) Thomas said "Good point. As long as you
document that not all drivers _actually_ behave the way you describe,
it's fine to add a comment saying that drivers _should_ behave the way
you describe".
Or, said another way: if a driver doesn't behave the way Stephen
describes then it should be fixed unless there is some reason why
there is no possible way to make it happen.
(Thomas / Stephen: please correct if I got my paraphrasing incorrect).
-Doug
Powered by blists - more mailing lists