linux-kernel - Re: [PATCH RFC] timer: of: Create a platform_device before the framework is initialized

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAL_JsqLNQ729cwSEUnk5bNMjhJR7WTqcPPh1uL4suN1GhNhRMw@mail.gmail.com>
Date: Fri, 27 Jun 2025 08:34:18 -0500
From: Rob Herring <robh@...nel.org>
To: Daniel Lezcano <daniel.lezcano@...aro.org>
Cc: gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org, 
	lorenzo.pieralisi@...aro.org, Hans de Goede <hansg@...nel.org>, 
	Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>, 
	"Bryan O'Donoghue" <bryan.odonoghue@...aro.org>, Thomas Gleixner <tglx@...utronix.de>, 
	Arnd Bergmann <arnd@...db.de>, John Stultz <jstultz@...gle.com>, Stephen Boyd <sboyd@...nel.org>, 
	Saravana Kannan <saravanak@...gle.com>, 
	"open list:GENERIC INCLUDE/ASM HEADER FILES" <linux-arch@...r.kernel.org>, 
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE" <devicetree@...r.kernel.org>
Subject: Re: [PATCH RFC] timer: of: Create a platform_device before the
 framework is initialized

On Wed, Jun 25, 2025 at 3:57 AM Daniel Lezcano
<daniel.lezcano@...aro.org> wrote:
>
> In the context of the time keeping and the timers, some platforms have
> timers which need to be initialized very early. It is the case of the
> ARM platform which do not have the architected timers.
>
> The macro TIMER_OF_DECLARE adds an entry in the timer init functions
> array at compile time and the function timer_probe is called from the
> timer_init() function in kernel/time.c
>
> This array contains a t-uple with the init function and the compatible
> string.
>
> The init function has a device node pointer parameter.
>
> The timer_probe() function browses the of nodes and find the ones
> matching the compatible string given when using the TIMER_OF_DECLARE
> macro. It then calls the init function with the device node as a
> pointer.
>
> But there are some platforms where there are multiple timers like the
> ARM64 with the architected timers. Those are always initialized very
> early and the other timers can be initialized later.
>
> For this reason we find timer drivers with the platform_driver
> incarnation. Consequently their init functions are different, they
> have a platform_device pointer parameter and rely on the devm_
> function for rollbacking.
>
> To summarize, we have:
>  - TIMER_OF_DECLARE with init function prototype:
>    int (*init)(struct device_node *np);
>
>  - module_platform_driver (and variant) with the probe function
>    prototype:
>    int (*init)(struct platform_device *pdev);
>
> The current situation with the timers is the following:
>
>  - Two platforms can have the same timer hardware, hence the same
>    driver but one without alternate timers and the other with multiple
>    timers. For example, the Exynos platform has only the Exynos MCT on
>    ARM but has the architeched timers in addition on the ARM64.
>
>  - The timer drivers can be modules now which was not the case until
>    recently. TIMER_OF_DECLARE do not allow the build as a module.
>
> It results in duplicate init functions (one with rollback and one with
> devm_) and different way to declare the driver (TIMER_OF_DECLARE and
> module_platform_driver).
>
> This proposed change is to unify the prototyping of the init functions
> to receive a platform_device pointer as parameter. Consequently, it
> will allow a smoother and nicer module conversion and a huge cleanup
> of the init functions by removing all the rollback code from all the
> timer drivers. It introduces a TIMER_OF_DECLARE_PDEV macro.
>
> If the macro is used a platform_device is manually allocated and
> initialized with the needed information for the probe
> function. Otherwise module_platform_driver can be use instead with the
> same probe function without the timer_probe() initialization.
>
> I don't have an expert knowledge of the platform_device internal
> subtilitie so I'm not sure if this approach is valid. However, it has
> been tested on a Rockchip board with the "rockchip,rk3288-timer" and
> verified the macro and the devm_ rollback work correctly.

Have you looked at the SH "early_platform_driver"? How does this
compare? IIRC, that used to be generally available, but has been
pushed into SH since that was the only arch using it and no one likes
it.

Rob