| Message ID | 20230816133936.2150294-2-linux@roeck-us.net |
|---|---|
| State | Superseded |
| Headers | show |
| Series | rtc: Add support for limited alarm timer offsets | expand |
On 16/08/2023 06:39:30-0700, Guenter Roeck wrote: > Some alarm timers are based on time offsets, not on absolute times. > In some situations, the amount of time that can be scheduled in the > future is limited. This may result in a refusal to suspend the system, > causing substantial battery drain. > > Some RTC alarm drivers remedy the situation by setting the alarm time > to the maximum supported time if a request for an out-of-range timeout > is made. This is not really desirable since it may result in unexpected > early wakeups. > > To reduce the impact of this problem, let RTC drivers report the maximum > supported alarm timer offset. The code setting alarm timers can then > decide if it wants to reject setting alarm timers to a larger value, if it > wants to implement recurring alarms until the actually requested alarm > time is met, or if it wants to accept the limited alarm time. > > Only introduce the necessary variable into struct rtc_device. > Code to set and use the variable will follow with subsequent patches. > > Cc: Brian Norris <briannorris@chromium.org> > Signed-off-by: Guenter Roeck <linux@roeck-us.net> > --- > include/linux/rtc.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/linux/rtc.h b/include/linux/rtc.h > index 1fd9c6a21ebe..b6d000ab1e5e 100644 > --- a/include/linux/rtc.h > +++ b/include/linux/rtc.h > @@ -146,6 +146,7 @@ struct rtc_device { > > time64_t range_min; > timeu64_t range_max; > + timeu64_t range_max_offset; While range_min and range_max are for the wall clock time, I would prefer using a name that would clearly mark this as an alarm related variable. > time64_t start_secs; > time64_t offset_secs; > bool set_start_time; > -- > 2.39.2 >
On Wed, Aug 16, 2023 at 04:57:30PM +0200, Alexandre Belloni wrote: > On 16/08/2023 06:39:30-0700, Guenter Roeck wrote: > > Some alarm timers are based on time offsets, not on absolute times. > > In some situations, the amount of time that can be scheduled in the > > future is limited. This may result in a refusal to suspend the system, > > causing substantial battery drain. > > > > Some RTC alarm drivers remedy the situation by setting the alarm time > > to the maximum supported time if a request for an out-of-range timeout > > is made. This is not really desirable since it may result in unexpected > > early wakeups. > > > > To reduce the impact of this problem, let RTC drivers report the maximum > > supported alarm timer offset. The code setting alarm timers can then > > decide if it wants to reject setting alarm timers to a larger value, if it > > wants to implement recurring alarms until the actually requested alarm > > time is met, or if it wants to accept the limited alarm time. > > > > Only introduce the necessary variable into struct rtc_device. > > Code to set and use the variable will follow with subsequent patches. > > > > Cc: Brian Norris <briannorris@chromium.org> > > Signed-off-by: Guenter Roeck <linux@roeck-us.net> > > --- > > include/linux/rtc.h | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/include/linux/rtc.h b/include/linux/rtc.h > > index 1fd9c6a21ebe..b6d000ab1e5e 100644 > > --- a/include/linux/rtc.h > > +++ b/include/linux/rtc.h > > @@ -146,6 +146,7 @@ struct rtc_device { > > > > time64_t range_min; > > timeu64_t range_max; > > + timeu64_t range_max_offset; > > While range_min and range_max are for the wall clock time, I would > prefer using a name that would clearly mark this as an alarm related > variable. Sure, no problem. Do you have a suggestion ? alarm_range_max or alarm_range_max_offset, maybe ? I'd also be happy to use some other term for 'offset' if you have a suggestion. Thanks, Guenter
On 16/08/2023 08:24:39-0700, Guenter Roeck wrote: > On Wed, Aug 16, 2023 at 04:57:30PM +0200, Alexandre Belloni wrote: > > On 16/08/2023 06:39:30-0700, Guenter Roeck wrote: > > > Some alarm timers are based on time offsets, not on absolute times. > > > In some situations, the amount of time that can be scheduled in the > > > future is limited. This may result in a refusal to suspend the system, > > > causing substantial battery drain. > > > > > > Some RTC alarm drivers remedy the situation by setting the alarm time > > > to the maximum supported time if a request for an out-of-range timeout > > > is made. This is not really desirable since it may result in unexpected > > > early wakeups. > > > > > > To reduce the impact of this problem, let RTC drivers report the maximum > > > supported alarm timer offset. The code setting alarm timers can then > > > decide if it wants to reject setting alarm timers to a larger value, if it > > > wants to implement recurring alarms until the actually requested alarm > > > time is met, or if it wants to accept the limited alarm time. > > > > > > Only introduce the necessary variable into struct rtc_device. > > > Code to set and use the variable will follow with subsequent patches. > > > > > > Cc: Brian Norris <briannorris@chromium.org> > > > Signed-off-by: Guenter Roeck <linux@roeck-us.net> > > > --- > > > include/linux/rtc.h | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/include/linux/rtc.h b/include/linux/rtc.h > > > index 1fd9c6a21ebe..b6d000ab1e5e 100644 > > > --- a/include/linux/rtc.h > > > +++ b/include/linux/rtc.h > > > @@ -146,6 +146,7 @@ struct rtc_device { > > > > > > time64_t range_min; > > > timeu64_t range_max; > > > + timeu64_t range_max_offset; > > > > While range_min and range_max are for the wall clock time, I would > > prefer using a name that would clearly mark this as an alarm related > > variable. > > Sure, no problem. Do you have a suggestion ? alarm_range_max or > alarm_range_max_offset, maybe ? I'd also be happy to use some other > term for 'offset' if you have a suggestion. I don't really know, what about alarm_offset_max? This is the maximum value of the offset for the alarm to the current time.
On Wed, Aug 16, 2023 at 06:19:05PM +0200, Alexandre Belloni wrote: > On 16/08/2023 08:24:39-0700, Guenter Roeck wrote: > > On Wed, Aug 16, 2023 at 04:57:30PM +0200, Alexandre Belloni wrote: > > > On 16/08/2023 06:39:30-0700, Guenter Roeck wrote: > > > > Some alarm timers are based on time offsets, not on absolute times. > > > > In some situations, the amount of time that can be scheduled in the > > > > future is limited. This may result in a refusal to suspend the system, > > > > causing substantial battery drain. > > > > > > > > Some RTC alarm drivers remedy the situation by setting the alarm time > > > > to the maximum supported time if a request for an out-of-range timeout > > > > is made. This is not really desirable since it may result in unexpected > > > > early wakeups. > > > > > > > > To reduce the impact of this problem, let RTC drivers report the maximum > > > > supported alarm timer offset. The code setting alarm timers can then > > > > decide if it wants to reject setting alarm timers to a larger value, if it > > > > wants to implement recurring alarms until the actually requested alarm > > > > time is met, or if it wants to accept the limited alarm time. > > > > > > > > Only introduce the necessary variable into struct rtc_device. > > > > Code to set and use the variable will follow with subsequent patches. > > > > > > > > Cc: Brian Norris <briannorris@chromium.org> > > > > Signed-off-by: Guenter Roeck <linux@roeck-us.net> > > > > --- > > > > include/linux/rtc.h | 1 + > > > > 1 file changed, 1 insertion(+) > > > > > > > > diff --git a/include/linux/rtc.h b/include/linux/rtc.h > > > > index 1fd9c6a21ebe..b6d000ab1e5e 100644 > > > > --- a/include/linux/rtc.h > > > > +++ b/include/linux/rtc.h > > > > @@ -146,6 +146,7 @@ struct rtc_device { > > > > > > > > time64_t range_min; > > > > timeu64_t range_max; > > > > + timeu64_t range_max_offset; > > > > > > While range_min and range_max are for the wall clock time, I would > > > prefer using a name that would clearly mark this as an alarm related > > > variable. > > > > Sure, no problem. Do you have a suggestion ? alarm_range_max or > > alarm_range_max_offset, maybe ? I'd also be happy to use some other > > term for 'offset' if you have a suggestion. > > I don't really know, what about alarm_offset_max? This is the maximum > value of the offset for the alarm to the current time. > Sounds good to me. Thanks, Guenter > > -- > Alexandre Belloni, co-owner and COO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com
diff --git a/include/linux/rtc.h b/include/linux/rtc.h index 1fd9c6a21ebe..b6d000ab1e5e 100644 --- a/include/linux/rtc.h +++ b/include/linux/rtc.h @@ -146,6 +146,7 @@ struct rtc_device { time64_t range_min; timeu64_t range_max; + timeu64_t range_max_offset; time64_t start_secs; time64_t offset_secs; bool set_start_time;
Some alarm timers are based on time offsets, not on absolute times. In some situations, the amount of time that can be scheduled in the future is limited. This may result in a refusal to suspend the system, causing substantial battery drain. Some RTC alarm drivers remedy the situation by setting the alarm time to the maximum supported time if a request for an out-of-range timeout is made. This is not really desirable since it may result in unexpected early wakeups. To reduce the impact of this problem, let RTC drivers report the maximum supported alarm timer offset. The code setting alarm timers can then decide if it wants to reject setting alarm timers to a larger value, if it wants to implement recurring alarms until the actually requested alarm time is met, or if it wants to accept the limited alarm time. Only introduce the necessary variable into struct rtc_device. Code to set and use the variable will follow with subsequent patches. Cc: Brian Norris <briannorris@chromium.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> --- include/linux/rtc.h | 1 + 1 file changed, 1 insertion(+)