Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46 |
|
#
2cf2a1ac |
| 15-Aug-2023 |
Nathan Chancellor <nathan@kernel.org> |
rtc: stm32: Use NOIRQ_SYSTEM_SLEEP_PM_OPS()
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
rtc: stm32: Use NOIRQ_SYSTEM_SLEEP_PM_OPS()
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 <nathan@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20230815-rtc-stm32-unused-pm-funcs-v1-1-82eb8e02d903@kernel.org Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
show more ...
|
Revision tags: v6.1.45, v6.1.44, v6.1.43 |
|
#
a69c610e |
| 01-Aug-2023 |
Arnd Bergmann <arnd@arndb.de> |
rtc: stm32: remove incorrect #ifdef check
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:
rtc: stm32: remove incorrect #ifdef check
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 <arnd@arndb.de> Reviewed-by: Valentin Caron <valentin.caron@foss.st.com> Link: https://lore.kernel.org/r/20230801105932.3738430-1-arnd@kernel.org Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
show more ...
|
Revision tags: v6.1.42 |
|
#
48144c28 |
| 24-Jul-2023 |
Rob Herring <robh@kernel.org> |
rtc: Explicitly include correct DT includes
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 mer
rtc: Explicitly include correct DT includes
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 <robh@kernel.org> Link: https://lore.kernel.org/r/20230724205456.767430-1-robh@kernel.org Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
show more ...
|
Revision tags: v6.1.41, v6.1.40, v6.1.39 |
|
#
650915ec |
| 05-Jul-2023 |
Valentin Caron <valentin.caron@foss.st.com> |
rtc: stm32: fix unnecessary parentheses
Fix a few style issues reported by checkpatch.pl: - Unnecessary parentheses - Lines should not end with a '('
Signed-off-by: Valentin Caron <valentin.caron@f
rtc: stm32: fix unnecessary parentheses
Fix a few style issues reported by checkpatch.pl: - Unnecessary parentheses - Lines should not end with a '('
Signed-off-by: Valentin Caron <valentin.caron@foss.st.com> Link: https://lore.kernel.org/r/20230705174357.353616-8-valentin.caron@foss.st.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
show more ...
|
#
46828a5f |
| 05-Jul-2023 |
Valentin Caron <valentin.caron@foss.st.com> |
rtc: stm32: fix issues of stm32_rtc_valid_alrm function
stm32_rtc_valid_alrm function has some issues : - arithmetical operations are impossible on BCD values - "cur_mon + 1" can overflow - the use
rtc: stm32: fix issues of stm32_rtc_valid_alrm function
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 <valentin.caron@foss.st.com> Link: https://lore.kernel.org/r/20230705174357.353616-7-valentin.caron@foss.st.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
show more ...
|
#
fb9a7e53 |
| 05-Jul-2023 |
Gabriel Fernandez <gabriel.fernandez@foss.st.com> |
rtc: stm32: change PM callbacks to "_noirq()"
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: stm32: change PM callbacks to "_noirq()"
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 <gabriel.fernandez@foss.st.com> Signed-off-by: Valentin Caron <valentin.caron@foss.st.com> Link: https://lore.kernel.org/r/20230705174357.353616-6-valentin.caron@foss.st.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
show more ...
|
#
95f7679c |
| 05-Jul-2023 |
Valentin Caron <valentin.caron@foss.st.com> |
rtc: stm32: don't print an error on probe deferral
Change stm32-rtc driver to not generate an error message when device probe operation is deferred for a clock.
Signed-off-by: Etienne Carriere <eti
rtc: stm32: don't print an error on probe deferral
Change stm32-rtc driver to not generate an error message when device probe operation is deferred for a clock.
Signed-off-by: Etienne Carriere <etienne.carriere@foss.st.com> Signed-off-by: Valentin Caron <valentin.caron@foss.st.com> Link: https://lore.kernel.org/r/20230705174357.353616-5-valentin.caron@foss.st.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
show more ...
|
#
24879257 |
| 05-Jul-2023 |
Christophe Guibout <christophe.guibout@foss.st.com> |
rtc: stm32: improve rtc precision
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 divid
rtc: stm32: improve rtc precision
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 <christophe.guibout@foss.st.com> Signed-off-by: Valentin Caron <valentin.caron@foss.st.com> Link: https://lore.kernel.org/r/20230705174357.353616-4-valentin.caron@foss.st.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
show more ...
|
#
1c18b8ec |
| 05-Jul-2023 |
Antonio Borneo <antonio.borneo@foss.st.com> |
rtc: stm32: don't stop time counter if not needed
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_ini
rtc: stm32: don't stop time counter if not needed
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 <antonio.borneo@foss.st.com> Signed-off-by: Valentin Caron <valentin.caron@foss.st.com> Link: https://lore.kernel.org/r/20230705174357.353616-3-valentin.caron@foss.st.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
show more ...
|
#
f69cb2d6 |
| 05-Jul-2023 |
Antonio Borneo <antonio.borneo@foss.st.com> |
rtc: stm32: use the proper register sequence to read date/time
Date and time are read from two separate RTC registers. To ensure consistency between the two registers, reading the time register lock
rtc: stm32: use the proper register sequence to read date/time
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 <antonio.borneo@foss.st.com> Signed-off-by: Valentin Caron <valentin.caron@foss.st.com> Link: https://lore.kernel.org/r/20230705174357.353616-2-valentin.caron@foss.st.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
show more ...
|
Revision tags: v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32 |
|
#
38e0689b |
| 31-May-2023 |
Alexandre Torgue <alexandre.torgue@foss.st.com> |
rtc: stm32: remove dedicated wakeup management
There is no more needs to use a dedicated wake up interrupt for RTC as EXTI block manages by itself now all interrupt lines.
Dedicated wakeup interrup
rtc: stm32: remove dedicated wakeup management
There is no more needs to use a dedicated wake up interrupt for RTC as EXTI block manages by itself now all interrupt lines.
Dedicated wakeup interrupt has been introduced with STM32 MP1 support commit b72252b6580c ("rtc: stm32: add stm32mp1 rtc support") because GIC & EXTI interrupts were not yet linked in EXTI driver.
Removing this interrupt won't break compatibility with device trees which do use two interrupts entries: it could only prevent wakeup from low power modes on STM32MP1x, but platform power management is not yet available.
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Link: https://lore.kernel.org/r/20230531122732.1515594-1-amelie.delaunay@foss.st.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
show more ...
|
Revision tags: v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16 |
|
#
54c2cb27 |
| 04-Mar-2023 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
rtc: stm32: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error ha
rtc: stm32: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void.
Trivially convert this driver from always returning zero in the remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230304133028.2135435-33-u.kleine-koenig@pengutronix.de Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
show more ...
|
Revision tags: v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43 |
|
#
950ac33d |
| 07-Jun-2021 |
Martin Fuzzey <martin.fuzzey@flowbird.group> |
rtc: stm32: Fix unbalanced clk_disable_unprepare() on probe error path
The STM32MP1 RTC may have 2 clocks, the pclk and the rtc_ck.
If clk_prepare_enable() fails for the second clock (rtc_ck) we mu
rtc: stm32: Fix unbalanced clk_disable_unprepare() on probe error path
The STM32MP1 RTC may have 2 clocks, the pclk and the rtc_ck.
If clk_prepare_enable() fails for the second clock (rtc_ck) we must only call clk_disable_unprepare() for the first clock (pclk) but currently we call it on both leading to a WARN:
[ 15.629568] WARNING: CPU: 0 PID: 146 at drivers/clk/clk.c:958 clk_core_disable+0xb0/0xc8 [ 15.637620] ck_rtc already disabled [ 15.663322] CPU: 0 PID: 146 Comm: systemd-udevd Not tainted 5.4.77-pknbsp-svn5759-atag-v5.4.77-204-gea4235203137-dirty #2413 [ 15.674510] Hardware name: STM32 (Device Tree Support) [ 15.679658] [<c0111148>] (unwind_backtrace) from [<c010c0b8>] (show_stack+0x10/0x14) [ 15.687371] [<c010c0b8>] (show_stack) from [<c0ab3d28>] (dump_stack+0xc0/0xe0) [ 15.694574] [<c0ab3d28>] (dump_stack) from [<c012360c>] (__warn+0xc8/0xf0) [ 15.701428] [<c012360c>] (__warn) from [<c0123694>] (warn_slowpath_fmt+0x60/0x94) [ 15.708894] [<c0123694>] (warn_slowpath_fmt) from [<c053b518>] (clk_core_disable+0xb0/0xc8) [ 15.717230] [<c053b518>] (clk_core_disable) from [<c053c190>] (clk_core_disable_lock+0x18/0x24) [ 15.725924] [<c053c190>] (clk_core_disable_lock) from [<bf0adc44>] (stm32_rtc_probe+0x124/0x5e4 [rtc_stm32]) [ 15.735739] [<bf0adc44>] (stm32_rtc_probe [rtc_stm32]) from [<c05f7d4c>] (platform_drv_probe+0x48/0x98) [ 15.745095] [<c05f7d4c>] (platform_drv_probe) from [<c05f5cec>] (really_probe+0x1f0/0x458) [ 15.753338] [<c05f5cec>] (really_probe) from [<c05f61c4>] (driver_probe_device+0x70/0x1c4) [ 15.761584] [<c05f61c4>] (driver_probe_device) from [<c05f6580>] (device_driver_attach+0x58/0x60) [ 15.770439] [<c05f6580>] (device_driver_attach) from [<c05f6654>] (__driver_attach+0xcc/0x170) [ 15.779032] [<c05f6654>] (__driver_attach) from [<c05f40d8>] (bus_for_each_dev+0x58/0x7c) [ 15.787191] [<c05f40d8>] (bus_for_each_dev) from [<c05f4ffc>] (bus_add_driver+0xdc/0x1f8) [ 15.795352] [<c05f4ffc>] (bus_add_driver) from [<c05f6ed8>] (driver_register+0x7c/0x110) [ 15.803425] [<c05f6ed8>] (driver_register) from [<c01027bc>] (do_one_initcall+0x70/0x1b8) [ 15.811588] [<c01027bc>] (do_one_initcall) from [<c01a1094>] (do_init_module+0x58/0x1f8) [ 15.819660] [<c01a1094>] (do_init_module) from [<c01a0074>] (load_module+0x1e58/0x23c8) [ 15.827646] [<c01a0074>] (load_module) from [<c01a0860>] (sys_finit_module+0xa0/0xd4) [ 15.835459] [<c01a0860>] (sys_finit_module) from [<c01011e0>] (__sys_trace_return+0x0/0x20)
Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group> Fixes: 4e64350f42e2 ("rtc: add STM32 RTC driver") Cc: stable@vger.kernel.org Reviewed-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/1623087421-19722-1-git-send-email-martin.fuzzey@flowbird.group
show more ...
|
Revision tags: v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14 |
|
#
f66e7f2d |
| 19-Jan-2021 |
Alexandre Belloni <alexandre.belloni@bootlin.com> |
rtc: stm32: use rtc_lock/rtc_unlock
Avoid accessing directly rtc->ops_lock and use the RTC core helpers.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.o
rtc: stm32: use rtc_lock/rtc_unlock
Avoid accessing directly rtc->ops_lock and use the RTC core helpers.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210119220653.677750-14-alexandre.belloni@bootlin.com
show more ...
|
#
a6f7bf26 |
| 07-Jun-2021 |
Martin Fuzzey <martin.fuzzey@flowbird.group> |
rtc: stm32: Fix unbalanced clk_disable_unprepare() on probe error path
commit 950ac33dbe6ff656a623d862022f0762ec061ba7 upstream.
The STM32MP1 RTC may have 2 clocks, the pclk and the rtc_ck.
If clk
rtc: stm32: Fix unbalanced clk_disable_unprepare() on probe error path
commit 950ac33dbe6ff656a623d862022f0762ec061ba7 upstream.
The STM32MP1 RTC may have 2 clocks, the pclk and the rtc_ck.
If clk_prepare_enable() fails for the second clock (rtc_ck) we must only call clk_disable_unprepare() for the first clock (pclk) but currently we call it on both leading to a WARN:
[ 15.629568] WARNING: CPU: 0 PID: 146 at drivers/clk/clk.c:958 clk_core_disable+0xb0/0xc8 [ 15.637620] ck_rtc already disabled [ 15.663322] CPU: 0 PID: 146 Comm: systemd-udevd Not tainted 5.4.77-pknbsp-svn5759-atag-v5.4.77-204-gea4235203137-dirty #2413 [ 15.674510] Hardware name: STM32 (Device Tree Support) [ 15.679658] [<c0111148>] (unwind_backtrace) from [<c010c0b8>] (show_stack+0x10/0x14) [ 15.687371] [<c010c0b8>] (show_stack) from [<c0ab3d28>] (dump_stack+0xc0/0xe0) [ 15.694574] [<c0ab3d28>] (dump_stack) from [<c012360c>] (__warn+0xc8/0xf0) [ 15.701428] [<c012360c>] (__warn) from [<c0123694>] (warn_slowpath_fmt+0x60/0x94) [ 15.708894] [<c0123694>] (warn_slowpath_fmt) from [<c053b518>] (clk_core_disable+0xb0/0xc8) [ 15.717230] [<c053b518>] (clk_core_disable) from [<c053c190>] (clk_core_disable_lock+0x18/0x24) [ 15.725924] [<c053c190>] (clk_core_disable_lock) from [<bf0adc44>] (stm32_rtc_probe+0x124/0x5e4 [rtc_stm32]) [ 15.735739] [<bf0adc44>] (stm32_rtc_probe [rtc_stm32]) from [<c05f7d4c>] (platform_drv_probe+0x48/0x98) [ 15.745095] [<c05f7d4c>] (platform_drv_probe) from [<c05f5cec>] (really_probe+0x1f0/0x458) [ 15.753338] [<c05f5cec>] (really_probe) from [<c05f61c4>] (driver_probe_device+0x70/0x1c4) [ 15.761584] [<c05f61c4>] (driver_probe_device) from [<c05f6580>] (device_driver_attach+0x58/0x60) [ 15.770439] [<c05f6580>] (device_driver_attach) from [<c05f6654>] (__driver_attach+0xcc/0x170) [ 15.779032] [<c05f6654>] (__driver_attach) from [<c05f40d8>] (bus_for_each_dev+0x58/0x7c) [ 15.787191] [<c05f40d8>] (bus_for_each_dev) from [<c05f4ffc>] (bus_add_driver+0xdc/0x1f8) [ 15.795352] [<c05f4ffc>] (bus_add_driver) from [<c05f6ed8>] (driver_register+0x7c/0x110) [ 15.803425] [<c05f6ed8>] (driver_register) from [<c01027bc>] (do_one_initcall+0x70/0x1b8) [ 15.811588] [<c01027bc>] (do_one_initcall) from [<c01a1094>] (do_init_module+0x58/0x1f8) [ 15.819660] [<c01a1094>] (do_init_module) from [<c01a0074>] (load_module+0x1e58/0x23c8) [ 15.827646] [<c01a0074>] (load_module) from [<c01a0860>] (sys_finit_module+0xa0/0xd4) [ 15.835459] [<c01a0860>] (sys_finit_module) from [<c01011e0>] (__sys_trace_return+0x0/0x20)
Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group> Fixes: 4e64350f42e2 ("rtc: add STM32 RTC driver") Cc: stable@vger.kernel.org Reviewed-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/1623087421-19722-1-git-send-email-martin.fuzzey@flowbird.group Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3 |
|
#
cf33e911 |
| 05-Dec-2019 |
Chuhong Yuan <hslester96@gmail.com> |
rtc: stm32: add missed clk_disable_unprepare in error path of resume
The resume() forgets to call clk_disable_unprepare() when failed. Add the missed call to fix it.
Signed-off-by: Chuhong Yuan <hs
rtc: stm32: add missed clk_disable_unprepare in error path of resume
The resume() forgets to call clk_disable_unprepare() when failed. Add the missed call to fix it.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Reviewed-by: Amelie Delaunay <amelie.delaunay@st.com> Link: https://lore.kernel.org/r/20191205160655.32188-1-hslester96@gmail.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
show more ...
|
Revision tags: v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5 |
|
#
09ef18bc |
| 06-Oct-2019 |
YueHaibing <yuehaibing@huawei.com> |
rtc: use devm_platform_ioremap_resource() to simplify code
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle.
Signed-off-by: YueHaibing <yuehaibing@hua
rtc: use devm_platform_ioremap_resource() to simplify code
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle.
Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20191006102953.57536-2-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-3-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-4-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-5-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-6-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-7-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-8-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-9-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-10-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-11-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-12-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-13-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-14-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-15-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-16-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-17-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-18-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-19-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-20-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-21-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-22-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-23-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-24-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-25-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-26-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-27-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-28-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-29-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-30-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-31-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-32-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-33-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-34-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-35-yuehaibing@huawei.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
show more ...
|
Revision tags: v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5 |
|
#
faac9102 |
| 30-Jul-2019 |
Stephen Boyd <swboyd@chromium.org> |
rtc: Remove dev_err() usage after platform_get_irq()
We don't need dev_err() messages when platform_get_irq() fails now that platform_get_irq() prints an error message itself when something goes wro
rtc: Remove dev_err() usage after platform_get_irq()
We don't need dev_err() messages when platform_get_irq() fails now that platform_get_irq() prints an error message itself when something goes wrong. Let's remove these prints with a simple semantic patch.
// <smpl> @@ expression ret; struct platform_device *E; @@
ret = ( platform_get_irq(E, ...) | platform_get_irq_byname(E, ...) );
if ( \( ret < 0 \| ret <= 0 \) ) { ( -if (ret != -EPROBE_DEFER) -{ ... -dev_err(...); -... } | ... -dev_err(...); ) ... } // </smpl>
While we're here, remove braces on if statements that only have one statement (manually).
Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: linux-rtc@vger.kernel.org Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20190730181557.90391-40-swboyd@chromium.org Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
show more ...
|
Revision tags: v5.2.4, v5.2.3, v5.2.2, v5.2.1 |
|
#
fe63604c |
| 08-Jul-2019 |
Markus Elfring <elfring@users.sourceforge.net> |
rtc: stm32: remove one condition check in stm32_rtc_set_alarm()
A condition check was repeated in this function implementation despite of a corresponding check in the stm32_rtc_alarm_irq_enable() fu
rtc: stm32: remove one condition check in stm32_rtc_set_alarm()
A condition check was repeated in this function implementation despite of a corresponding check in the stm32_rtc_alarm_irq_enable() function. Thus delete redundant source code here.
This issue was detected by using the Coccinelle software.
Suggested-by: Russell King <linux@armlinux.org.uk> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Reviewed-by: Amelie Delaunay <amelie.delaunay@st.com> Link: https://lore.kernel.org/r/4da614a4-83c6-548c-a112-033b846c561b@web.de Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
show more ...
|
Revision tags: v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10 |
|
#
cf612c59 |
| 24-Apr-2019 |
Fabien Dessenne <fabien.dessenne@st.com> |
rtc: stm32: manage the get_irq probe defer case
Manage the -EPROBE_DEFER error case for the wake IRQ.
Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com> Acked-by: Amelie Delaunay <amelie.delau
rtc: stm32: manage the get_irq probe defer case
Manage the -EPROBE_DEFER error case for the wake IRQ.
Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com> Acked-by: Amelie Delaunay <amelie.delaunay@st.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
show more ...
|
Revision tags: v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3, v4.17.2, v4.17.1, v4.17 |
|
#
b72252b6 |
| 17-May-2018 |
Amelie Delaunay <amelie.delaunay@st.com> |
rtc: stm32: add stm32mp1 rtc support
This patch adds support for stm32mp1 RTC. Some common registers with previous RTC version have a different offset. It is the case for Control Register (CR) and A
rtc: stm32: add stm32mp1 rtc support
This patch adds support for stm32mp1 RTC. Some common registers with previous RTC version have a different offset. It is the case for Control Register (CR) and ALaRMA Register (ALRMAR). There are also new registers regarding event flags: now, Alarm event flag is in Status Register (SR) and write 1 in Status Clear Register (SCR) is required to clear the event.
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
show more ...
|
#
02b0cc34 |
| 17-May-2018 |
Amelie Delaunay <amelie.delaunay@st.com> |
rtc: stm32: rework register management to prepare other version of RTC
This patch reworks register/bits management because next version of RTC uses the same way of working but with different registe
rtc: stm32: rework register management to prepare other version of RTC
This patch reworks register/bits management because next version of RTC uses the same way of working but with different register's offset or bits moved in new registers.
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
show more ...
|
#
819cbde5 |
| 17-May-2018 |
Amelie Delaunay <amelie.delaunay@st.com> |
rtc: stm32: fix misspelling and misalignment issues
This patch cleans the following checkpatch complaints:
CHECK: 'initalized' may be misspelled - perhaps 'initialized'? #644: FILE: drivers/rtc/rtc
rtc: stm32: fix misspelling and misalignment issues
This patch cleans the following checkpatch complaints:
CHECK: 'initalized' may be misspelled - perhaps 'initialized'? #644: FILE: drivers/rtc/rtc-stm32.c:644: + * the calendar has been initalized or not. INITS flag is reset by a
CHECK: Alignment should match open parenthesis #669: FILE: drivers/rtc/rtc-stm32.c:669: + rtc->rtc_dev = devm_rtc_device_register(&pdev->dev, pdev->name, + &stm32_rtc_ops, THIS_MODULE);
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
show more ...
|
#
22cb47c1 |
| 19-Apr-2018 |
Amelie Delaunay <amelie.delaunay@st.com> |
rtc: stm32: get DBP register and mask from DT st, syscfg property
RTC driver should not be aware of the PWR registers offset and bits position. Furthermore, we can imagine that DBP relative register
rtc: stm32: get DBP register and mask from DT st, syscfg property
RTC driver should not be aware of the PWR registers offset and bits position. Furthermore, we can imagine that DBP relative register and bit mask could change depending on the SoC. So this patch introduces 2 parameters, dbp_reg and dbp_mask, allowing to get PWR_CR and PWR_CR_DBP from device tree. And it prepares next RTC version, backup domain write protection is disabled only if needed.
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
show more ...
|
#
d213217d |
| 19-Apr-2018 |
Amelie Delaunay <amelie.delaunay@st.com> |
rtc: stm32: fix alarm interrupt flags by removing IRQF_TRIGGER_RISING
RTC alarm interrupt is active high and already configured by device tree. So remove IRQF_TRIGGER_RISING from driver.
Signed-off
rtc: stm32: fix alarm interrupt flags by removing IRQF_TRIGGER_RISING
RTC alarm interrupt is active high and already configured by device tree. So remove IRQF_TRIGGER_RISING from driver.
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
show more ...
|