When the wakeup attribute is set, the GPIO button is capable of
waking up the system from sleep states, including the "freeze"
sleep state. For that to work, its driver needs to pass the
IRQF_NO_SUSPEND flag to devm_request_any_context_irq(), or the
interrupt will be disabled by suspend_device_irqs() and the
system won't be woken up by it from the "freeze" sleep state.
The suspend_device_irqs() routine is a workaround for drivers
that mishandle interrupts triggered when the devices handled
by them are suspended, so it is safe to use IRQF_NO_SUSPEND in
all drivers that don't have that problem.
The affected/tested machines include Dell Venue 11 Pro and Asus T100TA.
Signed-off-by: Aubrey Li <[email protected]>
Reviewed-by: Rafael J. Wysocki <[email protected]>
---
drivers/input/keyboard/gpio_keys.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
index 8c98e97..b046dc6 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -527,6 +527,14 @@ static int gpio_keys_setup_key(struct platform_device *pdev,
if (!button->can_disable)
irqflags |= IRQF_SHARED;
+ /*
+ * If platform has specified the wakeup attribute of the button,
+ * we add IRQF_NO_SUSPEND to desc->action->flag. So the wake up
+ * interrupt will not be disabled in suspend_device_irqs
+ */
+ if (button->wakeup)
+ irqflags |= IRQF_NO_SUSPEND;
+
error = devm_request_any_context_irq(&pdev->dev, bdata->irq,
isr, irqflags, desc, bdata);
if (error < 0) {
--
1.7.10.4
On Thu, 19 Jun 2014 08:51:25 +0800
"Li, Aubrey" <[email protected]> wrote:
> When the wakeup attribute is set, the GPIO button is capable of
> waking up the system from sleep states, including the "freeze"
> sleep state. For that to work, its driver needs to pass the
> IRQF_NO_SUSPEND flag to devm_request_any_context_irq(), or the
> interrupt will be disabled by suspend_device_irqs() and the
> system won't be woken up by it from the "freeze" sleep state.
>
> The suspend_device_irqs() routine is a workaround for drivers
> that mishandle interrupts triggered when the devices handled
> by them are suspended, so it is safe to use IRQF_NO_SUSPEND in
> all drivers that don't have that problem.
>
> The affected/tested machines include Dell Venue 11 Pro and Asus T100TA.
>
> Signed-off-by: Aubrey Li <[email protected]>
> Reviewed-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Alan Cox <[email protected]>
ping...
On 2014/6/19 18:40, One Thousand Gnomes wrote:
> On Thu, 19 Jun 2014 08:51:25 +0800
> "Li, Aubrey" <[email protected]> wrote:
>
>> When the wakeup attribute is set, the GPIO button is capable of
>> waking up the system from sleep states, including the "freeze"
>> sleep state. For that to work, its driver needs to pass the
>> IRQF_NO_SUSPEND flag to devm_request_any_context_irq(), or the
>> interrupt will be disabled by suspend_device_irqs() and the
>> system won't be woken up by it from the "freeze" sleep state.
>>
>> The suspend_device_irqs() routine is a workaround for drivers
>> that mishandle interrupts triggered when the devices handled
>> by them are suspended, so it is safe to use IRQF_NO_SUSPEND in
>> all drivers that don't have that problem.
>>
>> The affected/tested machines include Dell Venue 11 Pro and Asus T100TA.
>>
>> Signed-off-by: Aubrey Li <[email protected]>
>> Reviewed-by: Rafael J. Wysocki <[email protected]>
>
> Reviewed-by: Alan Cox <[email protected]>
>
>
>
On Thursday, June 19, 2014 08:51:25 AM Li, Aubrey wrote:
> When the wakeup attribute is set, the GPIO button is capable of
> waking up the system from sleep states, including the "freeze"
> sleep state. For that to work, its driver needs to pass the
> IRQF_NO_SUSPEND flag to devm_request_any_context_irq(), or the
> interrupt will be disabled by suspend_device_irqs() and the
> system won't be woken up by it from the "freeze" sleep state.
>
> The suspend_device_irqs() routine is a workaround for drivers
> that mishandle interrupts triggered when the devices handled
> by them are suspended, so it is safe to use IRQF_NO_SUSPEND in
> all drivers that don't have that problem.
>
> The affected/tested machines include Dell Venue 11 Pro and Asus T100TA.
>
> Signed-off-by: Aubrey Li <[email protected]>
> Reviewed-by: Rafael J. Wysocki <[email protected]>
OK
Due to the lack of response (ie. no objections) and because the issue
addressed by this patch is real, I'm queuing it up as a PM-related fix
for 3.17.
Rafael
> ---
> drivers/input/keyboard/gpio_keys.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
> index 8c98e97..b046dc6 100644
> --- a/drivers/input/keyboard/gpio_keys.c
> +++ b/drivers/input/keyboard/gpio_keys.c
> @@ -527,6 +527,14 @@ static int gpio_keys_setup_key(struct platform_device *pdev,
> if (!button->can_disable)
> irqflags |= IRQF_SHARED;
>
> + /*
> + * If platform has specified the wakeup attribute of the button,
> + * we add IRQF_NO_SUSPEND to desc->action->flag. So the wake up
> + * interrupt will not be disabled in suspend_device_irqs
> + */
> + if (button->wakeup)
> + irqflags |= IRQF_NO_SUSPEND;
> +
> error = devm_request_any_context_irq(&pdev->dev, bdata->irq,
> isr, irqflags, desc, bdata);
> if (error < 0) {
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
On Tue, Jul 08, 2014 at 10:52:52PM +0200, Rafael J. Wysocki wrote:
> On Thursday, June 19, 2014 08:51:25 AM Li, Aubrey wrote:
> > When the wakeup attribute is set, the GPIO button is capable of
> > waking up the system from sleep states, including the "freeze"
> > sleep state. For that to work, its driver needs to pass the
> > IRQF_NO_SUSPEND flag to devm_request_any_context_irq(), or the
> > interrupt will be disabled by suspend_device_irqs() and the
> > system won't be woken up by it from the "freeze" sleep state.
> >
> > The suspend_device_irqs() routine is a workaround for drivers
> > that mishandle interrupts triggered when the devices handled
> > by them are suspended, so it is safe to use IRQF_NO_SUSPEND in
> > all drivers that don't have that problem.
> >
> > The affected/tested machines include Dell Venue 11 Pro and Asus T100TA.
> >
> > Signed-off-by: Aubrey Li <[email protected]>
> > Reviewed-by: Rafael J. Wysocki <[email protected]>
>
> OK
>
> Due to the lack of response (ie. no objections) and because the issue
> addressed by this patch is real, I'm queuing it up as a PM-related fix
> for 3.17.
Please do not. The response is till the same: board code should make sure
that enable_irq_wake() does the right thing and keeps interrupts enabled.
It is wrong to patch drivers for this.
Thanks.
--
Dmitry
On Tuesday, July 08, 2014 01:45:30 PM Dmitry Torokhov wrote:
> On Tue, Jul 08, 2014 at 10:52:52PM +0200, Rafael J. Wysocki wrote:
> > On Thursday, June 19, 2014 08:51:25 AM Li, Aubrey wrote:
> > > When the wakeup attribute is set, the GPIO button is capable of
> > > waking up the system from sleep states, including the "freeze"
> > > sleep state. For that to work, its driver needs to pass the
> > > IRQF_NO_SUSPEND flag to devm_request_any_context_irq(), or the
> > > interrupt will be disabled by suspend_device_irqs() and the
> > > system won't be woken up by it from the "freeze" sleep state.
> > >
> > > The suspend_device_irqs() routine is a workaround for drivers
> > > that mishandle interrupts triggered when the devices handled
> > > by them are suspended, so it is safe to use IRQF_NO_SUSPEND in
> > > all drivers that don't have that problem.
> > >
> > > The affected/tested machines include Dell Venue 11 Pro and Asus T100TA.
> > >
> > > Signed-off-by: Aubrey Li <[email protected]>
> > > Reviewed-by: Rafael J. Wysocki <[email protected]>
> >
> > OK
> >
> > Due to the lack of response (ie. no objections) and because the issue
> > addressed by this patch is real, I'm queuing it up as a PM-related fix
> > for 3.17.
>
> Please do not. The response is till the same: board code should make sure
> that enable_irq_wake() does the right thing and keeps interrupts enabled.
Which board code? That's nothing like that for the platforms in question.
> It is wrong to patch drivers for this.
Why is it? Only drivers know if they can handle incoming interrupts after
having suspended their devices.
Rafael
On Tue, Jul 08, 2014 at 11:06:17PM +0200, Rafael J. Wysocki wrote:
> On Tuesday, July 08, 2014 01:45:30 PM Dmitry Torokhov wrote:
> > On Tue, Jul 08, 2014 at 10:52:52PM +0200, Rafael J. Wysocki wrote:
> > > On Thursday, June 19, 2014 08:51:25 AM Li, Aubrey wrote:
> > > > When the wakeup attribute is set, the GPIO button is capable of
> > > > waking up the system from sleep states, including the "freeze"
> > > > sleep state. For that to work, its driver needs to pass the
> > > > IRQF_NO_SUSPEND flag to devm_request_any_context_irq(), or the
> > > > interrupt will be disabled by suspend_device_irqs() and the
> > > > system won't be woken up by it from the "freeze" sleep state.
> > > >
> > > > The suspend_device_irqs() routine is a workaround for drivers
> > > > that mishandle interrupts triggered when the devices handled
> > > > by them are suspended, so it is safe to use IRQF_NO_SUSPEND in
> > > > all drivers that don't have that problem.
> > > >
> > > > The affected/tested machines include Dell Venue 11 Pro and Asus T100TA.
> > > >
> > > > Signed-off-by: Aubrey Li <[email protected]>
> > > > Reviewed-by: Rafael J. Wysocki <[email protected]>
> > >
> > > OK
> > >
> > > Due to the lack of response (ie. no objections) and because the issue
> > > addressed by this patch is real, I'm queuing it up as a PM-related fix
> > > for 3.17.
> >
> > Please do not. The response is till the same: board code should make sure
> > that enable_irq_wake() does the right thing and keeps interrupts enabled.
>
> Which board code? That's nothing like that for the platforms in question.
Then it needs to be written.
>
> > It is wrong to patch drivers for this.
>
> Why is it? Only drivers know if they can handle incoming interrupts after
> having suspended their devices.
The driver correctly used enable_irq_wake() to indicate that interrupt should
be a wakeup source, the now the core/board needs to make sure the interrupt
gets delivered to the driver properly. We should not be patching every driver
that uses enable_irq_wake() with IRQF_NO_SUSPEND. If you look at the earlier
patch discussion Tegra folks managed to implement this behavior just fine.
Thanks.
--
Dmitry
On Tuesday, July 08, 2014 02:12:59 PM Dmitry Torokhov wrote:
> On Tue, Jul 08, 2014 at 11:06:17PM +0200, Rafael J. Wysocki wrote:
> > On Tuesday, July 08, 2014 01:45:30 PM Dmitry Torokhov wrote:
> > > On Tue, Jul 08, 2014 at 10:52:52PM +0200, Rafael J. Wysocki wrote:
> > > > On Thursday, June 19, 2014 08:51:25 AM Li, Aubrey wrote:
> > > > > When the wakeup attribute is set, the GPIO button is capable of
> > > > > waking up the system from sleep states, including the "freeze"
> > > > > sleep state. For that to work, its driver needs to pass the
> > > > > IRQF_NO_SUSPEND flag to devm_request_any_context_irq(), or the
> > > > > interrupt will be disabled by suspend_device_irqs() and the
> > > > > system won't be woken up by it from the "freeze" sleep state.
> > > > >
> > > > > The suspend_device_irqs() routine is a workaround for drivers
> > > > > that mishandle interrupts triggered when the devices handled
> > > > > by them are suspended, so it is safe to use IRQF_NO_SUSPEND in
> > > > > all drivers that don't have that problem.
> > > > >
> > > > > The affected/tested machines include Dell Venue 11 Pro and Asus T100TA.
> > > > >
> > > > > Signed-off-by: Aubrey Li <[email protected]>
> > > > > Reviewed-by: Rafael J. Wysocki <[email protected]>
> > > >
> > > > OK
> > > >
> > > > Due to the lack of response (ie. no objections) and because the issue
> > > > addressed by this patch is real, I'm queuing it up as a PM-related fix
> > > > for 3.17.
> > >
> > > Please do not. The response is till the same: board code should make sure
> > > that enable_irq_wake() does the right thing and keeps interrupts enabled.
> >
> > Which board code? That's nothing like that for the platforms in question.
>
> Then it needs to be written.
Well, excuse me, but I don't get it. Why would I need to write any board code
for an ACPI-based system?
> > > It is wrong to patch drivers for this.
> >
> > Why is it? Only drivers know if they can handle incoming interrupts after
> > having suspended their devices.
>
> The driver correctly used enable_irq_wake() to indicate that interrupt should
> be a wakeup source, the now the core/board needs to make sure the interrupt
> gets delivered to the driver properly. We should not be patching every driver
> that uses enable_irq_wake() with IRQF_NO_SUSPEND.
Interrupts that can wake up from the "freeze" sleep state need not be set up
with enable_irq_wake() and the flag doesn't say "this is a wakeup interrupt".
It says "do not suspend this interrupt, I can handle it after the device has
been suspended" (as I said).
And if it is OK for a driver to set IRQF_SHARED, it is equally OK for it to
set IRQF_NO_SUSPEND, because, in fact, those two flags are related.
> If you look at the earlier patch discussion Tegra folks managed to implement
> this behavior just fine.
I'm not sure whose idea it was that IRQF_NO_SUSPEND was not to be set by drivers,
but it is not a correct one. I know why suspend_device_irqs() was introduced
and I'm telling you this has nothing to do with setting up the IRQ chip to do
system wakeup.
And please grep for IRQF_NO_SUSPEND to see how drivers generally use it.
Rafael
On Tue, Jul 08, 2014 at 11:47:01PM +0200, Rafael J. Wysocki wrote:
> On Tuesday, July 08, 2014 02:12:59 PM Dmitry Torokhov wrote:
> > On Tue, Jul 08, 2014 at 11:06:17PM +0200, Rafael J. Wysocki wrote:
> > > On Tuesday, July 08, 2014 01:45:30 PM Dmitry Torokhov wrote:
> > > > On Tue, Jul 08, 2014 at 10:52:52PM +0200, Rafael J. Wysocki wrote:
> > > > > On Thursday, June 19, 2014 08:51:25 AM Li, Aubrey wrote:
> > > > > > When the wakeup attribute is set, the GPIO button is capable of
> > > > > > waking up the system from sleep states, including the "freeze"
> > > > > > sleep state. For that to work, its driver needs to pass the
> > > > > > IRQF_NO_SUSPEND flag to devm_request_any_context_irq(), or the
> > > > > > interrupt will be disabled by suspend_device_irqs() and the
> > > > > > system won't be woken up by it from the "freeze" sleep state.
> > > > > >
> > > > > > The suspend_device_irqs() routine is a workaround for drivers
> > > > > > that mishandle interrupts triggered when the devices handled
> > > > > > by them are suspended, so it is safe to use IRQF_NO_SUSPEND in
> > > > > > all drivers that don't have that problem.
> > > > > >
> > > > > > The affected/tested machines include Dell Venue 11 Pro and Asus T100TA.
> > > > > >
> > > > > > Signed-off-by: Aubrey Li <[email protected]>
> > > > > > Reviewed-by: Rafael J. Wysocki <[email protected]>
> > > > >
> > > > > OK
> > > > >
> > > > > Due to the lack of response (ie. no objections) and because the issue
> > > > > addressed by this patch is real, I'm queuing it up as a PM-related fix
> > > > > for 3.17.
> > > >
> > > > Please do not. The response is till the same: board code should make sure
> > > > that enable_irq_wake() does the right thing and keeps interrupts enabled.
> > >
> > > Which board code? That's nothing like that for the platforms in question.
> >
> > Then it needs to be written.
>
> Well, excuse me, but I don't get it. Why would I need to write any board code
> for an ACPI-based system?
Why would not you? What is the difference between ACPI systems and all
other systems? If ACPI-based systems need certain behavior they need to
implement it, the same as DT-based systems or custom boards.
>
> > > > It is wrong to patch drivers for this.
> > >
> > > Why is it? Only drivers know if they can handle incoming interrupts after
> > > having suspended their devices.
> >
> > The driver correctly used enable_irq_wake() to indicate that interrupt should
> > be a wakeup source, the now the core/board needs to make sure the interrupt
> > gets delivered to the driver properly. We should not be patching every driver
> > that uses enable_irq_wake() with IRQF_NO_SUSPEND.
>
> Interrupts that can wake up from the "freeze" sleep state need not be set up
> with enable_irq_wake() and the flag doesn't say "this is a wakeup interrupt".
> It says "do not suspend this interrupt, I can handle it after the device has
> been suspended" (as I said).
And the driver does not really care about this and whether the sleep
state is suspend or freeze or something else, it is your platform that
cares and has certain limitations that require interrupts to be not
suspended in certain cases.
>From the driver POV it says that the device can be a waekup source
(again it does not care about details as to which sleep state we woudl
be waking from) and it expects the PM core to handle the things
properly. If certain sleep state requires interrupts to be kept on then
PM core should make them as such, not driver.
>
> And if it is OK for a driver to set IRQF_SHARED, it is equally OK for it to
> set IRQF_NO_SUSPEND, because, in fact, those two flags are related.
Are you proposing for IRQ core to automatically set IRQF_NO_SUSPEND for
IRQF_SHARED interrupts? That wold be fine with me.
>
> > If you look at the earlier patch discussion Tegra folks managed to implement
> > this behavior just fine.
>
> I'm not sure whose idea it was that IRQF_NO_SUSPEND was not to be set by drivers,
> but it is not a correct one. I know why suspend_device_irqs() was introduced
> and I'm telling you this has nothing to do with setting up the IRQ chip to do
> system wakeup.
I do not believe I asked why suspend_device_irqs() was introduced.
>
> And please grep for IRQF_NO_SUSPEND to see how drivers generally use it.
I see that just handful of them use IRQF_NO_SUSPEND (not sure how many
are actully required), I see that a lot more drivers use
enable_irq_wake() and do not bother setting IRQF_NO_SUSPEND.
Thanks.
--
Dmitry
On Tuesday, July 08, 2014 03:11:14 PM Dmitry Torokhov wrote:
> On Tue, Jul 08, 2014 at 11:47:01PM +0200, Rafael J. Wysocki wrote:
> > On Tuesday, July 08, 2014 02:12:59 PM Dmitry Torokhov wrote:
> > > On Tue, Jul 08, 2014 at 11:06:17PM +0200, Rafael J. Wysocki wrote:
> > > > On Tuesday, July 08, 2014 01:45:30 PM Dmitry Torokhov wrote:
> > > > > On Tue, Jul 08, 2014 at 10:52:52PM +0200, Rafael J. Wysocki wrote:
> > > > > > On Thursday, June 19, 2014 08:51:25 AM Li, Aubrey wrote:
> > > > > > > When the wakeup attribute is set, the GPIO button is capable of
> > > > > > > waking up the system from sleep states, including the "freeze"
> > > > > > > sleep state. For that to work, its driver needs to pass the
> > > > > > > IRQF_NO_SUSPEND flag to devm_request_any_context_irq(), or the
> > > > > > > interrupt will be disabled by suspend_device_irqs() and the
> > > > > > > system won't be woken up by it from the "freeze" sleep state.
> > > > > > >
> > > > > > > The suspend_device_irqs() routine is a workaround for drivers
> > > > > > > that mishandle interrupts triggered when the devices handled
> > > > > > > by them are suspended, so it is safe to use IRQF_NO_SUSPEND in
> > > > > > > all drivers that don't have that problem.
> > > > > > >
> > > > > > > The affected/tested machines include Dell Venue 11 Pro and Asus T100TA.
> > > > > > >
> > > > > > > Signed-off-by: Aubrey Li <[email protected]>
> > > > > > > Reviewed-by: Rafael J. Wysocki <[email protected]>
> > > > > >
> > > > > > OK
> > > > > >
> > > > > > Due to the lack of response (ie. no objections) and because the issue
> > > > > > addressed by this patch is real, I'm queuing it up as a PM-related fix
> > > > > > for 3.17.
> > > > >
> > > > > Please do not. The response is till the same: board code should make sure
> > > > > that enable_irq_wake() does the right thing and keeps interrupts enabled.
> > > >
> > > > Which board code? That's nothing like that for the platforms in question.
> > >
> > > Then it needs to be written.
> >
> > Well, excuse me, but I don't get it. Why would I need to write any board code
> > for an ACPI-based system?
>
> Why would not you? What is the difference between ACPI systems and all
> other systems? If ACPI-based systems need certain behavior they need to
> implement it, the same as DT-based systems or custom boards.
I'm not sure what you're talking about.
This isn't an ACPI-based system that needs certain behavior. That's certain
behavior we want from GPIO buttons that can wake up *in* *general*.
Regardless of the platform, we want interrupts from those buttons to happen
after calling suspend_device_irqs(). Why? Because we want them to be able
to happen while freeze_enter() is being executed and *that* is platform
independent.
> > > > > It is wrong to patch drivers for this.
> > > >
> > > > Why is it? Only drivers know if they can handle incoming interrupts after
> > > > having suspended their devices.
> > >
> > > The driver correctly used enable_irq_wake() to indicate that interrupt should
> > > be a wakeup source, the now the core/board needs to make sure the interrupt
> > > gets delivered to the driver properly. We should not be patching every driver
> > > that uses enable_irq_wake() with IRQF_NO_SUSPEND.
> >
> > Interrupts that can wake up from the "freeze" sleep state need not be set up
> > with enable_irq_wake() and the flag doesn't say "this is a wakeup interrupt".
> > It says "do not suspend this interrupt, I can handle it after the device has
> > been suspended" (as I said).
>
> And the driver does not really care about this and whether the sleep
> state is suspend or freeze or something else, it is your platform that
> cares and has certain limitations that require interrupts to be not
> suspended in certain cases.
Not in "certain cases", but actually never and it is not about any platform
limitations. I'm not sure what other words I need to use to make it more
clear.
> From the driver POV it says that the device can be a waekup source
> (again it does not care about details as to which sleep state we woudl
> be waking from) and it expects the PM core to handle the things
> properly. If certain sleep state requires interrupts to be kept on then
> PM core should make them as such, not driver.
That would be the case in an ideal world, but the real one is not ideal,
unfortunately. The problem is that the PM core actually cannot decide
which interrupts to keep on, because it doesn't know which drivers can
cope with interrupts that happen after their devices have been suspended.
Using IRQF_NO_SUSPEND is the way to experess that by a driver.
And again, that has nothing to do with platform limitations or requirements.
All this is about is whether or not to allow interrupts to be *handled* by
drivers after certain point in the suspend sequence, which is
suspend_device_irqs(). By using IRQF_NO_SUSPEND drivers say, basically "it is
OK to leave this IRQ as is, I promise to take care of it going forward" and
that covers *all* suspend/hibernate transitions.
The reason why the "freeze" sleep state is somewhat special is that it doesn't
do any platform-specific magic and needs *normal* device interrupts to work
after suspend_device_irqs(). And I would *love* *to* drop suspend_device_irqs()
at this point, but I can't, because there still are drivers that would have
broken had I done that.
And I'm saying "somewhat" above, because that behavior is actually needed to
prevent wakeup events occuring *during* suspend transitions from being lost
for all kinds of those transitions (if someone actually cares).
> >
> > And if it is OK for a driver to set IRQF_SHARED, it is equally OK for it to
> > set IRQF_NO_SUSPEND, because, in fact, those two flags are related.
>
> Are you proposing for IRQ core to automatically set IRQF_NO_SUSPEND for
> IRQF_SHARED interrupts? That wold be fine with me.
No, I'm not.
The first choice basically is to go through all drivers that don't use IRQF_NO_SUSPEND
and which have _noirq suspend callbacks (that covers all PCI drivers and some
non-PCI ones too IIRC) and audit their interrupt handlers to check whether or not
they can cope with interrupts coming after their devices have been suspended. Fix
the ones that can't and we can drop suspend_device_irqs().
But I guess I may be forgiven for regarding that as rather unattractive. And we
actually could have done that to start with, guess why we didn't?
The second choice is to use IRQF_NO_SUSPEND in the drivers that are OK. That
isn't too attractive either but has been practice for quite a while.
> > > If you look at the earlier patch discussion Tegra folks managed to implement
> > > this behavior just fine.
> >
> > I'm not sure whose idea it was that IRQF_NO_SUSPEND was not to be set by drivers,
> > but it is not a correct one. I know why suspend_device_irqs() was introduced
> > and I'm telling you this has nothing to do with setting up the IRQ chip to do
> > system wakeup.
>
> I do not believe I asked why suspend_device_irqs() was introduced.
But you should, because suspend_device_irqs() is the very reason why
IRQF_NO_SUSPEND exists. :-)
> >
> > And please grep for IRQF_NO_SUSPEND to see how drivers generally use it.
>
> I see that just handful of them use IRQF_NO_SUSPEND (not sure how many
> are actully required), I see that a lot more drivers use
> enable_irq_wake() and do not bother setting IRQF_NO_SUSPEND.
And they will have problems with the "freeze" sleep state.
enable_irq_wake() is *not* a replacement for IRQF_NO_SUSPEND, nor the other
way around. They are different things.
Rafael
On Wed, Jul 09, 2014 at 01:06:07AM +0200, Rafael J. Wysocki wrote:
> On Tuesday, July 08, 2014 03:11:14 PM Dmitry Torokhov wrote:
> > On Tue, Jul 08, 2014 at 11:47:01PM +0200, Rafael J. Wysocki wrote:
> > > On Tuesday, July 08, 2014 02:12:59 PM Dmitry Torokhov wrote:
> > > > On Tue, Jul 08, 2014 at 11:06:17PM +0200, Rafael J. Wysocki wrote:
> > > > > On Tuesday, July 08, 2014 01:45:30 PM Dmitry Torokhov wrote:
> > > > > > On Tue, Jul 08, 2014 at 10:52:52PM +0200, Rafael J. Wysocki wrote:
> > > > > > > On Thursday, June 19, 2014 08:51:25 AM Li, Aubrey wrote:
> > > > > > > > When the wakeup attribute is set, the GPIO button is capable of
> > > > > > > > waking up the system from sleep states, including the "freeze"
> > > > > > > > sleep state. For that to work, its driver needs to pass the
> > > > > > > > IRQF_NO_SUSPEND flag to devm_request_any_context_irq(), or the
> > > > > > > > interrupt will be disabled by suspend_device_irqs() and the
> > > > > > > > system won't be woken up by it from the "freeze" sleep state.
> > > > > > > >
> > > > > > > > The suspend_device_irqs() routine is a workaround for drivers
> > > > > > > > that mishandle interrupts triggered when the devices handled
> > > > > > > > by them are suspended, so it is safe to use IRQF_NO_SUSPEND in
> > > > > > > > all drivers that don't have that problem.
> > > > > > > >
> > > > > > > > The affected/tested machines include Dell Venue 11 Pro and Asus T100TA.
> > > > > > > >
> > > > > > > > Signed-off-by: Aubrey Li <[email protected]>
> > > > > > > > Reviewed-by: Rafael J. Wysocki <[email protected]>
> > > > > > >
> > > > > > > OK
> > > > > > >
> > > > > > > Due to the lack of response (ie. no objections) and because the issue
> > > > > > > addressed by this patch is real, I'm queuing it up as a PM-related fix
> > > > > > > for 3.17.
> > > > > >
> > > > > > Please do not. The response is till the same: board code should make sure
> > > > > > that enable_irq_wake() does the right thing and keeps interrupts enabled.
> > > > >
> > > > > Which board code? That's nothing like that for the platforms in question.
> > > >
> > > > Then it needs to be written.
> > >
> > > Well, excuse me, but I don't get it. Why would I need to write any board code
> > > for an ACPI-based system?
> >
> > Why would not you? What is the difference between ACPI systems and all
> > other systems? If ACPI-based systems need certain behavior they need to
> > implement it, the same as DT-based systems or custom boards.
>
> I'm not sure what you're talking about.
>
> This isn't an ACPI-based system that needs certain behavior. That's certain
> behavior we want from GPIO buttons that can wake up *in* *general*.
>
> Regardless of the platform, we want interrupts from those buttons to happen
> after calling suspend_device_irqs(). Why? Because we want them to be able
> to happen while freeze_enter() is being executed and *that* is platform
> independent.
Tell me this: do we always call suspend_device_irqs()?
>
> > > > > > It is wrong to patch drivers for this.
> > > > >
> > > > > Why is it? Only drivers know if they can handle incoming interrupts after
> > > > > having suspended their devices.
> > > >
> > > > The driver correctly used enable_irq_wake() to indicate that interrupt should
> > > > be a wakeup source, the now the core/board needs to make sure the interrupt
> > > > gets delivered to the driver properly. We should not be patching every driver
> > > > that uses enable_irq_wake() with IRQF_NO_SUSPEND.
> > >
> > > Interrupts that can wake up from the "freeze" sleep state need not be set up
> > > with enable_irq_wake() and the flag doesn't say "this is a wakeup interrupt".
> > > It says "do not suspend this interrupt, I can handle it after the device has
> > > been suspended" (as I said).
> >
> > And the driver does not really care about this and whether the sleep
> > state is suspend or freeze or something else, it is your platform that
> > cares and has certain limitations that require interrupts to be not
> > suspended in certain cases.
>
> Not in "certain cases", but actually never and it is not about any platform
> limitations. I'm not sure what other words I need to use to make it more
> clear.
>
> > From the driver POV it says that the device can be a waekup source
> > (again it does not care about details as to which sleep state we woudl
> > be waking from) and it expects the PM core to handle the things
> > properly. If certain sleep state requires interrupts to be kept on then
> > PM core should make them as such, not driver.
>
> That would be the case in an ideal world, but the real one is not ideal,
> unfortunately. The problem is that the PM core actually cannot decide
> which interrupts to keep on, because it doesn't know which drivers can
> cope with interrupts that happen after their devices have been suspended.
> Using IRQF_NO_SUSPEND is the way to experess that by a driver.
When device driver marks IRQ as a wakeup source I believe it is prepared
to handle it (or it would shut it off explicitly).
>
> And again, that has nothing to do with platform limitations or requirements.
> All this is about is whether or not to allow interrupts to be *handled* by
> drivers after certain point in the suspend sequence, which is
> suspend_device_irqs(). By using IRQF_NO_SUSPEND drivers say, basically "it is
> OK to leave this IRQ as is, I promise to take care of it going forward" and
> that covers *all* suspend/hibernate transitions.
>
> The reason why the "freeze" sleep state is somewhat special is that it doesn't
> do any platform-specific magic and needs *normal* device interrupts to work
> after suspend_device_irqs(). And I would *love* *to* drop suspend_device_irqs()
> at this point, but I can't, because there still are drivers that would have
> broken had I done that.
>
> And I'm saying "somewhat" above, because that behavior is actually needed to
> prevent wakeup events occuring *during* suspend transitions from being lost
> for all kinds of those transitions (if someone actually cares).
>
> > >
> > > And if it is OK for a driver to set IRQF_SHARED, it is equally OK for it to
> > > set IRQF_NO_SUSPEND, because, in fact, those two flags are related.
> >
> > Are you proposing for IRQ core to automatically set IRQF_NO_SUSPEND for
> > IRQF_SHARED interrupts? That wold be fine with me.
>
> No, I'm not.
Then they are not really related that closely, are they?
>
> The first choice basically is to go through all drivers that don't use IRQF_NO_SUSPEND
> and which have _noirq suspend callbacks (that covers all PCI drivers and some
> non-PCI ones too IIRC) and audit their interrupt handlers to check whether or not
> they can cope with interrupts coming after their devices have been suspended. Fix
> the ones that can't and we can drop suspend_device_irqs().
>
> But I guess I may be forgiven for regarding that as rather unattractive. And we
> actually could have done that to start with, guess why we didn't?
>
> The second choice is to use IRQF_NO_SUSPEND in the drivers that are OK. That
> isn't too attractive either but has been practice for quite a while.
>
> > > > If you look at the earlier patch discussion Tegra folks managed to implement
> > > > this behavior just fine.
> > >
> > > I'm not sure whose idea it was that IRQF_NO_SUSPEND was not to be set by drivers,
> > > but it is not a correct one. I know why suspend_device_irqs() was introduced
> > > and I'm telling you this has nothing to do with setting up the IRQ chip to do
> > > system wakeup.
> >
> > I do not believe I asked why suspend_device_irqs() was introduced.
>
> But you should, because suspend_device_irqs() is the very reason why
> IRQF_NO_SUSPEND exists. :-)
Then you should have shared this knowledge instead of asserting that you
possess it.
>
> > >
> > > And please grep for IRQF_NO_SUSPEND to see how drivers generally use it.
> >
> > I see that just handful of them use IRQF_NO_SUSPEND (not sure how many
> > are actully required), I see that a lot more drivers use
> > enable_irq_wake() and do not bother setting IRQF_NO_SUSPEND.
>
> And they will have problems with the "freeze" sleep state.
>
> enable_irq_wake() is *not* a replacement for IRQF_NO_SUSPEND, nor the other
> way around. They are different things.
However what I hear is that one has to use one when using another, and
form this fact comes my request: when entering freeze sleep state
interrupts that are marked as wakeup sources should be automatically
excluded form the list of IRQs that need to be suspended.
Thanks.
--
Dmitry
On Tuesday, July 08, 2014 05:15:06 PM Dmitry Torokhov wrote:
> On Wed, Jul 09, 2014 at 01:06:07AM +0200, Rafael J. Wysocki wrote:
> > On Tuesday, July 08, 2014 03:11:14 PM Dmitry Torokhov wrote:
> > > On Tue, Jul 08, 2014 at 11:47:01PM +0200, Rafael J. Wysocki wrote:
> > > > On Tuesday, July 08, 2014 02:12:59 PM Dmitry Torokhov wrote:
> > > > > On Tue, Jul 08, 2014 at 11:06:17PM +0200, Rafael J. Wysocki wrote:
> > > > > > On Tuesday, July 08, 2014 01:45:30 PM Dmitry Torokhov wrote:
> > > > > > > On Tue, Jul 08, 2014 at 10:52:52PM +0200, Rafael J. Wysocki wrote:
> > > > > > > > On Thursday, June 19, 2014 08:51:25 AM Li, Aubrey wrote:
> > > > > > > > > When the wakeup attribute is set, the GPIO button is capable of
> > > > > > > > > waking up the system from sleep states, including the "freeze"
> > > > > > > > > sleep state. For that to work, its driver needs to pass the
> > > > > > > > > IRQF_NO_SUSPEND flag to devm_request_any_context_irq(), or the
> > > > > > > > > interrupt will be disabled by suspend_device_irqs() and the
> > > > > > > > > system won't be woken up by it from the "freeze" sleep state.
> > > > > > > > >
> > > > > > > > > The suspend_device_irqs() routine is a workaround for drivers
> > > > > > > > > that mishandle interrupts triggered when the devices handled
> > > > > > > > > by them are suspended, so it is safe to use IRQF_NO_SUSPEND in
> > > > > > > > > all drivers that don't have that problem.
> > > > > > > > >
> > > > > > > > > The affected/tested machines include Dell Venue 11 Pro and Asus T100TA.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Aubrey Li <[email protected]>
> > > > > > > > > Reviewed-by: Rafael J. Wysocki <[email protected]>
> > > > > > > >
> > > > > > > > OK
> > > > > > > >
> > > > > > > > Due to the lack of response (ie. no objections) and because the issue
> > > > > > > > addressed by this patch is real, I'm queuing it up as a PM-related fix
> > > > > > > > for 3.17.
> > > > > > >
> > > > > > > Please do not. The response is till the same: board code should make sure
> > > > > > > that enable_irq_wake() does the right thing and keeps interrupts enabled.
> > > > > >
> > > > > > Which board code? That's nothing like that for the platforms in question.
> > > > >
> > > > > Then it needs to be written.
> > > >
> > > > Well, excuse me, but I don't get it. Why would I need to write any board code
> > > > for an ACPI-based system?
> > >
> > > Why would not you? What is the difference between ACPI systems and all
> > > other systems? If ACPI-based systems need certain behavior they need to
> > > implement it, the same as DT-based systems or custom boards.
> >
> > I'm not sure what you're talking about.
> >
> > This isn't an ACPI-based system that needs certain behavior. That's certain
> > behavior we want from GPIO buttons that can wake up *in* *general*.
> >
> > Regardless of the platform, we want interrupts from those buttons to happen
> > after calling suspend_device_irqs(). Why? Because we want them to be able
> > to happen while freeze_enter() is being executed and *that* is platform
> > independent.
>
> Tell me this: do we always call suspend_device_irqs()?
Yes, we do.
> > > > > > > It is wrong to patch drivers for this.
> > > > > >
> > > > > > Why is it? Only drivers know if they can handle incoming interrupts after
> > > > > > having suspended their devices.
> > > > >
> > > > > The driver correctly used enable_irq_wake() to indicate that interrupt should
> > > > > be a wakeup source, the now the core/board needs to make sure the interrupt
> > > > > gets delivered to the driver properly. We should not be patching every driver
> > > > > that uses enable_irq_wake() with IRQF_NO_SUSPEND.
> > > >
> > > > Interrupts that can wake up from the "freeze" sleep state need not be set up
> > > > with enable_irq_wake() and the flag doesn't say "this is a wakeup interrupt".
> > > > It says "do not suspend this interrupt, I can handle it after the device has
> > > > been suspended" (as I said).
> > >
> > > And the driver does not really care about this and whether the sleep
> > > state is suspend or freeze or something else, it is your platform that
> > > cares and has certain limitations that require interrupts to be not
> > > suspended in certain cases.
> >
> > Not in "certain cases", but actually never and it is not about any platform
> > limitations. I'm not sure what other words I need to use to make it more
> > clear.
> >
> > > From the driver POV it says that the device can be a waekup source
> > > (again it does not care about details as to which sleep state we woudl
> > > be waking from) and it expects the PM core to handle the things
> > > properly. If certain sleep state requires interrupts to be kept on then
> > > PM core should make them as such, not driver.
> >
> > That would be the case in an ideal world, but the real one is not ideal,
> > unfortunately. The problem is that the PM core actually cannot decide
> > which interrupts to keep on, because it doesn't know which drivers can
> > cope with interrupts that happen after their devices have been suspended.
> > Using IRQF_NO_SUSPEND is the way to experess that by a driver.
>
> When device driver marks IRQ as a wakeup source I believe it is prepared
> to handle it (or it would shut it off explicitly).
I can agree with that.
Are you suggesting that __disable_irq() should check irq_data for
IRQD_WAKEUP_STATE and skip the IRQ (in the 'suspend' case) if that is set?
That might work too.
> > And again, that has nothing to do with platform limitations or requirements.
> > All this is about is whether or not to allow interrupts to be *handled* by
> > drivers after certain point in the suspend sequence, which is
> > suspend_device_irqs(). By using IRQF_NO_SUSPEND drivers say, basically "it is
> > OK to leave this IRQ as is, I promise to take care of it going forward" and
> > that covers *all* suspend/hibernate transitions.
> >
> > The reason why the "freeze" sleep state is somewhat special is that it doesn't
> > do any platform-specific magic and needs *normal* device interrupts to work
> > after suspend_device_irqs(). And I would *love* *to* drop suspend_device_irqs()
> > at this point, but I can't, because there still are drivers that would have
> > broken had I done that.
> >
> > And I'm saying "somewhat" above, because that behavior is actually needed to
> > prevent wakeup events occuring *during* suspend transitions from being lost
> > for all kinds of those transitions (if someone actually cares).
> >
> > > >
> > > > And if it is OK for a driver to set IRQF_SHARED, it is equally OK for it to
> > > > set IRQF_NO_SUSPEND, because, in fact, those two flags are related.
> > >
> > > Are you proposing for IRQ core to automatically set IRQF_NO_SUSPEND for
> > > IRQF_SHARED interrupts? That wold be fine with me.
> >
> > No, I'm not.
>
> Then they are not really related that closely, are they?
Yes, they are. The original underlying problem was that some drivers with
IRQF_SHARED set mishandled interrupts triggered by the other device sharing the
IRQ line (so they did not expect the interrupt to trigger at that point, but it did).
> > The first choice basically is to go through all drivers that don't use IRQF_NO_SUSPEND
> > and which have _noirq suspend callbacks (that covers all PCI drivers and some
> > non-PCI ones too IIRC) and audit their interrupt handlers to check whether or not
> > they can cope with interrupts coming after their devices have been suspended. Fix
> > the ones that can't and we can drop suspend_device_irqs().
> >
> > But I guess I may be forgiven for regarding that as rather unattractive. And we
> > actually could have done that to start with, guess why we didn't?
> >
> > The second choice is to use IRQF_NO_SUSPEND in the drivers that are OK. That
> > isn't too attractive either but has been practice for quite a while.
> >
> > > > > If you look at the earlier patch discussion Tegra folks managed to implement
> > > > > this behavior just fine.
> > > >
> > > > I'm not sure whose idea it was that IRQF_NO_SUSPEND was not to be set by drivers,
> > > > but it is not a correct one. I know why suspend_device_irqs() was introduced
> > > > and I'm telling you this has nothing to do with setting up the IRQ chip to do
> > > > system wakeup.
> > >
> > > I do not believe I asked why suspend_device_irqs() was introduced.
> >
> > But you should, because suspend_device_irqs() is the very reason why
> > IRQF_NO_SUSPEND exists. :-)
>
> Then you should have shared this knowledge instead of asserting that you
> possess it.
Well, I just thought you knew that too.
> > > >
> > > > And please grep for IRQF_NO_SUSPEND to see how drivers generally use it.
> > >
> > > I see that just handful of them use IRQF_NO_SUSPEND (not sure how many
> > > are actully required), I see that a lot more drivers use
> > > enable_irq_wake() and do not bother setting IRQF_NO_SUSPEND.
> >
> > And they will have problems with the "freeze" sleep state.
> >
> > enable_irq_wake() is *not* a replacement for IRQF_NO_SUSPEND, nor the other
> > way around. They are different things.
>
> However what I hear is that one has to use one when using another, and
> form this fact comes my request:
That isn't exactly the case. IRQF_NO_SUSPEND need not imply enable_irq_wake().
> when entering freeze sleep state
> interrupts that are marked as wakeup sources should be automatically
> excluded form the list of IRQs that need to be suspended.
That seems to be the case for all sleep states, doesn't it?
Rafael
On Wed, Jul 09, 2014 at 02:59:33AM +0200, Rafael J. Wysocki wrote:
> On Tuesday, July 08, 2014 05:15:06 PM Dmitry Torokhov wrote:
> > On Wed, Jul 09, 2014 at 01:06:07AM +0200, Rafael J. Wysocki wrote:
> > > On Tuesday, July 08, 2014 03:11:14 PM Dmitry Torokhov wrote:
> > > > On Tue, Jul 08, 2014 at 11:47:01PM +0200, Rafael J. Wysocki wrote:
> > > > > On Tuesday, July 08, 2014 02:12:59 PM Dmitry Torokhov wrote:
> > > > > > On Tue, Jul 08, 2014 at 11:06:17PM +0200, Rafael J. Wysocki wrote:
> > > > > > > On Tuesday, July 08, 2014 01:45:30 PM Dmitry Torokhov wrote:
> > > > > > > > On Tue, Jul 08, 2014 at 10:52:52PM +0200, Rafael J. Wysocki wrote:
> > > > > > > > > On Thursday, June 19, 2014 08:51:25 AM Li, Aubrey wrote:
> > > > > > > > > > When the wakeup attribute is set, the GPIO button is capable of
> > > > > > > > > > waking up the system from sleep states, including the "freeze"
> > > > > > > > > > sleep state. For that to work, its driver needs to pass the
> > > > > > > > > > IRQF_NO_SUSPEND flag to devm_request_any_context_irq(), or the
> > > > > > > > > > interrupt will be disabled by suspend_device_irqs() and the
> > > > > > > > > > system won't be woken up by it from the "freeze" sleep state.
> > > > > > > > > >
> > > > > > > > > > The suspend_device_irqs() routine is a workaround for drivers
> > > > > > > > > > that mishandle interrupts triggered when the devices handled
> > > > > > > > > > by them are suspended, so it is safe to use IRQF_NO_SUSPEND in
> > > > > > > > > > all drivers that don't have that problem.
> > > > > > > > > >
> > > > > > > > > > The affected/tested machines include Dell Venue 11 Pro and Asus T100TA.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Aubrey Li <[email protected]>
> > > > > > > > > > Reviewed-by: Rafael J. Wysocki <[email protected]>
> > > > > > > > >
> > > > > > > > > OK
> > > > > > > > >
> > > > > > > > > Due to the lack of response (ie. no objections) and because the issue
> > > > > > > > > addressed by this patch is real, I'm queuing it up as a PM-related fix
> > > > > > > > > for 3.17.
> > > > > > > >
> > > > > > > > Please do not. The response is till the same: board code should make sure
> > > > > > > > that enable_irq_wake() does the right thing and keeps interrupts enabled.
> > > > > > >
> > > > > > > Which board code? That's nothing like that for the platforms in question.
> > > > > >
> > > > > > Then it needs to be written.
> > > > >
> > > > > Well, excuse me, but I don't get it. Why would I need to write any board code
> > > > > for an ACPI-based system?
> > > >
> > > > Why would not you? What is the difference between ACPI systems and all
> > > > other systems? If ACPI-based systems need certain behavior they need to
> > > > implement it, the same as DT-based systems or custom boards.
> > >
> > > I'm not sure what you're talking about.
> > >
> > > This isn't an ACPI-based system that needs certain behavior. That's certain
> > > behavior we want from GPIO buttons that can wake up *in* *general*.
> > >
> > > Regardless of the platform, we want interrupts from those buttons to happen
> > > after calling suspend_device_irqs(). Why? Because we want them to be able
> > > to happen while freeze_enter() is being executed and *that* is platform
> > > independent.
> >
> > Tell me this: do we always call suspend_device_irqs()?
>
> Yes, we do.
OK, I see.
>
> > > > > > > > It is wrong to patch drivers for this.
> > > > > > >
> > > > > > > Why is it? Only drivers know if they can handle incoming interrupts after
> > > > > > > having suspended their devices.
> > > > > >
> > > > > > The driver correctly used enable_irq_wake() to indicate that interrupt should
> > > > > > be a wakeup source, the now the core/board needs to make sure the interrupt
> > > > > > gets delivered to the driver properly. We should not be patching every driver
> > > > > > that uses enable_irq_wake() with IRQF_NO_SUSPEND.
> > > > >
> > > > > Interrupts that can wake up from the "freeze" sleep state need not be set up
> > > > > with enable_irq_wake() and the flag doesn't say "this is a wakeup interrupt".
> > > > > It says "do not suspend this interrupt, I can handle it after the device has
> > > > > been suspended" (as I said).
> > > >
> > > > And the driver does not really care about this and whether the sleep
> > > > state is suspend or freeze or something else, it is your platform that
> > > > cares and has certain limitations that require interrupts to be not
> > > > suspended in certain cases.
> > >
> > > Not in "certain cases", but actually never and it is not about any platform
> > > limitations. I'm not sure what other words I need to use to make it more
> > > clear.
> > >
> > > > From the driver POV it says that the device can be a waekup source
> > > > (again it does not care about details as to which sleep state we woudl
> > > > be waking from) and it expects the PM core to handle the things
> > > > properly. If certain sleep state requires interrupts to be kept on then
> > > > PM core should make them as such, not driver.
> > >
> > > That would be the case in an ideal world, but the real one is not ideal,
> > > unfortunately. The problem is that the PM core actually cannot decide
> > > which interrupts to keep on, because it doesn't know which drivers can
> > > cope with interrupts that happen after their devices have been suspended.
> > > Using IRQF_NO_SUSPEND is the way to experess that by a driver.
> >
> > When device driver marks IRQ as a wakeup source I believe it is prepared
> > to handle it (or it would shut it off explicitly).
>
> I can agree with that.
>
> Are you suggesting that __disable_irq() should check irq_data for
> IRQD_WAKEUP_STATE and skip the IRQ (in the 'suspend' case) if that is set?
Yes, something like that.
>
> That might work too.
>
> > > And again, that has nothing to do with platform limitations or requirements.
> > > All this is about is whether or not to allow interrupts to be *handled* by
> > > drivers after certain point in the suspend sequence, which is
> > > suspend_device_irqs(). By using IRQF_NO_SUSPEND drivers say, basically "it is
> > > OK to leave this IRQ as is, I promise to take care of it going forward" and
> > > that covers *all* suspend/hibernate transitions.
> > >
> > > The reason why the "freeze" sleep state is somewhat special is that it doesn't
> > > do any platform-specific magic and needs *normal* device interrupts to work
> > > after suspend_device_irqs(). And I would *love* *to* drop suspend_device_irqs()
> > > at this point, but I can't, because there still are drivers that would have
> > > broken had I done that.
> > >
> > > And I'm saying "somewhat" above, because that behavior is actually needed to
> > > prevent wakeup events occuring *during* suspend transitions from being lost
> > > for all kinds of those transitions (if someone actually cares).
> > >
> > > > >
> > > > > And if it is OK for a driver to set IRQF_SHARED, it is equally OK for it to
> > > > > set IRQF_NO_SUSPEND, because, in fact, those two flags are related.
> > > >
> > > > Are you proposing for IRQ core to automatically set IRQF_NO_SUSPEND for
> > > > IRQF_SHARED interrupts? That wold be fine with me.
> > >
> > > No, I'm not.
> >
> > Then they are not really related that closely, are they?
>
> Yes, they are. The original underlying problem was that some drivers with
> IRQF_SHARED set mishandled interrupts triggered by the other device sharing the
> IRQ line (so they did not expect the interrupt to trigger at that point, but it did).
Right, well-behaved driver using IRQF_SHARED should expect IRQ at any
time, even if the device supposed to be quiesced at the time. But I
guess we are still not comfortable setting IRQF_NO_SUSPEND even though
it should be OK.
>
> > > The first choice basically is to go through all drivers that don't use IRQF_NO_SUSPEND
> > > and which have _noirq suspend callbacks (that covers all PCI drivers and some
> > > non-PCI ones too IIRC) and audit their interrupt handlers to check whether or not
> > > they can cope with interrupts coming after their devices have been suspended. Fix
> > > the ones that can't and we can drop suspend_device_irqs().
> > >
> > > But I guess I may be forgiven for regarding that as rather unattractive. And we
> > > actually could have done that to start with, guess why we didn't?
> > >
> > > The second choice is to use IRQF_NO_SUSPEND in the drivers that are OK. That
> > > isn't too attractive either but has been practice for quite a while.
> > >
> > > > > > If you look at the earlier patch discussion Tegra folks managed to implement
> > > > > > this behavior just fine.
> > > > >
> > > > > I'm not sure whose idea it was that IRQF_NO_SUSPEND was not to be set by drivers,
> > > > > but it is not a correct one. I know why suspend_device_irqs() was introduced
> > > > > and I'm telling you this has nothing to do with setting up the IRQ chip to do
> > > > > system wakeup.
> > > >
> > > > I do not believe I asked why suspend_device_irqs() was introduced.
> > >
> > > But you should, because suspend_device_irqs() is the very reason why
> > > IRQF_NO_SUSPEND exists. :-)
> >
> > Then you should have shared this knowledge instead of asserting that you
> > possess it.
>
> Well, I just thought you knew that too.
>
> > > > >
> > > > > And please grep for IRQF_NO_SUSPEND to see how drivers generally use it.
> > > >
> > > > I see that just handful of them use IRQF_NO_SUSPEND (not sure how many
> > > > are actully required), I see that a lot more drivers use
> > > > enable_irq_wake() and do not bother setting IRQF_NO_SUSPEND.
> > >
> > > And they will have problems with the "freeze" sleep state.
> > >
> > > enable_irq_wake() is *not* a replacement for IRQF_NO_SUSPEND, nor the other
> > > way around. They are different things.
> >
> > However what I hear is that one has to use one when using another, and
> > form this fact comes my request:
>
> That isn't exactly the case. IRQF_NO_SUSPEND need not imply enable_irq_wake().
Right, but I am hoping that enable_irq_wake() can imply IRQF_NO_SUSPEND.
>
> > when entering freeze sleep state
> > interrupts that are marked as wakeup sources should be automatically
> > excluded form the list of IRQs that need to be suspended.
>
> That seems to be the case for all sleep states, doesn't it?
I was under impression that some of sleep paths were skipping freezer.
If not then they all need this.
Thanks.
--
Dmitry
On Tuesday, July 08, 2014 05:54:35 PM Dmitry Torokhov wrote:
> On Wed, Jul 09, 2014 at 02:59:33AM +0200, Rafael J. Wysocki wrote:
> > On Tuesday, July 08, 2014 05:15:06 PM Dmitry Torokhov wrote:
> > > On Wed, Jul 09, 2014 at 01:06:07AM +0200, Rafael J. Wysocki wrote:
[cut]
> > >
> > > When device driver marks IRQ as a wakeup source I believe it is prepared
> > > to handle it (or it would shut it off explicitly).
> >
> > I can agree with that.
> >
> > Are you suggesting that __disable_irq() should check irq_data for
> > IRQD_WAKEUP_STATE and skip the IRQ (in the 'suspend' case) if that is set?
>
> Yes, something like that.
OK
Aubrey, can you please check if the appended patch helps on the T100?
Rafael
---
kernel/irq/manage.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-pm/kernel/irq/manage.c
===================================================================
--- linux-pm.orig/kernel/irq/manage.c
+++ linux-pm/kernel/irq/manage.c
@@ -385,7 +385,8 @@ setup_affinity(unsigned int irq, struct
void __disable_irq(struct irq_desc *desc, unsigned int irq, bool suspend)
{
if (suspend) {
- if (!desc->action || (desc->action->flags & IRQF_NO_SUSPEND))
+ if (!desc->action || (desc->action->flags & IRQF_NO_SUSPEND)
+ || irqd_has_set(&desc->irq_data, IRQD_WAKEUP_STATE))
return;
desc->istate |= IRQS_SUSPENDED;
}
On 2014/7/9 20:45, Rafael J. Wysocki wrote:
> On Tuesday, July 08, 2014 05:54:35 PM Dmitry Torokhov wrote:
>> On Wed, Jul 09, 2014 at 02:59:33AM +0200, Rafael J. Wysocki wrote:
>>> On Tuesday, July 08, 2014 05:15:06 PM Dmitry Torokhov wrote:
>>>> On Wed, Jul 09, 2014 at 01:06:07AM +0200, Rafael J. Wysocki wrote:
>
> [cut]
>
>>>>
>>>> When device driver marks IRQ as a wakeup source I believe it is prepared
>>>> to handle it (or it would shut it off explicitly).
>>>
>>> I can agree with that.
>>>
>>> Are you suggesting that __disable_irq() should check irq_data for
>>> IRQD_WAKEUP_STATE and skip the IRQ (in the 'suspend' case) if that is set?
>>
>> Yes, something like that.
>
> OK
Many thanks to you both for the discussion.
>
> Aubrey, can you please check if the appended patch helps on the T100?
I verified this patch on T100, it works as expected, freeze can be waken
up by reverting my patch and applying this one.
Is this a final solution?
Thanks,
-Aubrey
>
> Rafael
>
> ---
> kernel/irq/manage.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> Index: linux-pm/kernel/irq/manage.c
> ===================================================================
> --- linux-pm.orig/kernel/irq/manage.c
> +++ linux-pm/kernel/irq/manage.c
> @@ -385,7 +385,8 @@ setup_affinity(unsigned int irq, struct
> void __disable_irq(struct irq_desc *desc, unsigned int irq, bool suspend)
> {
> if (suspend) {
> - if (!desc->action || (desc->action->flags & IRQF_NO_SUSPEND))
> + if (!desc->action || (desc->action->flags & IRQF_NO_SUSPEND)
> + || irqd_has_set(&desc->irq_data, IRQD_WAKEUP_STATE))
> return;
> desc->istate |= IRQS_SUSPENDED;
> }
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
On Thursday, July 10, 2014 10:27:46 AM Li, Aubrey wrote:
> On 2014/7/9 20:45, Rafael J. Wysocki wrote:
> > On Tuesday, July 08, 2014 05:54:35 PM Dmitry Torokhov wrote:
> >> On Wed, Jul 09, 2014 at 02:59:33AM +0200, Rafael J. Wysocki wrote:
> >>> On Tuesday, July 08, 2014 05:15:06 PM Dmitry Torokhov wrote:
> >>>> On Wed, Jul 09, 2014 at 01:06:07AM +0200, Rafael J. Wysocki wrote:
> >
> > [cut]
> >
> >>>>
> >>>> When device driver marks IRQ as a wakeup source I believe it is prepared
> >>>> to handle it (or it would shut it off explicitly).
> >>>
> >>> I can agree with that.
> >>>
> >>> Are you suggesting that __disable_irq() should check irq_data for
> >>> IRQD_WAKEUP_STATE and skip the IRQ (in the 'suspend' case) if that is set?
> >>
> >> Yes, something like that.
> >
> > OK
>
> Many thanks to you both for the discussion.
> >
> > Aubrey, can you please check if the appended patch helps on the T100?
>
> I verified this patch on T100, it works as expected, freeze can be waken
> up by reverting my patch and applying this one.
Thanks!
> Is this a final solution?
I hope so. I'll resend it with a proper changelog later today.
Rafael
From: Rafael J. Wysocki <[email protected]>
If an IRQ has been configured for wakeup via enable_irq_wake(), the
driver who has done that must be prepared for receiving interrupts
after suspend_device_irqs() has returned, so there is no need to
"suspend" such IRQs. Moreover, if drivers using enable_irq_wake()
actually want to receive interrupts after suspend_device_irqs() has
returned, they need to add IRQF_NO_SUSPEND to the IRQ flags while
requesting the IRQs, which shouldn't be necessary (it also goes a bit
too far, as IRQF_NO_SUSPEND causes the IRQ to be ignored by
suspend_device_irqs() all the time regardless of whether or not it
has been configured for signaling wakeup).
For the above reasons, make __disable_irq() ignore IRQ descriptors
with IRQD_WAKEUP_STATE set when its suspend argument is true which
effectively causes them to behave like IRQs with IRQF_NO_SUSPEND
set.
This also allows IRQs configured for wakeup via enable_irq_wake()
to work as wakeup interrupts for the "freeze" (suspend-to-idle)
sleep mode automatically just like for any other sleep states.
Signed-off-by: Rafael J. Wysocki <[email protected]>
---
kernel/irq/manage.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-pm/kernel/irq/manage.c
===================================================================
--- linux-pm.orig/kernel/irq/manage.c
+++ linux-pm/kernel/irq/manage.c
@@ -385,7 +385,8 @@ setup_affinity(unsigned int irq, struct
void __disable_irq(struct irq_desc *desc, unsigned int irq, bool suspend)
{
if (suspend) {
- if (!desc->action || (desc->action->flags & IRQF_NO_SUSPEND))
+ if (!desc->action || (desc->action->flags & IRQF_NO_SUSPEND)
+ || irqd_has_set(&desc->irq_data, IRQD_WAKEUP_STATE))
return;
desc->istate |= IRQS_SUSPENDED;
}
Commit-ID: d709f7bcbb3ab01704fa7b37a2e4b981cf3783c1
Gitweb: http://git.kernel.org/tip/d709f7bcbb3ab01704fa7b37a2e4b981cf3783c1
Author: Rafael J. Wysocki <[email protected]>
AuthorDate: Thu, 10 Jul 2014 23:37:54 +0200
Committer: Thomas Gleixner <[email protected]>
CommitDate: Tue, 15 Jul 2014 12:57:26 +0200
PM / sleep / irq: Do not suspend wakeup interrupts
If an IRQ has been configured for wakeup via enable_irq_wake(), the
driver who has done that must be prepared for receiving interrupts
after suspend_device_irqs() has returned, so there is no need to
"suspend" such IRQs. Moreover, if drivers using enable_irq_wake()
actually want to receive interrupts after suspend_device_irqs() has
returned, they need to add IRQF_NO_SUSPEND to the IRQ flags while
requesting the IRQs, which shouldn't be necessary (it also goes a bit
too far, as IRQF_NO_SUSPEND causes the IRQ to be ignored by
suspend_device_irqs() all the time regardless of whether or not it
has been configured for signaling wakeup).
For the above reasons, make __disable_irq() ignore IRQ descriptors
with IRQD_WAKEUP_STATE set when its suspend argument is true which
effectively causes them to behave like IRQs with IRQF_NO_SUSPEND
set.
This also allows IRQs configured for wakeup via enable_irq_wake()
to work as wakeup interrupts for the "freeze" (suspend-to-idle)
sleep mode automatically just like for any other sleep states.
Signed-off-by: Rafael J. Wysocki <[email protected]>
Cc: Li Aubrey <[email protected]>
Cc: Dmitry Torokhov <[email protected]>
Cc: One Thousand Gnomes <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
---
kernel/irq/manage.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 3dc6a61..88657d7 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -385,7 +385,8 @@ setup_affinity(unsigned int irq, struct irq_desc *desc, struct cpumask *mask)
void __disable_irq(struct irq_desc *desc, unsigned int irq, bool suspend)
{
if (suspend) {
- if (!desc->action || (desc->action->flags & IRQF_NO_SUSPEND))
+ if (!desc->action || (desc->action->flags & IRQF_NO_SUSPEND) ||
+ irqd_has_set(&desc->irq_data, IRQD_WAKEUP_STATE))
return;
desc->istate |= IRQS_SUSPENDED;
}
On Thursday 10 July 2014 23:37:54, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <[email protected]>
>
> If an IRQ has been configured for wakeup via enable_irq_wake(), the
> driver who has done that must be prepared for receiving interrupts
> after suspend_device_irqs() has returned, so there is no need to
> "suspend" such IRQs. Moreover, if drivers using enable_irq_wake()
> actually want to receive interrupts after suspend_device_irqs() has
> returned, they need to add IRQF_NO_SUSPEND to the IRQ flags while
> requesting the IRQs, which shouldn't be necessary (it also goes a bit
> too far, as IRQF_NO_SUSPEND causes the IRQ to be ignored by
> suspend_device_irqs() all the time regardless of whether or not it
> has been configured for signaling wakeup).
>
> For the above reasons, make __disable_irq() ignore IRQ descriptors
> with IRQD_WAKEUP_STATE set when its suspend argument is true which
> effectively causes them to behave like IRQs with IRQF_NO_SUSPEND
> set.
>
> This also allows IRQs configured for wakeup via enable_irq_wake()
> to work as wakeup interrupts for the "freeze" (suspend-to-idle)
> sleep mode automatically just like for any other sleep states.
>
> Signed-off-by: Rafael J. Wysocki <[email protected]>
> ---
> kernel/irq/manage.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> Index: linux-pm/kernel/irq/manage.c
> ===================================================================
> --- linux-pm.orig/kernel/irq/manage.c
> +++ linux-pm/kernel/irq/manage.c
> @@ -385,7 +385,8 @@ setup_affinity(unsigned int irq, struct
> void __disable_irq(struct irq_desc *desc, unsigned int irq, bool suspend)
> {
> if (suspend) {
> - if (!desc->action || (desc->action->flags & IRQF_NO_SUSPEND))
> + if (!desc->action || (desc->action->flags & IRQF_NO_SUSPEND)
> + || irqd_has_set(&desc->irq_data, IRQD_WAKEUP_STATE))
> return;
> desc->istate |= IRQS_SUSPENDED;
> }
Nice, this fixes my wakeup problem from freeze using gpio-keys. Unfortunately my SPI-attached touchscreen controller cannot be used for wakeup from freeze. Using it to wakeup from mem does work instead. Any ideas what might be wrong in this case?
Best regards,
Alexander
On Tuesday, July 15, 2014 02:22:25 PM Alexander Stein wrote:
> On Thursday 10 July 2014 23:37:54, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <[email protected]>
> >
> > If an IRQ has been configured for wakeup via enable_irq_wake(), the
> > driver who has done that must be prepared for receiving interrupts
> > after suspend_device_irqs() has returned, so there is no need to
> > "suspend" such IRQs. Moreover, if drivers using enable_irq_wake()
> > actually want to receive interrupts after suspend_device_irqs() has
> > returned, they need to add IRQF_NO_SUSPEND to the IRQ flags while
> > requesting the IRQs, which shouldn't be necessary (it also goes a bit
> > too far, as IRQF_NO_SUSPEND causes the IRQ to be ignored by
> > suspend_device_irqs() all the time regardless of whether or not it
> > has been configured for signaling wakeup).
> >
> > For the above reasons, make __disable_irq() ignore IRQ descriptors
> > with IRQD_WAKEUP_STATE set when its suspend argument is true which
> > effectively causes them to behave like IRQs with IRQF_NO_SUSPEND
> > set.
> >
> > This also allows IRQs configured for wakeup via enable_irq_wake()
> > to work as wakeup interrupts for the "freeze" (suspend-to-idle)
> > sleep mode automatically just like for any other sleep states.
> >
> > Signed-off-by: Rafael J. Wysocki <[email protected]>
> > ---
> > kernel/irq/manage.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > Index: linux-pm/kernel/irq/manage.c
> > ===================================================================
> > --- linux-pm.orig/kernel/irq/manage.c
> > +++ linux-pm/kernel/irq/manage.c
> > @@ -385,7 +385,8 @@ setup_affinity(unsigned int irq, struct
> > void __disable_irq(struct irq_desc *desc, unsigned int irq, bool suspend)
> > {
> > if (suspend) {
> > - if (!desc->action || (desc->action->flags & IRQF_NO_SUSPEND))
> > + if (!desc->action || (desc->action->flags & IRQF_NO_SUSPEND)
> > + || irqd_has_set(&desc->irq_data, IRQD_WAKEUP_STATE))
> > return;
> > desc->istate |= IRQS_SUSPENDED;
> > }
>
> Nice, this fixes my wakeup problem from freeze using gpio-keys. Unfortunately my SPI-attached touchscreen controller cannot be used for wakeup from freeze. Using it to wakeup from mem does work instead. Any ideas what might be wrong in this case?
Not without looking at the code in question.
One guess would be a missing call to enable_irq_wake().
Rafael
On Tuesday 15 July 2014 14:50:28, Rafael J. Wysocki wrote:
> On Tuesday, July 15, 2014 02:22:25 PM Alexander Stein wrote:
> > On Thursday 10 July 2014 23:37:54, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki <[email protected]>
> > >
> > > If an IRQ has been configured for wakeup via enable_irq_wake(), the
> > > driver who has done that must be prepared for receiving interrupts
> > > after suspend_device_irqs() has returned, so there is no need to
> > > "suspend" such IRQs. Moreover, if drivers using enable_irq_wake()
> > > actually want to receive interrupts after suspend_device_irqs() has
> > > returned, they need to add IRQF_NO_SUSPEND to the IRQ flags while
> > > requesting the IRQs, which shouldn't be necessary (it also goes a bit
> > > too far, as IRQF_NO_SUSPEND causes the IRQ to be ignored by
> > > suspend_device_irqs() all the time regardless of whether or not it
> > > has been configured for signaling wakeup).
> > >
> > > For the above reasons, make __disable_irq() ignore IRQ descriptors
> > > with IRQD_WAKEUP_STATE set when its suspend argument is true which
> > > effectively causes them to behave like IRQs with IRQF_NO_SUSPEND
> > > set.
> > >
> > > This also allows IRQs configured for wakeup via enable_irq_wake()
> > > to work as wakeup interrupts for the "freeze" (suspend-to-idle)
> > > sleep mode automatically just like for any other sleep states.
> > >
> > > Signed-off-by: Rafael J. Wysocki <[email protected]>
> > > ---
> > > kernel/irq/manage.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > Index: linux-pm/kernel/irq/manage.c
> > > ===================================================================
> > > --- linux-pm.orig/kernel/irq/manage.c
> > > +++ linux-pm/kernel/irq/manage.c
> > > @@ -385,7 +385,8 @@ setup_affinity(unsigned int irq, struct
> > > void __disable_irq(struct irq_desc *desc, unsigned int irq, bool suspend)
> > > {
> > > if (suspend) {
> > > - if (!desc->action || (desc->action->flags & IRQF_NO_SUSPEND))
> > > + if (!desc->action || (desc->action->flags & IRQF_NO_SUSPEND)
> > > + || irqd_has_set(&desc->irq_data, IRQD_WAKEUP_STATE))
> > > return;
> > > desc->istate |= IRQS_SUSPENDED;
> > > }
> >
> > Nice, this fixes my wakeup problem from freeze using gpio-keys. Unfortunately my SPI-attached touchscreen controller cannot be used for wakeup from freeze. Using it to wakeup from mem does work instead. Any ideas what might be wrong in this case?
>
> Not without looking at the code in question.
>
> One guess would be a missing call to enable_irq_wake().
No, ads7846.c does call 'enable_irq_wake(ts->spi->irq)'. So is this a platform or driver specific problem?
Regards,
Alexander
On Tuesday, July 15, 2014 02:36:46 PM Alexander Stein wrote:
> On Tuesday 15 July 2014 14:50:28, Rafael J. Wysocki wrote:
> > On Tuesday, July 15, 2014 02:22:25 PM Alexander Stein wrote:
> > > On Thursday 10 July 2014 23:37:54, Rafael J. Wysocki wrote:
> > > > From: Rafael J. Wysocki <[email protected]>
> > > >
> > > > If an IRQ has been configured for wakeup via enable_irq_wake(), the
> > > > driver who has done that must be prepared for receiving interrupts
> > > > after suspend_device_irqs() has returned, so there is no need to
> > > > "suspend" such IRQs. Moreover, if drivers using enable_irq_wake()
> > > > actually want to receive interrupts after suspend_device_irqs() has
> > > > returned, they need to add IRQF_NO_SUSPEND to the IRQ flags while
> > > > requesting the IRQs, which shouldn't be necessary (it also goes a bit
> > > > too far, as IRQF_NO_SUSPEND causes the IRQ to be ignored by
> > > > suspend_device_irqs() all the time regardless of whether or not it
> > > > has been configured for signaling wakeup).
> > > >
> > > > For the above reasons, make __disable_irq() ignore IRQ descriptors
> > > > with IRQD_WAKEUP_STATE set when its suspend argument is true which
> > > > effectively causes them to behave like IRQs with IRQF_NO_SUSPEND
> > > > set.
> > > >
> > > > This also allows IRQs configured for wakeup via enable_irq_wake()
> > > > to work as wakeup interrupts for the "freeze" (suspend-to-idle)
> > > > sleep mode automatically just like for any other sleep states.
> > > >
> > > > Signed-off-by: Rafael J. Wysocki <[email protected]>
> > > > ---
> > > > kernel/irq/manage.c | 3 ++-
> > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > >
> > > > Index: linux-pm/kernel/irq/manage.c
> > > > ===================================================================
> > > > --- linux-pm.orig/kernel/irq/manage.c
> > > > +++ linux-pm/kernel/irq/manage.c
> > > > @@ -385,7 +385,8 @@ setup_affinity(unsigned int irq, struct
> > > > void __disable_irq(struct irq_desc *desc, unsigned int irq, bool suspend)
> > > > {
> > > > if (suspend) {
> > > > - if (!desc->action || (desc->action->flags & IRQF_NO_SUSPEND))
> > > > + if (!desc->action || (desc->action->flags & IRQF_NO_SUSPEND)
> > > > + || irqd_has_set(&desc->irq_data, IRQD_WAKEUP_STATE))
> > > > return;
> > > > desc->istate |= IRQS_SUSPENDED;
> > > > }
> > >
> > > Nice, this fixes my wakeup problem from freeze using gpio-keys. Unfortunately my SPI-attached touchscreen controller cannot be used for wakeup from freeze. Using it to wakeup from mem does work instead. Any ideas what might be wrong in this case?
> >
> > Not without looking at the code in question.
> >
> > One guess would be a missing call to enable_irq_wake().
>
> No, ads7846.c does call 'enable_irq_wake(ts->spi->irq)'. So is this a platform or driver specific problem?
Well, both code paths are identical from the driver's perspective, so I'd bet
on the platform, but that's only a guess at this point.
Rafael
Hi Thomas,
On Tuesday, July 15, 2014 04:01:10 AM tip-bot for Rafael J. Wysocki wrote:
> Commit-ID: d709f7bcbb3ab01704fa7b37a2e4b981cf3783c1
> Gitweb: http://git.kernel.org/tip/d709f7bcbb3ab01704fa7b37a2e4b981cf3783c1
> Author: Rafael J. Wysocki <[email protected]>
> AuthorDate: Thu, 10 Jul 2014 23:37:54 +0200
> Committer: Thomas Gleixner <[email protected]>
> CommitDate: Tue, 15 Jul 2014 12:57:26 +0200
>
> PM / sleep / irq: Do not suspend wakeup interrupts
Please revert this one as it will introduce a problem with shared interrupts
analogous to the one that the handling of IRQF_NO_SUSPEND has.
Rafael