From: Daniel Lezcano <daniel.lezcano@kernel.org>
To: daniel.lezcano@kernel.org, tglx@kernel.org, zhipeng.wang_1@nxp.com
Cc: shawnguo@kernel.org, jstultz@google.com,
linux-kernel@vger.kernel.org,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
linux-arm-kernel@lists.infradead.org (moderated
list:ARM/Mediatek SoC support),
linux-mediatek@lists.infradead.org (moderated list:ARM/Mediatek
SoC support)
Subject: [PATCH v1 0/7] Timer driver module support
Date: Fri, 27 Mar 2026 18:55:21 +0100 [thread overview]
Message-ID: <20260327175533.3044-1-daniel.lezcano@kernel.org> (raw)
Converting the timer driver modules requires a particular care
because, depending on the platform, that may be not supported.
A previous study showed we are safe regarding how the module refcount
is held and if THIS_MODULE is set for the clockevent and the
clocksource when they are registered.
It won't be possible to unload a module if a clockevent is registered.
It will be possible to unload a module if only a clocksource is
registered and it is not the current one.
However platforms without architected timers may need the timer driver
to be initialized very early and others can be initialized later. The
former can not be a module and the init function receives a
device_node pointer, there is no device associated and devres is not
used. That results in a lot of rollbacking code where usually it is
where we find bug and resource leaks. The latter can be converted to a
module and uses a module_platform_driver(), thus the init function is
a probe function receiving a struct platform_device pointer parameter.
We end up with two approaches and duplicate code for the init
functions. This is not optimal.
Finally, we have the driver having to be initialized very early on
some platforms and be built as a module on other platforms, resulting
on having two init functions co-existing in the same driver.
This series provides what is needed to move to the same probe function
for early init, builtin and module timers.
A new macro is introduced: TIMER_PDEV_DECLARE() and a new Kconfig
option is added CONFIG_EARLY_TIMER. TIMER_PDEV_DECLARE() will have
different behavior depending on the context:
- The driver is a module and CONFIG_EARLY_TIMER=no
--> the driver is a module
- The driver is builtin and CONFIG_EARLY_TIMER=no
--> the driver is loaded later
- The driver is builtin or a module but CONFIG_EARLY_TIMER=yes
--> the driver is initialized through the timer-probe function
The different timer driver framework functions have their __init
sections removed and the symbols exported in order to be compatible
with the drivers converted into modules.
The series provides a couple of drivers changed. The Mediatek as a
recent requested target which is only compiled-tested. The Rockchip
timer which was tested on a rk3588 in the three different
configurations.
Daniel Lezcano (7):
clocksource/drivers/timer-probe: Create a platform_device before the
framework is initialized
drivers/clocksource/rockchip: Use the TIMER_PDEV_DECLARE() macro
clocksource/drivers/mmio: Make the code compatible with modules
clocksource/drivers/timer-of: Make the code compatible with modules
clocksource/drivers/timer-probe: Add the module support for the
TIMER_PDEV_DECLARE() macro
clocksource/drivers/rockchip: Add rockchip timer module support
clocksource/drivers/mediatek: Convert to module support
drivers/clocksource/Kconfig | 7 +-
drivers/clocksource/mmio.c | 11 ++-
drivers/clocksource/timer-mediatek.c | 29 ++++++--
drivers/clocksource/timer-of.c | 24 ++++---
drivers/clocksource/timer-of.h | 5 +-
drivers/clocksource/timer-probe.c | 69 ++++++++++++++++--
drivers/clocksource/timer-rockchip.c | 101 ++++++++++-----------------
include/asm-generic/vmlinux.lds.h | 10 +++
include/linux/clocksource.h | 31 ++++++++
9 files changed, 194 insertions(+), 93 deletions(-)
--
2.43.0
next reply other threads:[~2026-03-27 17:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-27 17:55 Daniel Lezcano [this message]
2026-03-27 17:55 ` [PATCH v1 2/7] drivers/clocksource/rockchip: Use the TIMER_PDEV_DECLARE() macro Daniel Lezcano
2026-03-27 17:55 ` [PATCH v1 5/7] clocksource/drivers/rockchip: " Daniel Lezcano
2026-03-27 17:55 ` [PATCH v1 6/7] clocksource/drivers/rockchip: Add rockchip timer module support Daniel Lezcano
2026-03-27 17:55 ` [PATCH v1 7/7] clocksource/drivers/mediatek: Convert to " Daniel Lezcano
2026-03-27 18:02 ` [PATCH v1 0/7] Timer driver " Daniel Lezcano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260327175533.3044-1-daniel.lezcano@kernel.org \
--to=daniel.lezcano@kernel.org \
--cc=angelogioacchino.delregno@collabora.com \
--cc=jstultz@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=shawnguo@kernel.org \
--cc=tglx@kernel.org \
--cc=zhipeng.wang_1@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox