CC kernel/time/alarmtimer.c maintainers On Mon, Oct 31, 2022 at 06:10:53PM +0100, Alexandre Belloni wrote: > On 28/10/2022 17:54:00-0700, Guenter Roeck wrote: > > RTC chips on some older Chromebooks can only handle alarms less than 24 > > hours in the future. Attempts to set an alarm beyond that range fails. > > The most severe impact of this limitation is that suspend requests fail > > if alarmtimer_suspend() tries to set an alarm for more than 24 hours > > in the future. > > > > Try to set the real-time alarm to just below 24 hours if setting it to > > a larger value fails to work around the problem. While not perfect, it > > is better than just failing the call. A similar workaround is already > > implemented in the rtc-tps6586x driver. > > I'm not super convinced this is actually better than failing the call > because your are implementing policy in the driver which is bad from a > user point of view. It would be way better to return -ERANGE and let > userspace select a better alarm time. There is no way to signal user space. alarmtimer_suspend() is doing this on behalf of CLOCK_BOOTTIME_ALARM or CLOCK_REALTIME_ALARM timers, which were set long ago. We could possibly figure out some way to change the clock API to signal some kind of error back to the timer handlers, but that seems destined to be overly complex and not really help anyone (stable ABI, etc.). The right answer for alarmtimer is to just wake up a little early, IMO. (And failing alarmtimer_suspend() is Bad.) I think Guenter considered some alternative change to teach drivers/rtc/* and alarmtimer_suspend() to agree on an error code (ERANGE? or EDOM?) to do some automatic backoff there. But given the existing example (rtc-tps6586x) and the inconsistent use of error codes in drivers/rtc/, this seemed just as good of an option to me. But if we want to shave more yaks, then we'll have a more complex / riskier patch set and a harder time backporting the fix. That's OK too. Brian
