linux/rust/kernel/time, branch v6.18

rust: hrtimer: Add HrTimer::expires()

2025-09-04T14:54:39Z

Add a simple callback for retrieving the current expiry time for an HrTimer. In rvkms, we use the HrTimer expiry value in order to calculate the approximate vblank timestamp during each emulated vblank interrupt. Signed-off-by: Lyude Paul Reviewed-by: Andreas Hindborg Link: https://lore.kernel.org/r/20250821193259.964504-8-lyude@redhat.com Signed-off-by: Andreas Hindborg

rust: hrtimer: Add forward_now() to HrTimer and HrTimerCallbackContext

2025-09-04T14:54:39Z

Signed-off-by: Lyude Paul Reviewed-by: Daniel Almeida Reviewed-by: Andreas Hindborg Link: https://lore.kernel.org/r/20250821193259.964504-6-lyude@redhat.com Signed-off-by: Andreas Hindborg

rust: hrtimer: Add HrTimerCallbackContext and ::forward()

2025-09-04T14:54:39Z

With Linux's hrtimer API, there's a number of methods that can only be called in two situations: * When we have exclusive access to the hrtimer and it is not currently active * When we're within the context of an hrtimer callback context This commit handles the second situation and implements hrtimer_forward() support in the context of a timer callback. We do this by introducing a HrTimerCallbackContext type which is provided to users during the RawHrTimerCallback::run() callback, and then add a forward() function to the type. Signed-off-by: Lyude Paul Reviewed-by: Daniel Almeida Reviewed-by: Andreas Hindborg Link: https://lore.kernel.org/r/20250821193259.964504-5-lyude@redhat.com Signed-off-by: Andreas Hindborg

rust: hrtimer: Add HrTimer::raw_forward() and forward()

2025-09-04T14:54:39Z

Within the hrtimer API there are quite a number of functions that can only be safely called from one of two contexts: * When we have exclusive access to the hrtimer and the timer is not active. * When we're within the hrtimer's callback context as it is being executed. This commit adds bindings for hrtimer_forward() for the first such context, along with HrTimer::raw_forward() for later use in implementing the hrtimer_forward() in the latter context. Signed-off-by: Lyude Paul Reviewed-by: Daniel Almeida Reviewed-by: Andreas Hindborg Link: https://lore.kernel.org/r/20250821193259.964504-4-lyude@redhat.com Signed-off-by: Andreas Hindborg

rust: hrtimer: Add HrTimerInstant

2025-09-04T14:54:39Z

Since we want to add HrTimer methods that can accept Instants, we will want to make sure that for each method we are using the correct Clocksource for the given HrTimer. This would get a bit overly-verbose, so add a simple HrTimerInstant type-alias to handle this for us. Signed-off-by: Lyude Paul Reviewed-by: Andreas Hindborg Reviewed-by: Daniel Almeida Link: https://lore.kernel.org/r/20250821193259.964504-3-lyude@redhat.com Signed-off-by: Andreas Hindborg

rust: hrtimer: Document the return value for HrTimerHandle::cancel()

2025-09-04T14:54:39Z

Just a drive-by fix I noticed: we don't actually document what the return value from cancel() does, so do that. Signed-off-by: Lyude Paul Reviewed-by: Andreas Hindborg Reviewed-by: Daniel Almeida Link: https://lore.kernel.org/r/20250821193259.964504-2-lyude@redhat.com Signed-off-by: Andreas Hindborg

rust: time: Pass correct timer mode ID to hrtimer_start_range_ns

2025-07-16T22:55:35Z

While rebasing rvkms I noticed that timers I was setting seemed to have pretty random timer values that amounted slightly over 2x the time value I set each time. After a lot of debugging, I finally managed to figure out why: it seems that since we moved to Instant and Delta, we mistakenly began passing the clocksource ID to hrtimer_start_range_ns, when we should be passing the timer mode instead. Presumably, this works fine for simple relative timers - but immediately breaks on other types of timers. So, fix this by passing the ID for the timer mode instead. Signed-off-by: Lyude Paul Acked-by: Andreas Hindborg Reviewed-by: FUJITA Tomonori Fixes: e0c0ab04f678 ("rust: time: Make HasHrTimer generic over HrTimerMode") Link: https://lore.kernel.org/r/20250710225129.670051-1-lyude@redhat.com [ Removed cast, applied `rustfmt`, fixed `Fixes:` tag. - Miguel ] Signed-off-by: Miguel Ojeda

Merge tag 'rust-timekeeping-for-v6.17' of https://github.com/Rust-for-Linux/linux into rust-next

2025-07-16T21:45:08Z

Pull timekeeping updates from Andreas Hindborg: - Make 'Instant' generic over clock source. This allows the compiler to assert that arithmetic expressions involving the 'Instant' use 'Instants' based on the same clock source. - Make 'HrTimer' generic over the timer mode. 'HrTimer' timers take a 'Duration' or an 'Instant' when setting the expiry time, depending on the timer mode. With this change, the compiler can check the type matches the timer mode. - Add an abstraction for 'fsleep'. 'fsleep' is a flexible sleep function that will select an appropriate sleep method depending on the requested sleep time. - Avoid 64-bit divisions on 32-bit hardware when calculating timestamps. - Seal the 'HrTimerMode' trait. This prevents users of the 'HrTimerMode' from implementing the trait on their own types. * tag 'rust-timekeeping-for-v6.17' of https://github.com/Rust-for-Linux/linux: rust: time: Add wrapper for fsleep() function rust: time: Seal the HrTimerMode trait rust: time: Remove Ktime in hrtimer rust: time: Make HasHrTimer generic over HrTimerMode rust: time: Add HrTimerExpires trait rust: time: Replace HrTimerMode enum with trait-based mode types rust: time: Add ktime_get() to ClockSource trait rust: time: Make Instant generic over ClockSource rust: time: Replace ClockId enum with ClockSource trait rust: time: Avoid 64-bit integer division on 32-bit architectures

rust: types: rename Opaque::raw_get to cast_into

2025-07-15T20:26:11Z

In the previous patch we added Opaque::cast_from() that performs the opposite operation to Opaque::raw_get(). For consistency with this naming, rename raw_get() to cast_from(). There are a few other options such as calling cast_from() something closer to raw_get() rather than renaming this method. However, I could not find a great naming scheme that works with raw_get(). The previous version of this patch used from_raw(), but functions of that name typically have a different signature, so that's not a great option. Suggested-by: Danilo Krummrich Signed-off-by: Alice Ryhl Acked-by: Benno Lossin Acked-by: Andreas Hindborg Acked-by: Boqun Feng Reviewed-by: Danilo Krummrich Acked-by: Danilo Krummrich Link: https://lore.kernel.org/r/20250624-opaque-from-raw-v2-2-e4da40bdc59c@google.com [ Removed `HrTimer::raw_get` change. - Miguel ] Signed-off-by: Miguel Ojeda

rust: time: Add wrapper for fsleep() function

2025-06-30T11:22:05Z

Add a wrapper for fsleep(), flexible sleep functions in include/linux/delay.h which typically deals with hardware delays. The kernel supports several sleep functions to handle various lengths of delay. This adds fsleep(), automatically chooses the best sleep method based on a duration. fsleep() can only be used in a nonatomic context. This requirement is not checked by these abstractions, but it is intended that klint [1] or a similar tool will be used to check it in the future. Link: https://rust-for-linux.com/klint [1] Reviewed-by: Gary Guo Reviewed-by: Alice Ryhl Reviewed-by: Fiona Behrens Tested-by: Daniel Almeida Reviewed-by: Andreas Hindborg Signed-off-by: FUJITA Tomonori Link: https://lore.kernel.org/r/20250617144155.3903431-3-fujita.tomonori@gmail.com Signed-off-by: Andreas Hindborg