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...
- 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
