All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.