linux-kernel - Re: [linux-pm] sleepy linux self-test

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 2 Feb 2008 09:31:38 -0800
From:	David Brownell <david-b@...bell.net>
To:	Pavel Machek <pavel@....cz>
Cc:	linux-pm@...ts.linux-foundation.org, Ingo Molnar <mingo@...e.hu>,
	kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [linux-pm] sleepy linux self-test

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/