From: David Brownell <david-b@pacbell.net>
To: Pavel Machek <pavel@ucw.cz>
Cc: linux-pm@lists.linux-foundation.org, Ingo Molnar <mingo@elte.hu>,
kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [linux-pm] sleepy linux self-test
Date: Sat, 2 Feb 2008 09:31:38 -0800 [thread overview]
Message-ID: <200802020931.38689.david-b@pacbell.net> (raw)
In-Reply-To: <20080202124759.GB25773@elf.ucw.cz>
On Saturday 02 February 2008, Pavel Machek wrote:
> Hi!
>
> > > --- a/drivers/rtc/rtc-cmos.c
> > > +++ b/drivers/rtc/rtc-cmos.c
> > > @@ -78,7 +78,7 @@ static inline int is_intr(u8 rtc_intr)
> > >
> > > /*----------------------------------------------------------------*/
> > >
> > > -static int cmos_read_time(struct device *dev, struct rtc_time *t)
> > > +int cmos_read_time(struct device *dev, struct rtc_time *t)
> > > {
> > >
> > > ... etc ...
> >
> > You should be using the standard RTC library calls, exported
> > from drivers/rtc/interface.c ... and making sure this mechanism
> > will work with any wakeup-capable RTC. Otherwise you'll end
> > being needlessly x86-specific, or reinventing those calls.
> >
> > Plus, the way you're doing it now is violating the locking
> > protocol used by that driver.
>
> Yep, you are right, but that is the easy issue to fix.
Which is why I was puzzled that you didn't start out doing it
the "right" way ... even just hard-wiring the dubious assumption
that "rtc0" is the right RTC to use. :)
> There's hard issue: I need
>
> struct rtc_device *rtc
>
> for the rtc that can be used for system resume,
Well, "rtc which (a) has an alarm, (b) may be used for system wakeup".
Assuming there *is* such an RTC ... fortunately, there will usually be
one on systems that are designed to go to sleep.
> and I'd like to get it
> without violating too many layers. How to do that?
>
> Ideally, I need
>
> set_alarm(int)
>
> ...that will magically pick the right rtc device to talk to, and set
> alarm on it. I don't see how to implement it with current code.
Easy enough. Given an RTC device node, you can tell whether it has
no chance at all to meet those requirements:
static int has_wakealarm(struct device *dev, void *name_ptr)
{
struct rtc_device *rtc = to_rtc_device(dev);
/* (a) has an alarm */
if (!rtc->op->set_alarm)
return 0;
/* (b) may be used for system wakeup */
if (device_may_wakeup(dev->parent))
return 0;
*(char **)name_ptr = rtc->name;
return 1;
}
Then there's a new class interface you may not have known about,
since it's been merged barely over a week now. You can use it
to find the name of the rtc to pass to rtc_open():
static char *find_wake_rtc(void)
{
char *pony = NULL;
dev = class_find_device(rtc_class, &rtc, has_wakealarm);
return pony;
}
On most PCs that will return the name "rtc0" ... and it'll do
the same on most of the other systems I have. On both of the
two-RTC systems I have that will return "rtc1". On systems
with no wakealarm-enabled RTC, that will return NULL.
Voila!
- Dave
next prev parent reply other threads:[~2008-02-02 17:31 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-30 13:17 Pavel Machek
2008-01-30 16:35 ` Ingo Molnar
2008-01-30 16:39 ` Pavel Machek
2008-01-30 19:36 ` Ingo Molnar
2008-01-30 23:26 ` Pavel Machek
2008-02-01 14:22 ` Ingo Molnar
2008-02-02 12:45 ` Pavel Machek
2008-02-02 13:49 ` Ingo Molnar
2008-02-02 13:51 ` Ingo Molnar
2008-02-01 1:55 ` [linux-pm] " David Brownell
2008-02-02 12:47 ` Pavel Machek
2008-02-02 13:50 ` Ingo Molnar
2008-02-02 17:49 ` David Brownell
2008-02-02 18:06 ` Ingo Molnar
2008-02-02 19:47 ` David Brownell
2008-02-02 17:31 ` David Brownell [this message]
2008-02-02 17:51 ` David Brownell
2008-02-02 18:00 ` Ingo Molnar
2008-02-02 19:13 ` David Brownell
2008-02-02 19:32 ` Pavel Machek
2008-02-02 19:38 ` Ingo Molnar
2008-02-02 19:59 ` Pavel Machek
2008-02-03 2:37 ` David Brownell
2008-02-03 5:05 ` Ingo Molnar
2008-02-03 5:14 ` Ingo Molnar
2008-02-03 5:19 ` Ingo Molnar
2008-02-03 5:35 ` Ingo Molnar
2008-02-03 5:54 ` Ingo Molnar
2008-02-03 7:05 ` Ingo Molnar
2008-02-03 7:32 ` David Brownell
2008-02-03 12:21 ` Rafael J. Wysocki
2008-02-03 13:16 ` David Brownell
2008-02-03 21:29 ` Rafael J. Wysocki
2008-02-03 22:42 ` David Brownell
2008-02-03 22:43 ` Rafael J. Wysocki
2008-02-03 22:48 ` Pavel Machek
2008-02-03 23:08 ` David Brownell
2008-02-10 21:03 ` Pavel Machek
2008-02-18 8:56 ` Pavel Machek
2008-02-18 9:46 ` [patch] suspend/resume self-test Ingo Molnar
2008-02-18 9:53 ` Pavel Machek
2008-02-18 10:40 ` David Brownell
2008-02-18 11:04 ` Rafael J. Wysocki
2008-02-18 13:09 ` Ingo Molnar
2008-02-18 20:16 ` David Brownell
2008-02-19 10:11 ` Pavel Machek
2008-02-19 14:43 ` Ingo Molnar
2008-02-19 19:12 ` David Brownell
2008-02-20 10:15 ` Ingo Molnar
2008-02-19 14:40 ` Ingo Molnar
2008-02-18 11:06 ` Rafael J. Wysocki
2008-02-10 21:02 ` [linux-pm] sleepy linux self-test Pavel Machek
2008-02-03 7:18 ` David Brownell
2008-02-03 7:51 ` Sam Ravnborg
2008-02-03 8:26 ` David Brownell
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=200802020931.38689.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=mingo@elte.hu \
--cc=pavel@ucw.cz \
/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
Powered by JetHome