Re: [PATCH v3 4/8] drivers: arm_architected_timer: refactor for pbl compatibility

["Sascha Hauer" <s.hauer@pengutronix.de>]

On 2026-08-20 09:32, Stefan Kerkmann wrote:
> >> diff --git a/drivers/clocksource/arm_architected_timer.c b/drivers/clocksource/arm_architected_timer.c
> >> index daced94c0e..ea5f5b8e05 100644
> >> --- a/drivers/clocksource/arm_architected_timer.c
> >> +++ b/drivers/clocksource/arm_architected_timer.c
> >> @@ -9,6 +9,7 @@
> >>  #include <linux/clk.h>
> >>  #include <io.h>
> >>  #include <asm/system.h>
> >> +#include <asm/hardware/arm_architected_timer.h>
> >>  
> >>  static uint64_t arm_arch_clocksource_read(void)
> >>  {
> >> @@ -22,22 +23,29 @@ static struct clocksource cs = {
> >>  	.priority = 70,
> >>  };
> >>  
> >> -static int arm_arch_timer_probe(struct device *dev)
> >> +int arm_arch_timer_init(uint64_t cntfrq)
> >>  {
> >> -	u32 cntfrq;
> >> -	int ret;
> >> -
> >> -	/* Some platforms don't set CNTFRQ_EL0 before barebox */
> >> -	ret = of_property_read_u32(dev->of_node, "clock-frequency", &cntfrq);
> >> -
> >> -	if (ret)
> >> +	if (!cntfrq)
> >>  		cntfrq = get_cntfrq();
> > 
> > I wonder if we should just drop the cntfrq argument. All users call
> > set_cntfrq() before calling this, so get_cntfrq() should return the
> > correct value and we can rely on it.
> > 
> 
> Maybe keep the argument and use set_cntfrq in arm_arch_timer_init if the
> argument is !=0? Then arm_arch_timer_init is the function to use if a C
> environment is available? This would prevent any inconsistency.

I am not sure, but set_cntfrq() might only be usable in EL3, so you
would have to be careful about the exception level when calling
arm_arch_timer_init() with a non zero argument.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |