[PATCH] clocksource: Update registration failure behavior documentation

[PATCH] clocksource: Update registration failure behavior documentation

[Zhan Xusheng]

The documentation for clocksource registration functions has been updated
to clarify the failure behavior. Specifically, the return value on failure
is no longer an error code (-EBUSY). Instead, the function will issue
warnings but always return 0 on failure, as previously successful
registration attempts might still leave the system in an inconsistent
state.

Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
---
 kernel/time/clocksource.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index df7194961658..6a56282dbd08 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -1228,7 +1228,8 @@ EXPORT_SYMBOL_GPL(__clocksource_update_freq_scale);
  * @scale:	Scale factor multiplied against freq to get clocksource hz
  * @freq:	clocksource frequency (cycles per second) divided by scale
  *
- * Returns -EBUSY if registration fails, zero otherwise.
+ * Returns 0 on success. On failure, it will issue warnings but will not return
+ * a specific error code.
  *
  * This *SHOULD NOT* be called directly! Please use the
  * clocksource_register_hz() or clocksource_register_khz helper functions.
-- 
2.43.0

Re: [PATCH] clocksource: Update registration failure behavior documentation

[Thomas Gleixner]

On Tue, Feb 10 2026 at 10:56, Zhan Xusheng wrote:
> The documentation for clocksource registration functions has been updated
> to clarify the failure behavior. Specifically, the return value on failure
> is no longer an error code (-EBUSY). Instead, the function will issue
> warnings but always return 0 on failure, as previously successful
> registration attempts might still leave the system in an inconsistent
> state.

This changelog is completely made up. Which failure is ignored there and
whats the inconsistent state of a previous attempt?

The -EBUSY comment is a leftover from the original implementation. and
the pr_warn() about the vdso clock mode is harmless as it still leaves
the system in a consistent state. Just the VDSO functionality is not
enabled.

This AI slop starts to become annoying.

Thanks,

        tglx