kernel/drivers/rtc/rtc-stm32.c, branch linux-6.9.y

rtc: stm32: Use NOIRQ_SYSTEM_SLEEP_PM_OPS()

2023-08-16T22:53:00Z

After the switch to SET_NOIRQ_SYSTEM_SLEEP_PM_OPS() and a subsequent fix, stm32_rtc_{suspend,resume}() are unused when CONFIG_PM_SLEEP is not set because SET_NOIRQ_SYSTEM_SLEEP_PM_OPS() is a no-op in that configuration: drivers/rtc/rtc-stm32.c:904:12: error: 'stm32_rtc_resume' defined but not used [-Werror=unused-function] 904 | static int stm32_rtc_resume(struct device *dev) | ^~~~~~~~~~~~~~~~ drivers/rtc/rtc-stm32.c:894:12: error: 'stm32_rtc_suspend' defined but not used [-Werror=unused-function] 894 | static int stm32_rtc_suspend(struct device *dev) | ^~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors The non-"SET_" version of this macro, NOIRQ_SYSTEM_SLEEP_PM_OPS(), is designed to handle this situation by only assigning the callbacks when CONFIG_PM_SLEEP is set while allowing the functions to appear used to the compiler. Switch to that macro to resolve the warnings. There is no functional change with this, as SET_NOIRQ_SYSTEM_SLEEP_PM_OPS() is defined using NOIRQ_SYSTEM_SLEEP_PM_OPS() when CONFIG_PM_SLEEP is set. Signed-off-by: Nathan Chancellor Reviewed-by: Arnd Bergmann Link: https://lore.kernel.org/r/20230815-rtc-stm32-unused-pm-funcs-v1-1-82eb8e02d903@kernel.org Signed-off-by: Alexandre Belloni

rtc: stm32: remove incorrect #ifdef check

2023-08-10T07:22:04Z

After a previous commit changed the driver over to SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(), the suspend/resume functions must no longer be hidden behind an #ifdef: In file included from include/linux/clk.h:13, from drivers/rtc/rtc-stm32.c:8: drivers/rtc/rtc-stm32.c:927:39: error: 'stm32_rtc_suspend' undeclared here (not in a function); did you mean 'stm32_rtc_probe'? 927 | SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(stm32_rtc_suspend, stm32_rtc_resume) | ^~~~~~~~~~~~~~~~~ include/linux/kernel.h:58:44: note: in definition of macro 'PTR_IF' 58 | #define PTR_IF(cond, ptr) ((cond) ? (ptr) : NULL) | ^~~ include/linux/pm.h:329:26: note: in expansion of macro 'pm_sleep_ptr' 329 | .suspend_noirq = pm_sleep_ptr(suspend_fn), \ | ^~~~~~~~~~~~ Fixes: fb9a7e5360dc8 ("rtc: stm32: change PM callbacks to "_noirq()"") Signed-off-by: Arnd Bergmann Reviewed-by: Valentin Caron Link: https://lore.kernel.org/r/20230801105932.3738430-1-arnd@kernel.org Signed-off-by: Alexandre Belloni

rtc: Explicitly include correct DT includes

2023-07-27T21:31:29Z

The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20230724205456.767430-1-robh@kernel.org Signed-off-by: Alexandre Belloni

rtc: stm32: fix unnecessary parentheses

2023-07-27T21:03:34Z

Fix a few style issues reported by checkpatch.pl: - Unnecessary parentheses - Lines should not end with a '(' Signed-off-by: Valentin Caron Link: https://lore.kernel.org/r/20230705174357.353616-8-valentin.caron@foss.st.com Signed-off-by: Alexandre Belloni

rtc: stm32: fix issues of stm32_rtc_valid_alrm function

2023-07-27T21:03:34Z

stm32_rtc_valid_alrm function has some issues : - arithmetical operations are impossible on BCD values - "cur_mon + 1" can overflow - the use case with the next month, the same day/hour/minutes went wrong To solve that, we prefer to use timestamp comparison. e.g. : On 5 Dec. 2021, the alarm limit is 5 Jan. 2022 (+31 days) On 31 Jan 2021, the alarm limit is 28 Feb. 2022 (+28 days) Signed-off-by: Valentin Caron Link: https://lore.kernel.org/r/20230705174357.353616-7-valentin.caron@foss.st.com Signed-off-by: Alexandre Belloni

rtc: stm32: change PM callbacks to "_noirq()"

2023-07-27T21:03:34Z

The RTC driver stops the RTCAPB clock during suspend, but the irq handler from RTC is called before starting clock. Then we are blocked while accessing RTC registers. We changes PM callbacks to '_no_irq()' to disable irq during resume callback and so irq handler will be called after the enable of RTCAPB clock. Signed-off-by: Gabriel Fernandez Signed-off-by: Valentin Caron Link: https://lore.kernel.org/r/20230705174357.353616-6-valentin.caron@foss.st.com Signed-off-by: Alexandre Belloni

rtc: stm32: don't print an error on probe deferral

2023-07-27T21:03:34Z

Change stm32-rtc driver to not generate an error message when device probe operation is deferred for a clock. Signed-off-by: Etienne Carriere Signed-off-by: Valentin Caron Link: https://lore.kernel.org/r/20230705174357.353616-5-valentin.caron@foss.st.com Signed-off-by: Alexandre Belloni

rtc: stm32: improve rtc precision

2023-07-27T21:03:34Z

The rtc is used to update the stgen counter on wake up from low power modes, so it needs to be as much accurate as possible. The maximization of asynchronous divider leads to a 4ms rtc precision clock. By decreasing pred_a to 0, it will have pred_s=32767 (when need_accuracy is true), so stgen clock becomes more accurate with 30us precision. Nevertheless this will leads to an increase of power consumption. Signed-off-by: Christophe Guibout Signed-off-by: Valentin Caron Link: https://lore.kernel.org/r/20230705174357.353616-4-valentin.caron@foss.st.com Signed-off-by: Alexandre Belloni

rtc: stm32: don't stop time counter if not needed

2023-07-27T21:03:34Z

RTC counters are stopped when INIT bit in ISR register is set and start counting from the (eventual) new value when INIT is reset. In stm32_rtc_init(), called during probe, the INIT bit is set to program the prescaler and the 24h mode. This halts the RTC counter at each probe tentative causing the RTC time to loose from 0.3s to 0.8s at each kernel boot. If the RTC is battery powered, both prescaler value and 24h mode are kept during power cycle and there is no need to program them again. Check if the desired prescaler value and the 24h mode are already programmed, then skip reprogramming them to avoid halting the time counter. Signed-off-by: Antonio Borneo Signed-off-by: Valentin Caron Link: https://lore.kernel.org/r/20230705174357.353616-3-valentin.caron@foss.st.com Signed-off-by: Alexandre Belloni

rtc: stm32: use the proper register sequence to read date/time

2023-07-27T21:03:33Z

Date and time are read from two separate RTC registers. To ensure consistency between the two registers, reading the time register locks the values in the shadow date register until the date register is read. Thus, the whole date/time read requires reading the time register first, followed by reading the date register. If the reads are done in reversed order, the shadow date register will remain locked until a future read operation. The future read will read the former date value that could be already invalid. Fix the read order of date/time registers in stm32_rtc_valid_alrm() Signed-off-by: Antonio Borneo Signed-off-by: Valentin Caron Link: https://lore.kernel.org/r/20230705174357.353616-2-valentin.caron@foss.st.com Signed-off-by: Alexandre Belloni