Add an `active()` method to HrTimer that returns true if the timer is in
the started or running states. This wraps the kernel's hrtimer_active()
function.

Also add documentation clarifying the definition of an active timer.

Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
---
 rust/kernel/time/hrtimer.rs | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/rust/kernel/time/hrtimer.rs b/rust/kernel/time/hrtimer.rs
index 856d2d929a008..b2272b059e504 100644
--- a/rust/kernel/time/hrtimer.rs
+++ b/rust/kernel/time/hrtimer.rs
@@ -66,6 +66,8 @@
 //!
 //! A `restart` operation on a timer in the **stopped** state is equivalent to a
 //! `start` operation.
+//!
+//! A timer is **active** if it is either in the **started** or **running** states.
 
 use super::{ClockSource, Delta, Instant};
 use crate::{prelude::*, types::Opaque};
@@ -246,6 +248,14 @@ pub fn expires(&self) -> HrTimerInstant<T>
             )
         }
     }
+
+    /// Query the state of the timer.
+    ///
+    /// Returns `true` if the timer is in the started or running states.
+    pub fn active(&self) -> bool {
+        // SAFETY: By type invariant, `self.timer` is valid.
+        unsafe { bindings::hrtimer_active(self.timer.get()) }
+    }
 }
 
 /// Implemented by pointer types that point to structs that contain a [`HrTimer`].

---
base-commit: 05f7e89ab9731565d8a62e3b5d1ec206485eeb0b
change-id: 20260215-hrtimer-active-f183411fe56b

Best regards,
-- 
Andreas Hindborg <a.hindborg@kernel.org>

On Sun, 15 Feb 2026 21:29:53 +0100
Andreas Hindborg <a.hindborg@kernel.org> wrote:

> Add an `active()` method to HrTimer that returns true if the timer is in
> the started or running states. This wraps the kernel's hrtimer_active()
> function.
> 
> Also add documentation clarifying the definition of an active timer.
> 
> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
> ---
>  rust/kernel/time/hrtimer.rs | 10 ++++++++++
>  1 file changed, 10 insertions(+)

Reviewed-by: FUJITA Tomonori <fujita.tomonori@gmail.com>

On Sun Feb 15, 2026 at 8:29 PM GMT, Andreas Hindborg wrote:
> Add an `active()` method to HrTimer that returns true if the timer is in
> the started or running states. This wraps the kernel's hrtimer_active()
> function.
>
> Also add documentation clarifying the definition of an active timer.
>
> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
> ---
>  rust/kernel/time/hrtimer.rs | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/rust/kernel/time/hrtimer.rs b/rust/kernel/time/hrtimer.rs
> index 856d2d929a008..b2272b059e504 100644
> --- a/rust/kernel/time/hrtimer.rs
> +++ b/rust/kernel/time/hrtimer.rs
> @@ -66,6 +66,8 @@
>  //!
>  //! A `restart` operation on a timer in the **stopped** state is equivalent to a
>  //! `start` operation.
> +//!
> +//! A timer is **active** if it is either in the **started** or **running** states.
>  
>  use super::{ClockSource, Delta, Instant};
>  use crate::{prelude::*, types::Opaque};
> @@ -246,6 +248,14 @@ pub fn expires(&self) -> HrTimerInstant<T>
>              )
>          }
>      }
> +
> +    /// Query the state of the timer.
> +    ///
> +    /// Returns `true` if the timer is in the started or running states.

This could be `#[inline]`.

> +    pub fn active(&self) -> bool {
> +        // SAFETY: By type invariant, `self.timer` is valid.

Perhaps also mention that this function is safe to call without exclusive
requirement, as this is a common requiremnt for many other hrtimer functions.

Best,
Gary

> +        unsafe { bindings::hrtimer_active(self.timer.get()) }
> +    }
>  }
>  
>  /// Implemented by pointer types that point to structs that contain a [`HrTimer`].
>
> ---
> base-commit: 05f7e89ab9731565d8a62e3b5d1ec206485eeb0b
> change-id: 20260215-hrtimer-active-f183411fe56b
>
> Best regards,

On Sun, Feb 15, 2026 at 9:30 PM Andreas Hindborg <a.hindborg@kernel.org> wrote:
>
> +    /// Query the state of the timer.
> +    ///
> +    /// Returns `true` if the timer is in the started or running states.

[`true`]

Since we try to add examples when we add APIs, could we perhaps add
one that inits a timers and asserts it is not active?

Thanks!

Cheers,
Miguel

On Sun, 15 Feb 2026 21:59:57 +0100
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:

> On Sun, Feb 15, 2026 at 9:30 PM Andreas Hindborg <a.hindborg@kernel.org> wrote:
>>
>> +    /// Query the state of the timer.
>> +    ///
>> +    /// Returns `true` if the timer is in the started or running states.
> 
> [`true`]

Should we use intra-doc links for true/flase? Currently, rust/kernel
doesn't seem to use them. Seems that Rust std library isn't consistent
on this either.

On Sat, Feb 28, 2026 at 3:23 AM FUJITA Tomonori <tomo@aliasing.net> wrote:
>
> Should we use intra-doc links for true/flase? Currently, rust/kernel
> doesn't seem to use them. Seems that Rust std library isn't consistent
> on this either.

Maybe... It doesn't matter much either way, obviously.

For simplicity/consistency with other "trivial" items, it may be
better. On the other hand, it is more painful to type and takes 2
characters.

This is the entry I have so far for this in my to-be-sent guidelines
"rules" list:

- Use intra-doc links wherever the link would work (i.e. if ``rustdoc``
  can resolve it), unless doing so would be unreasonably complex or
  verbose. In such a case, use a simple code span instead.

  Do so even for trivial types and constants, such as ``i32`` and
  ``true``, as well as for ``Self``.

  .. code-block:: rust

    /// Returns a new [`Foo`].

  Avoid:

  .. code-block:: rust

    /// Returns a new `Foo`.

Cheers,
Miguel

On Sat, Feb 28, 2026 at 04:04:27AM +0100, Miguel Ojeda wrote:
> On Sat, Feb 28, 2026 at 3:23 AM FUJITA Tomonori <tomo@aliasing.net> wrote:
> >
> > Should we use intra-doc links for true/flase? Currently, rust/kernel
> > doesn't seem to use them. Seems that Rust std library isn't consistent
> > on this either.
> 
> Maybe... It doesn't matter much either way, obviously.
> 
> For simplicity/consistency with other "trivial" items, it may be
> better. On the other hand, it is more painful to type and takes 2
> characters.
> 
> This is the entry I have so far for this in my to-be-sent guidelines
> "rules" list:
> 
> - Use intra-doc links wherever the link would work (i.e. if ``rustdoc``
>   can resolve it), unless doing so would be unreasonably complex or
>   verbose. In such a case, use a simple code span instead.
> 
>   Do so even for trivial types and constants, such as ``i32`` and
>   ``true``, as well as for ``Self``.
> 
>   .. code-block:: rust
> 
>     /// Returns a new [`Foo`].
> 
>   Avoid:
> 
>   .. code-block:: rust
> 
>     /// Returns a new `Foo`.

I'm not convinced by that. I don't think it's useful for `true` or
`Self` to be links in most cases.

Alice

On Sat, 28 Feb 2026 04:04:27 +0100
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:

> On Sat, Feb 28, 2026 at 3:23 AM FUJITA Tomonori <tomo@aliasing.net> wrote:
>>
>> Should we use intra-doc links for true/flase? Currently, rust/kernel
>> doesn't seem to use them. Seems that Rust std library isn't consistent
>> on this either.
> 
> Maybe... It doesn't matter much either way, obviously.
> 
> For simplicity/consistency with other "trivial" items, it may be
> better. On the other hand, it is more painful to type and takes 2
> characters.
> 
> This is the entry I have so far for this in my to-be-sent guidelines
> "rules" list:
> 
> - Use intra-doc links wherever the link would work (i.e. if ``rustdoc``
>   can resolve it), unless doing so would be unreasonably complex or
>   verbose. In such a case, use a simple code span instead.
> 
>   Do so even for trivial types and constants, such as ``i32`` and
>   ``true``, as well as for ``Self``.
> 
>   .. code-block:: rust
> 
>     /// Returns a new [`Foo`].
> 
>   Avoid:
> 
>   .. code-block:: rust
> 
>     /// Returns a new `Foo`.

Agreed, consistency alone is a good enough reason for this.