Clockevents cannot be deregistered so suppress driver bind attributes to
prevent drivers from being unbound and, for example, releasing
underlying resources after registration.

Note that the NXP STM patch depends on the recently submitted section
mismatch fix. [1]

Johan


[1] https://lore.kernel.org/lkml/20251017054943.7195-1-johan@kernel.org/


Johan Hovold (3):
  clocksource/drivers/arm_arch_timer_mmio: Prevent driver unbind
  clocksource/drivers/nxp-pit: Prevent driver unbind
  clocksource/drivers/nxp-stm: Prevent driver unbind

 drivers/clocksource/arm_arch_timer_mmio.c | 2 ++
 drivers/clocksource/timer-nxp-pit.c       | 3 ++-
 drivers/clocksource/timer-nxp-stm.c       | 3 ++-
 3 files changed, 6 insertions(+), 2 deletions(-)

-- 
2.51.0

Hi Johan,

On 11/11/25 16:32, Johan Hovold wrote:
> Clockevents cannot be deregistered so suppress driver bind attributes to
> prevent drivers from being unbound and, for example, releasing
> underlying resources after registration.

For non architected timers, we want to be able to convert the timers as 
modules.

That's an on-going work [1].

Your series assumes we won't convert that into modules, so you do the 
conversion to builtin. But actually, there is a slow move to module 
conversion.

However, given a clockevent can not be unregistered, the 
'suppress_bind_attrs' flag makes sense for those registering one.

   -- Daniel


[1] 
https://lore.kernel.org/all/20250602151853.1942521-1-daniel.lezcano@linaro.org/

-- 
<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

On Wed, Nov 12, 2025 at 10:48:22AM +0100, Daniel Lezcano wrote:

> On 11/11/25 16:32, Johan Hovold wrote:
> > Clockevents cannot be deregistered so suppress driver bind attributes to
> > prevent drivers from being unbound and, for example, releasing
> > underlying resources after registration.
> 
> For non architected timers, we want to be able to convert the timers as 
> modules.
> 
> That's an on-going work [1].
> 
> Your series assumes we won't convert that into modules, so you do the 
> conversion to builtin. But actually, there is a slow move to module 
> conversion.

No, that's not the case. The builtin_platform_driver macro still allows
building drivers as modules, it just prevents unloading them.

Johan