linux-kernel - Re: [PATCH] clocksource/drivers/timer-ti-dm: add module build support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <c1e8abec-680c-451d-b5df-f687291aa413@linaro.org>
Date: Wed, 5 Mar 2025 10:43:05 +0100
From: Daniel Lezcano <daniel.lezcano@...aro.org>
To: Guillaume La Roque <glaroque@...libre.com>,
 Thomas Gleixner <tglx@...utronix.de>
Cc: Nishanth Menon <nm@...com>, Andrew Davis <afd@...com>,
 mkorpershoek@...libre.com, linux-kernel@...r.kernel.org,
 Linux PM mailing list <linux-pm@...r.kernel.org>
Subject: Re: [PATCH] clocksource/drivers/timer-ti-dm: add module build support

On 20/02/2025 15:31, Guillaume La Roque wrote:
> Add missing MODULE_LICENSE variable and convert bool to tristate in
> Kconfig to be able to build driver in module.
> 
> By default this driver was set at y when ARCH_K3=y.
> 
> Signed-off-by: Guillaume La Roque <glaroque@...libre.com>
> ---
> Enable possibility to build in module timer-ti-dm driver needed in
> Android context and Android Generic Kernel Image support.
> 
> I know any other clicksource driver support module build but i do test on AM62X and
> AM62P EVM board and i able to use this driver and test it with PWM.
> 
> By default this driver will be always enable in bultin when ARCH_K3=y so
> no impact for other TI SoC.
> ---

Thomas, Guillaume

there are several requests to convert the built-in timers code into 
modules since Android is converted to a GKI.

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

  * it may end up with some interactions with cpuidle at boot time and 
the broadcast timer

  * the timekeeping may do jump in the past [if and] when switching the 
clocksource

  * the GKI approach is to have an update for the 'mainline' kernel and 
let the different SoC vendors deal with their drivers. I'm afraid this 
will prevent driver fixes to be carry on upstream because they will stay 
in the OoT kernels

For all these reasons, I don't think we can take the module change as is 
without figuring out the three first technical reasons (the last one is 
from an upstream maintainer POV)

Thoughts?

Thanks

   -- Daniel




-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog