On Fri, 28 Aug 2009 04:30:10 +0400
Anton Vorontsov wrote:
> 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
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().
>
> stat
On Thu, Aug 27, 2009 at 02:52:36PM -0700, David Brownell wrote:
[...]
> > I believe that it's not platform code responsibility to allow or
> > disallow wakeups, instead, drivers themselves should set the capability
> > if a device can trigger wakeups.
>
> Drivers can't generally know if that's pos
NAK; see details below
On Thursday 27 August 2009, Anton Vorontsov wrote:
> RTC core won't allow wakeup alarms to be set if RTC devices' parent
> (i.e. i2c_client or spi_device) isn't wakeup capable.
Quite rightly so ... being wakeup-capable is config-specific.
> For I2C devices there is I2C_CL
RTC core won't allow wakeup alarms to be set if RTC devices' parent
(i.e. i2c_client or spi_device) isn't wakeup capable.
For I2C devices there is I2C_CLIENT_WAKE flag exists that we can pass
via board info, and if set, I2C core will initialize wakeup capability.
For SPI devices there is no such f
