On Wed, 2008-04-09 at 03:13 -0700, David Brownell wrote:
> On Wednesday 09 April 2008, Zhao Yakui wrote:
> > > > Hmm, what if the wakealarm is set by mistake?
> > > > is there any chance that user can fix it?
> > >
> > > Certainly; there are several ways to turn an alarm off.
> > > With sysfs, just write a time in the past, as I recall...
> > >
> > > If you're concerned about accidents, think of it this way:
> > > the proposed patch would make it *REALLY EASY* to have
> > > accidents with sysfs that bork the alarm state, which can
> > > have been set by some task that's relying on it.
> >
> > But how to solve the following case?
> >
> > It is assumed that the RTC alarm is set by some task and not fired (It
> > will be fired after 20 minutes). The system enters the sleeping state
> > and is required to be resumed after some time(For example: ten minutes).
> >
> > How to set the RTC alarm?
>
> You mean, how to decide which alarm setting should "win"?
> If sysfs accidents aren't going to trump everything else.
What David said is right. There is a problem that settling the alarm unconditionally will
trash the alarm time on which some tasks are relying on.
It is OK to drop this patch.
But The following is reasonable. IMO.
For October: 0x0A will be written into the RTC region
(MONTH_ALARM). But in fact 0x10 should be written.
/* Writing 0xff means "don't care" or "match all". */
- mon = t->time.tm_mon;
- mon = (mon < 12) ? BIN2BCD(mon) : 0xff;
- mon++;
+ mon = t->time.tm_mon + 1;
+ mon = (mon <= 12) ? BIN2BCD(mon) : 0xff;
Is there an opportunity to merge it?
Thanks.
Yakui
> That's a fair question. I don't think there's a good answer
> to that with today's infrastructure. Arguably, there should
> be the notion of a number of clients, each of which get told
> when the alarm they request fires. But today, there's only
> a single alarm, and a single client.
>
> - Dave
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
