On Wed, 2008-04-09 at 18:08 +0800, David Brownell wrote:
> On Wednesday 09 April 2008, Zhao Yakui wrote:
> >
> > > instead? Else I don't see what would disable the
> > > alarm when it's supposed to be disabled. Plus, if
> > > that's done here, I suspect it also needs to be
> > > done in rtc_ioctl() for RTC_AIE_{ON,OFF} and *NOT*
> > > done in cmos_{suspend,resume)() ... very odd for a
> > > wakeup hook, since none of those presume the system
> > > is entering a state from which it could wake!
> >
> > If alarm is only used as the wake event source from sleeping state,
> it
> > is enough to call hook function in suspend/resume.
>
> From what other state could it "wake" though ???
> It doesn't "wake" except from sleeping states...
>
>
> > But if the system is booted with acpi enabled , I suspect whether
> RTC
> > alarm can trigger RTC IRQ.
>
> That is, you just "suspect" it won't work? That seems
> like a weak reason to change things. And if RTC IRQs
> don't actually work at runtime, that'd seem wierd.
>
>
> > If the RTC alarm is dedicated as the wake
> > event source, it will be also OK to call the hook function when the
> > alarm is enabled.
>
> Well, *today* the only client of that hook is ACPI. But
> if there's no actual need to call those wake hooks for
> non-wake code paths, I'd sure rather avoid doing that...
Reasonable.
As the ACPI wakup event of RTC is useless at runtime, it's okay with me
to drop this patch.
thanks,
rui
--
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
