public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
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 resend 0/7] Timer driver module support
Date: Fri, 27 Mar 2026 19:05:52 +0100	[thread overview]
Message-ID: <20260327180600.8150-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



             reply	other threads:[~2026-03-27 18:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-27 18:05 Daniel Lezcano [this message]
2026-03-27 18:05 ` [PATCH resend v1 5/7] clocksource/drivers/rockchip: Use the TIMER_PDEV_DECLARE() macro Daniel Lezcano
2026-03-27 18:05 ` [PATCH resend v1 6/7] clocksource/drivers/rockchip: Add rockchip timer module support Daniel Lezcano
2026-03-27 18:05 ` [PATCH resend v1 7/7] clocksource/drivers/mediatek: Convert to " 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=20260327180600.8150-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