devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: William McVicker <willmcvicker@google.com>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: "John Stultz" <jstultz@google.com>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Will Deacon" <will@kernel.org>,
	"Peter Griffin" <peter.griffin@linaro.org>,
	"André Draszik" <andre.draszik@linaro.org>,
	"Tudor Ambarus" <tudor.ambarus@linaro.org>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Alim Akhtar" <alim.akhtar@samsung.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Saravana Kannan" <saravanak@google.com>,
	"Krzysztof Kozlowski" <krzk@kernel.org>,
	"Donghoon Yu" <hoony.yu@samsung.com>,
	"Hosung Kim" <hosung0.kim@samsung.com>,
	kernel-team@android.com, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	"Youngmin Nam" <youngmin.nam@samsung.com>,
	linux-samsung-soc@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v2 6/7] clocksource/drivers/exynos_mct: Add module support
Date: Wed, 14 May 2025 16:16:07 -0700	[thread overview]
Message-ID: <aCUkN301jWUkXJ3_@google.com> (raw)
In-Reply-To: <aCNctHq6K7uqFF05@mai.linaro.org>

On 05/13/2025, Daniel Lezcano wrote:
> On Tue, Apr 15, 2025 at 05:48:41PM -0700, John Stultz wrote:
> > On Tue, Apr 15, 2025 at 9:50 AM Daniel Lezcano
> > <daniel.lezcano@linaro.org> wrote:
> > > On Wed, Apr 02, 2025 at 04:33:57PM -0700, Will McVicker wrote:
> > > > From: Donghoon Yu <hoony.yu@samsung.com>
> > > >
> > > > On Arm64 platforms the Exynos MCT driver can be built as a module. On
> > > > boot (and even after boot) the arch_timer is used as the clocksource and
> > > > tick timer. Once the MCT driver is loaded, it can be used as the wakeup
> > > > source for the arch_timer.
> > >
> > > From a previous thread where there is no answer:
> > >
> > > https://lore.kernel.org/all/c1e8abec-680c-451d-b5df-f687291aa413@linaro.org/
> > >
> > > I don't feel comfortable with changing the clocksource / clockevent drivers to
> > > a module for the reasons explained in the aforementionned thread.
> > 
> > I wasn't CC'ed on that, but to address a few of your points:
> > 
> > > I have some concerns about this kind of changes:
> > >
> > >   * the core code may not be prepared for that, so loading / unloading
> > > the modules with active timers may result into some issues
> > 
> > That's a fair concern, but permanent modules (which are loaded but not
> > unloaded) shouldn't suffer this issue. I recognize having modules be
> > fully unloadable is generally cleaner and preferred, but I also see
> > the benefit of allowing permanent modules to be one-way loaded so a
> > generic/distro kernel shared between lots of different platforms
> > doesn't need to be bloated with drivers that aren't used everywhere.
> > Obviously any single driver doesn't make a huge difference, but all
> > the small drivers together does add up.
> 
> Perhaps using module_platform_driver_probe() should do the trick with
> some scripts updated for my git hooks to check
> module_platform_driver() is not used.

Using `module_platform_driver_probe()` won't work as that still defines
a `module_exit()` hook. If you want to automatically handle this in code, then
the best approach is to follow what Saravana did in [1] for irqchip drivers.
Basically by using `builtin_platform_driver(drv_name##_driver)`, you will only
define the `module_init()` hook when the driver is compiled as a module which
ensures you always get a permanent module.

[1] https://lore.kernel.org/linux-arm-kernel/20200718000637.3632841-1-saravanak@google.com/

Regards,
Will

[...]

  reply	other threads:[~2025-05-14 23:16 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20250402233425epcas2p479285add99d27dc18aabd2295bfcbdc8@epcas2p4.samsung.com>
2025-04-02 23:33 ` [PATCH v2 0/7] Add module support for Arm64 Exynos MCT driver Will McVicker
2025-04-02 23:33   ` [PATCH v2 1/7] of/irq: Export of_irq_count for modules Will McVicker
2025-04-02 23:33   ` [PATCH v2 2/7] clocksource/drivers/exynos_mct: Don't register as a sched_clock on arm64 Will McVicker
2025-04-02 23:51     ` John Stultz
2025-04-08 19:57       ` William McVicker
2025-04-02 23:33   ` [PATCH v2 3/7] clocksource/drivers/exynos_mct: Set local timer interrupts as percpu Will McVicker
2025-05-08 10:12     ` Peter Griffin
2025-04-02 23:33   ` [PATCH v2 4/7] arm64: dts: exynos: gs101: Add 'local-timer-stop' to cpuidle nodes Will McVicker
2025-05-08 10:11     ` Peter Griffin
2025-04-02 23:33   ` [PATCH v2 5/7] clocksource/drivers/exynos_mct: Fix uninitialized irq name warning Will McVicker
2025-05-08 10:19     ` Peter Griffin
2025-04-02 23:33   ` [PATCH v2 6/7] clocksource/drivers/exynos_mct: Add module support Will McVicker
2025-04-15 16:50     ` Daniel Lezcano
2025-04-15 21:25       ` William McVicker
2025-04-16 11:15         ` Daniel Lezcano
2025-05-08 11:44           ` Peter Griffin
2025-04-16  0:48       ` John Stultz
2025-04-16 13:46         ` Daniel Lezcano
2025-04-16 19:48           ` John Stultz
2025-04-16 21:00             ` John Stultz
2025-05-13 14:52         ` Daniel Lezcano
2025-05-14 23:16           ` William McVicker [this message]
2025-05-23 15:03             ` Daniel Lezcano
2025-05-23 17:06               ` William McVicker
2025-05-23 18:06                 ` Saravana Kannan
2025-05-23 20:39                   ` Daniel Lezcano
2025-04-02 23:33   ` [PATCH v2 7/7] arm64: exynos: Drop select CLKSRC_EXYNOS_MCT Will McVicker
2025-04-04  1:11   ` [PATCH v2 0/7] Add module support for Arm64 Exynos MCT driver Youngmin Nam
2025-04-04  6:02     ` Krzysztof Kozlowski
2025-04-04  6:17       ` Youngmin Nam
2025-04-08 19:57     ` William McVicker

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=aCUkN301jWUkXJ3_@google.com \
    --to=willmcvicker@google.com \
    --cc=alim.akhtar@samsung.com \
    --cc=andre.draszik@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=conor+dt@kernel.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=hoony.yu@samsung.com \
    --cc=hosung0.kim@samsung.com \
    --cc=jstultz@google.com \
    --cc=kernel-team@android.com \
    --cc=krzk+dt@kernel.org \
    --cc=krzk@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=peter.griffin@linaro.org \
    --cc=robh@kernel.org \
    --cc=saravanak@google.com \
    --cc=tglx@linutronix.de \
    --cc=tudor.ambarus@linaro.org \
    --cc=will@kernel.org \
    --cc=youngmin.nam@samsung.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;
as well as URLs for NNTP newsgroup(s).