From: Anton Vorontsov <avorontsov@ru.mvista.com>
To: David Brownell <david-b@pacbell.net>
Cc: David Brownell <dbrownell@users.sourceforge.net>,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
Ben Dooks <ben-linux@fluff.org>,
Jean Delvare <khali@linux-fr.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-pm@lists.linux-foundation.org
Subject: Re: [PATCH] rtc: Set wakeup capability for I2C and SPI RTC drivers
Date: Fri, 28 Aug 2009 04:30:10 +0400 [thread overview]
Message-ID: <20090828003010.GA19160@oksana.dev.rtsoft.ru> (raw)
In-Reply-To: <20090827231925.GA1131@oksana.dev.rtsoft.ru>
On Fri, Aug 28, 2009 at 03:19:25AM +0400, Anton Vorontsov wrote:
[...]
> > That is why platform code should device_init_wakeup() and
> > drivers should check device_can_wakeup(dev) ...
>
> They should (and do) check may_wakeup() (i.e. should_wakeup) before
> suspending, not can_wakeup().
>
> static int ds1374_suspend(struct i2c_client *client, pm_message_t state)
> {
> if (client->irq >= 0 && device_may_wakeup(&client->dev))
> enable_irq_wake(client->irq);
> return 0;
> }
>
> (quite funny, they issue enable_irq_wake(), assuming that otherwise
> IRQ line won't trigger CPU wakeup. But in reality, there are interrupt
> controllers that you can't control in that regard: any IRQ activity
> will always resume CPU. And so 'echo disable > /sys/.../wakeup' won't
> guarantee anything. Unreliable, nasty? Could be.)
BTW, of course we can fix this by masking interrupts before
suspending, but nobody actually do this (but should, I think).
And if RTC's IRQ is wired to power switch you're in trouble
without any way to fix this.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
WARNING: multiple messages have this Message-ID (diff)
From: Anton Vorontsov <avorontsov@ru.mvista.com>
To: David Brownell <david-b@pacbell.net>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Ben Dooks <ben-linux@fluff.org>,
Jean Delvare <khali@linux-fr.org>,
linux-pm@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
David Brownell <dbrownell@users.sourceforge.net>
Subject: Re: [PATCH] rtc: Set wakeup capability for I2C and SPI RTC drivers
Date: Fri, 28 Aug 2009 04:30:10 +0400 [thread overview]
Message-ID: <20090828003010.GA19160@oksana.dev.rtsoft.ru> (raw)
In-Reply-To: <20090827231925.GA1131@oksana.dev.rtsoft.ru>
On Fri, Aug 28, 2009 at 03:19:25AM +0400, Anton Vorontsov wrote:
[...]
> > That is why platform code should device_init_wakeup() and
> > drivers should check device_can_wakeup(dev) ...
>
> They should (and do) check may_wakeup() (i.e. should_wakeup) before
> suspending, not can_wakeup().
>
> static int ds1374_suspend(struct i2c_client *client, pm_message_t state)
> {
> if (client->irq >= 0 && device_may_wakeup(&client->dev))
> enable_irq_wake(client->irq);
> return 0;
> }
>
> (quite funny, they issue enable_irq_wake(), assuming that otherwise
> IRQ line won't trigger CPU wakeup. But in reality, there are interrupt
> controllers that you can't control in that regard: any IRQ activity
> will always resume CPU. And so 'echo disable > /sys/.../wakeup' won't
> guarantee anything. Unreliable, nasty? Could be.)
BTW, of course we can fix this by masking interrupts before
suspending, but nobody actually do this (but should, I think).
And if RTC's IRQ is wired to power switch you're in trouble
without any way to fix this.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
next prev parent reply other threads:[~2009-08-28 0:30 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-27 18:22 [PATCH] rtc: Set wakeup capability for I2C and SPI RTC drivers Anton Vorontsov
2009-08-27 18:22 ` Anton Vorontsov
2009-08-27 21:52 ` David Brownell
2009-08-27 21:52 ` David Brownell
2009-08-27 23:19 ` Anton Vorontsov
2009-08-27 23:19 ` Anton Vorontsov
2009-08-28 0:30 ` Anton Vorontsov
2009-08-28 0:30 ` Anton Vorontsov [this message]
2009-08-28 0:30 ` Anton Vorontsov
2009-09-22 21:19 ` Andrew Morton
2009-09-22 21:19 ` Andrew Morton
2009-09-22 21:19 ` Andrew Morton
2009-08-27 23:19 ` Anton Vorontsov
-- strict thread matches above, loose matches on Subject: below --
2009-08-27 18:22 Anton Vorontsov
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=20090828003010.GA19160@oksana.dev.rtsoft.ru \
--to=avorontsov@ru.mvista.com \
--cc=akpm@linux-foundation.org \
--cc=ben-linux@fluff.org \
--cc=david-b@pacbell.net \
--cc=dbrownell@users.sourceforge.net \
--cc=khali@linux-fr.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=linuxppc-dev@ozlabs.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.