From: David Brownell <david-b@pacbell.net>
To: Anton Vorontsov <avorontsov@ru.mvista.com>
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
Subject: Re: [PATCH] rtc: Set wakeup capability for I2C and SPI RTC drivers
Date: Thu, 27 Aug 2009 14:52:36 -0700 [thread overview]
Message-ID: <200908271452.37358.david-b@pacbell.net> (raw)
In-Reply-To: <20090827182207.GA7358@oksana.dev.rtsoft.ru>
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_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 flag at all.
So why not add it for SPI? If it's an issue, it's not
unique to RTC devices.
> 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 possible though.
They need to be told that it is, by platform code.
Most devices can't issue wakeup events.
> That's what drivers/base/power/sysfs.c says:
>
> * It is the responsibility of device drivers to enable (or disable)
> * wakeup signaling as part of changing device power states, respecting
> * the policy choices provided through the driver model.
>
> I2C and SPI RTC devices send wakeup events via interrupt lines, so we
> should set the wakeup capability if IRQ is routed.
Re-read the quoted sentence. You're saying that policy
choices should be hard-wired into the driver; contrary
to that quote. (In this case the choice is one that
platform code must report, and which the hardware
designer made: if the device can issue wakeup events.)
> Ideally we should also check irq for wakeup capability before setting
> device's capability, i.e.
>
> if (can_irq_wake(irq))
> device_set_wakeup_capable(&client->dev, 1);
>
> But there is no can_irq_wake() call exist, and it is not that trivial
> to implement it for all interrupts controllers and complex/cascaded
> setups.
That is why platform code should device_init_wakeup() and
drivers should check device_can_wakeup(dev) ...
> drivers/base/power/sysfs.c also covers these cases:
>
> * Devices may not be able to generate wakeup events from all power
> * states. Also, the events may be ignored in some configurations;
> * for example, they might need help from other devices that aren't
> * active
>
> So there is no guarantee that wakeup will actually work,
Yes there is ... it's only **exceptional** cases where it can't
work. Your patch would make it routine that those flags be
unreliable; pretty nasty.
next prev parent reply other threads:[~2009-08-27 21:59 UTC|newest]
Thread overview: 5+ 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 21:52 ` David Brownell [this message]
2009-08-27 23:19 ` Anton Vorontsov
2009-08-28 0:30 ` Anton Vorontsov
2009-09-22 21:19 ` Andrew Morton
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=200908271452.37358.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=akpm@linux-foundation.org \
--cc=avorontsov@ru.mvista.com \
--cc=ben-linux@fluff.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox