[PATCH 1/9] rust: sync: completion: add single-shot and timed operations

[PATCH 1/9] rust: sync: completion: add single-shot and timed operations

[Mike Lothian]

Expose complete() and wait_for_completion_timeout() so Rust drivers
can coordinate asynchronous completions without open-coding access
to struct completion.

Assisted-by: Claude:claude-opus-5
Signed-off-by: Mike Lothian <mike@fireburn.co.uk>
---
 rust/kernel/sync/completion.rs | 25 ++++++++++++++++++++++++-
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/rust/kernel/sync/completion.rs b/rust/kernel/sync/completion.rs
index 35ff049ff078..df4f6e11ef37 100644
--- a/rust/kernel/sync/completion.rs
+++ b/rust/kernel/sync/completion.rs
@@ -6,7 +6,12 @@
 //!
 //! C header: [`include/linux/completion.h`](srctree/include/linux/completion.h)
 
-use crate::{bindings, prelude::*, types::Opaque};
+use crate::{
+    bindings,
+    prelude::*,
+    time::Jiffies,
+    types::Opaque, //
+};
 
 /// Synchronization primitive to signal when a certain task has been completed.
 ///
@@ -90,6 +95,15 @@ fn as_raw(&self) -> *mut bindings::completion {
         self.inner.get()
     }
 
+    /// Signal one task waiting for this completion.
+    ///
+    /// If no task is waiting, the signal is retained and consumed by a future waiter.
+    #[inline]
+    pub fn complete(&self) {
+        // SAFETY: `self.as_raw()` is a pointer to a valid `struct completion`.
+        unsafe { bindings::complete(self.as_raw()) };
+    }
+
     /// Signal all tasks waiting on this completion.
     ///
     /// This method wakes up all tasks waiting on this completion; after this operation the
@@ -111,4 +125,13 @@ pub fn wait_for_completion(&self) {
         // SAFETY: `self.as_raw()` is a pointer to a valid `struct completion`.
         unsafe { bindings::wait_for_completion(self.as_raw()) };
     }
+
+    /// Wait at most `timeout` jiffies for one completion signal.
+    ///
+    /// Returns `true` after consuming a signal and `false` when the timeout expires.
+    #[inline]
+    pub fn wait_for_completion_timeout(&self, timeout: Jiffies) -> bool {
+        // SAFETY: `self.as_raw()` is a pointer to a valid `struct completion`.
+        unsafe { bindings::wait_for_completion_timeout(self.as_raw(), timeout) != 0 }
+    }
 }

[PATCH 2/9] rust: hrtimer: add ArcHrTimerHandle::restart

[Mike Lothian]

Restarting an already-started timer through the safe API means dropping
its handle and calling `HrTimerPointer::start()` again. Dropping the
handle cancels, and cancelling blocks until a running callback returns,
so this is unavailable to any caller that cannot sleep -- a driver
re-arming its timer from a callback invoked with interrupts disabled,
say. Such drivers fall back to the unsafe `HasHrTimer::start()`
on a raw pointer.

Add `restart()` on the handle. It re-queues the timer in place without
cancelling first. It is safe because the handle already owns the
`Arc` that keeps the timer alive and still cancels it on drop, which
is exactly what `HasHrTimer::start()` requires of its caller.

Assisted-by: Claude:claude-opus-5
Signed-off-by: Mike Lothian <mike@fireburn.co.uk>
---
 rust/kernel/time/hrtimer/arc.rs | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/rust/kernel/time/hrtimer/arc.rs b/rust/kernel/time/hrtimer/arc.rs
index 7be82bcb352a..f7cd46dbd3d3 100644
--- a/rust/kernel/time/hrtimer/arc.rs
+++ b/rust/kernel/time/hrtimer/arc.rs
@@ -39,6 +39,29 @@ fn cancel(&mut self) -> bool {
     }
 }
 
+impl<T> ArcHrTimerHandle<T>
+where
+    T: HasHrTimer<T>,
+{
+    /// Restart the timer with a new expiry time, without cancelling it first.
+    ///
+    /// If the timer is queued it is removed and re-inserted at the new expiry; if it has already
+    /// expired it is queued again. Unlike dropping the handle and calling
+    /// [`HrTimerPointer::start`] again, this never blocks waiting for a running callback, so it
+    /// can be used from contexts that cannot sleep -- re-arming a timer from a driver callback
+    /// invoked with interrupts disabled, for instance.
+    ///
+    /// This handle keeps its timer alive and still cancels it on drop, so the timer cannot outlive
+    /// the restart.
+    pub fn restart(&self, expires: <<T as HasHrTimer<T>>::TimerMode as HrTimerMode>::Expires) {
+        // SAFETY:
+        // - `self.inner` is a live `Arc<T>` held by this handle, so the pointer is valid.
+        // - The caller cannot leak past the timer's death: this handle owns the `Arc` and cancels
+        //   the timer when dropped, which is the requirement `HasHrTimer::start` places on us.
+        unsafe { T::start(Arc::as_ptr(&self.inner), expires) };
+    }
+}
+
 impl<T> Drop for ArcHrTimerHandle<T>
 where
     T: HasHrTimer<T>,

Re: [PATCH 2/9] rust: hrtimer: add ArcHrTimerHandle::restart

[Andreas Hindborg]

"Mike Lothian" <mike@fireburn.co.uk> writes:

> Restarting an already-started timer through the safe API means dropping
> its handle and calling `HrTimerPointer::start()` again. Dropping the
> handle cancels, and cancelling blocks until a running callback returns,
> so this is unavailable to any caller that cannot sleep -- a driver
> re-arming its timer from a callback invoked with interrupts disabled,
> say. Such drivers fall back to the unsafe `HasHrTimer::start()`
> on a raw pointer.
>
> Add `restart()` on the handle. It re-queues the timer in place without
> cancelling first. It is safe because the handle already owns the
> `Arc` that keeps the timer alive and still cancels it on drop, which
> is exactly what `HasHrTimer::start()` requires of its caller.

The intention is that handlers use the `forward` method on the context
object in combination with return value `HrTimerRestart::Restart` to re
arm the timer.

However, we found a data race in the face of concurrent `start`
operations, so we are solving that over at [1].


Best regards,
Andreas Hindborg


[1] https://lore.kernel.org/rust-for-linux/20260825-expires-v2-v1-0-90411c6217c7@kernel.org/T/#t

Re: [PATCH 2/9] rust: hrtimer: add ArcHrTimerHandle::restart

[Andreas Hindborg]

"Mike Lothian" <mike@fireburn.co.uk> writes:

Hi Mike,

Please note that HTML messages are rejected by lore.

> On Thu, 27 Aug 2026, Andreas Hindborg wrote:
>> The intention is that handlers use the `forward` method on the context
>> object in combination with return value `HrTimerRestart::Restart` to re
>> arm the timer.
>>
>> However, we found a data race in the face of concurrent `start`
>> operations, so we are solving that over at [1].
>
> You are right, and checking properly, the driver that motivated this does
> not need it: its callback already ends with
>
> ctx.forward_now(Delta::from_nanos(interval));
> HrTimerRestart::Restart
>
> and nothing anywhere calls the handle's restart(). I will drop this patch
> rather than carry an API with no user, and rebase the rest on your
> expires-v2 series.
>
> Thanks for the pointer.

You are welcome :)

Best regards,
Andreas Hindborg

Re: [PATCH 2/9] rust: hrtimer: add ArcHrTimerHandle::restart

[Mike Lothian]

Sorry, I take that back - it does have a caller, I grepped for
".restart()", vino calls it in enable_vblank:

    h.restart(Delta::from_nanos(interval));

I'd like to keep it for v4 or does expires-v2 change it? If the
concurrent-start race is fixed there I'd rather rebase onto that than
carry something that races


Mike

[PATCH 3/9] rust: random: add a safe get_random_bytes wrapper

[Mike Lothian]

Expose a slice-based wrapper around get_random_bytes() so Rust callers
can fill key, nonce, and other random buffers without touching raw
pointers.

Assisted-by: Claude:claude-opus-5
Signed-off-by: Mike Lothian <mike@fireburn.co.uk>
---
 rust/kernel/lib.rs    |  1 +
 rust/kernel/random.rs | 34 ++++++++++++++++++++++++++++++++++
 2 files changed, 35 insertions(+)
 create mode 100644 rust/kernel/random.rs

diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
index 08e5730753eb..f39648246271 100644
--- a/rust/kernel/lib.rs
+++ b/rust/kernel/lib.rs
@@ -116,6 +116,7 @@
 pub mod ptr;
 #[cfg(CONFIG_RUST_PWM_ABSTRACTIONS)]
 pub mod pwm;
+pub mod random;
 pub mod rbtree;
 pub mod regulator;
 pub mod revocable;
diff --git a/rust/kernel/random.rs b/rust/kernel/random.rs
new file mode 100644
index 000000000000..5f2288969dbf
--- /dev/null
+++ b/rust/kernel/random.rs
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! Random number generation.
+//!
+//! C header: [`include/linux/random.h`](srctree/include/linux/random.h)
+
+use crate::bindings;
+
+/// Fills `buf` with cryptographically secure random bytes from the kernel's CSPRNG.
+///
+/// This is the in-kernel equivalent of reading from `/dev/urandom`, and is suitable for generating
+/// keys, nonces and other secrets. It never blocks: once the CSPRNG has been seeded during boot it
+/// stays seeded, and callers running that early should use
+/// [`wait_for_random_bytes()`] instead of assuming otherwise.
+///
+/// [`wait_for_random_bytes()`]: srctree/include/linux/random.h
+///
+/// # Examples
+///
+/// ```
+/// use kernel::random;
+///
+/// let mut key = [0u8; 16];
+/// random::fill_bytes(&mut key);
+///
+/// // A zero-length request is valid and does nothing.
+/// random::fill_bytes(&mut []);
+/// ```
+#[inline]
+pub fn fill_bytes(buf: &mut [u8]) {
+    // SAFETY: `buf` is a valid slice, so its pointer is valid for writes of `buf.len()` bytes, and
+    // `get_random_bytes()` writes exactly that many.
+    unsafe { bindings::get_random_bytes(buf.as_mut_ptr().cast(), buf.len()) };
+}

[PATCH 4/9] rust: xxhash: add a safe xxh64 wrapper

[Mike Lothian]

Expose xxh64() through a slice-based Rust API for non-cryptographic
hashing such as framebuffer damage detection.

Assisted-by: Claude:claude-opus-5
Signed-off-by: Mike Lothian <mike@fireburn.co.uk>
---
 rust/bindings/bindings_helper.h |  1 +
 rust/kernel/lib.rs              |  1 +
 rust/kernel/xxhash.rs           | 68 +++++++++++++++++++++++++++++++++
 3 files changed, 70 insertions(+)
 create mode 100644 rust/kernel/xxhash.rs

diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
index 1124785e210b..2d079f278a04 100644
--- a/rust/bindings/bindings_helper.h
+++ b/rust/bindings/bindings_helper.h
@@ -93,6 +93,7 @@
 #include <linux/wait.h>
 #include <linux/workqueue.h>
 #include <linux/xarray.h>
+#include <linux/xxhash.h>
 #include <trace/events/rust_sample.h>
 
 /*
diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
index f39648246271..d7ced2a4c11f 100644
--- a/rust/kernel/lib.rs
+++ b/rust/kernel/lib.rs
@@ -141,6 +141,7 @@
 pub mod usb;
 pub mod workqueue;
 pub mod xarray;
+pub mod xxhash;
 
 #[doc(hidden)]
 pub use bindings;
diff --git a/rust/kernel/xxhash.rs b/rust/kernel/xxhash.rs
new file mode 100644
index 000000000000..fca24cddef46
--- /dev/null
+++ b/rust/kernel/xxhash.rs
@@ -0,0 +1,68 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! xxHash, a fast non-cryptographic hash function.
+//!
+//! C header: [`include/linux/xxhash.h`](srctree/include/linux/xxhash.h)
+
+use core::mem::MaybeUninit;
+
+use crate::{bindings, error::to_result, prelude::*};
+
+/// Incremental xxHash64 state.
+///
+/// Use this when the input is split across several buffers. Calling
+/// [`update`](Self::update) for each buffer produces the same digest as hashing
+/// their concatenation with [`xxh64`].
+pub struct Xxh64(bindings::xxh64_state);
+
+impl Xxh64 {
+    /// Start a new hash with `seed`.
+    pub fn new(seed: u64) -> Self {
+        let mut state = MaybeUninit::uninit();
+        // SAFETY: `xxh64_reset()` initializes every byte of the state before
+        // returning.
+        unsafe {
+            bindings::xxh64_reset(state.as_mut_ptr(), seed);
+            Self(state.assume_init())
+        }
+    }
+
+    /// Add `data` to the hash.
+    pub fn update(&mut self, data: &[u8]) -> Result {
+        // SAFETY: `self.0` is initialized and exclusively borrowed; `data` is
+        // valid for reads of `data.len()` bytes.
+        to_result(unsafe { bindings::xxh64_update(&mut self.0, data.as_ptr().cast(), data.len()) })
+    }
+
+    /// Return the current digest without consuming the state.
+    pub fn digest(&self) -> u64 {
+        // SAFETY: `self.0` was initialized by `xxh64_reset()` and remains live.
+        unsafe { bindings::xxh64_digest(&self.0) }
+    }
+}
+
+/// Returns the 64-bit xxHash of `data`, starting from `seed`.
+///
+/// This is a non-cryptographic hash: use it for change detection, bucketing and similar, never for
+/// anything security-relevant.
+///
+/// # Examples
+///
+/// ```
+/// use kernel::xxhash::xxh64;
+///
+/// // The same input and seed always produce the same hash.
+/// assert_eq!(xxh64(b"hello", 0), xxh64(b"hello", 0));
+///
+/// // Different seeds produce different hashes.
+/// assert_ne!(xxh64(b"hello", 0), xxh64(b"hello", 1));
+///
+/// // Hashing the empty slice is well-defined.
+/// let _ = xxh64(&[], 0);
+/// ```
+#[inline]
+pub fn xxh64(data: &[u8], seed: u64) -> u64 {
+    // SAFETY: `data` is a valid slice, so its pointer is valid for reads of `data.len()` bytes,
+    // and `xxh64()` only reads from it for the duration of the call.
+    unsafe { bindings::xxh64(data.as_ptr().cast(), data.len(), seed) }
+}

[PATCH 5/9] rust: workqueue: make OwnedQueue thread-safe

[Mike Lothian]

OwnedQueue only owns a pointer to Queue, whose operations are already
Send and Sync. Propagate those guarantees so drivers can keep an
owned queue in shared device state.

Assisted-by: Claude:claude-opus-5
Signed-off-by: Mike Lothian <mike@fireburn.co.uk>
---
 rust/kernel/workqueue/mod.rs | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/rust/kernel/workqueue/mod.rs b/rust/kernel/workqueue/mod.rs
index e30c21214a81..000a29c9dc1a 100644
--- a/rust/kernel/workqueue/mod.rs
+++ b/rust/kernel/workqueue/mod.rs
@@ -380,6 +380,12 @@ pub struct OwnedQueue {
     queue: NonNull<Queue>,
 }
 
+// SAFETY: `Queue` operations are thread-safe and ownership may be transferred
+// between threads.
+unsafe impl Send for OwnedQueue {}
+// SAFETY: Shared access only exposes the thread-safe `Queue` API.
+unsafe impl Sync for OwnedQueue {}
+
 impl Deref for OwnedQueue {
     type Target = Queue;
     fn deref(&self) -> &Queue {

[PATCH 6/9] rust: io: add checked offset copy helpers

[Mike Lothian]

I/O mappings often need to copy a bounded byte range rather than
the complete mapping. Add checked helpers that project the requested
range before using the backend copy operation. This keeps raw backend
pointers out of consumers and reports invalid ranges instead.

Assisted-by: Claude:claude-opus-5
Signed-off-by: Mike Lothian <mike@fireburn.co.uk>
---
 rust/kernel/io.rs | 50 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)

diff --git a/rust/kernel/io.rs b/rust/kernel/io.rs
index 95f46bb75f9e..aea346b8b79e 100644
--- a/rust/kernel/io.rs
+++ b/rust/kernel/io.rs
@@ -225,6 +225,30 @@ fn io_view<'a, IO: Io<'a>, U>(
     Ok(unsafe { IO::Backend::project_view(view, projected_ptr) })
 }
 
+/// Returns a byte-slice view for a given range, performing runtime bounds checks.
+#[inline]
+fn io_byte_slice<'a, IO>(
+    this: IO,
+    offset: usize,
+    len: usize,
+) -> Result<<IO::Backend as IoBackend>::View<'a, [u8]>>
+where
+    IO: Io<'a, Target = [u8]>,
+{
+    let view = this.as_view();
+    let ptr = IO::Backend::as_ptr(view);
+    let end = offset.checked_add(len).ok_or(EINVAL)?;
+
+    if end > ptr.len() {
+        return Err(EINVAL);
+    }
+
+    let projected_ptr =
+        core::ptr::slice_from_raw_parts_mut(ptr.cast::<u8>().wrapping_add(offset), len);
+    // SAFETY: The bounds check above proves that `projected_ptr` is a sub-slice of `ptr`.
+    Ok(unsafe { IO::Backend::project_view(view, projected_ptr) })
+}
+
 /// I/O backends.
 ///
 /// This is an abstract representation to be implemented by arbitrary I/O
@@ -640,6 +664,32 @@ fn copy_to_slice(self, data: &mut [u8])
         }
     }
 
+    /// Copy bytes from `data` to a range of I/O memory.
+    ///
+    /// Returns [`EINVAL`] if `offset..offset + data.len()` is outside the I/O region.
+    #[inline]
+    fn try_copy_from_slice(self, offset: usize, data: &[u8]) -> Result
+    where
+        Self::Backend: IoCopyable,
+        Self: Io<'a, Target = [u8]>,
+    {
+        io_byte_slice(self, offset, data.len())?.copy_from_slice(data);
+        Ok(())
+    }
+
+    /// Copy a range of I/O memory to `data`.
+    ///
+    /// Returns [`EINVAL`] if `offset..offset + data.len()` is outside the I/O region.
+    #[inline]
+    fn try_copy_to_slice(self, offset: usize, data: &mut [u8]) -> Result
+    where
+        Self::Backend: IoCopyable,
+        Self: Io<'a, Target = [u8]>,
+    {
+        io_byte_slice(self, offset, data.len())?.copy_to_slice(data);
+        Ok(())
+    }
+
     /// Fallible 8-bit read with runtime bounds check.
     #[inline(always)]
     fn try_read8(self, offset: usize) -> Result<u8>

[PATCH 7/9] rust: hrtimer: expose interrupt state in hard callbacks

[Mike Lothian]

Hard hrtimer modes guarantee that their callbacks run with local
interrupts disabled. Carry that guarantee through HrTimerCallbackContext
so users of IRQ-aware locks do not need to assert the callback
context themselves.

Assisted-by: Claude:claude-opus-5
Signed-off-by: Mike Lothian <mike@fireburn.co.uk>
---
 rust/kernel/time/hrtimer.rs | 21 ++++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/rust/kernel/time/hrtimer.rs b/rust/kernel/time/hrtimer.rs
index 2d7f1131a813..a55b3ce53735 100644
--- a/rust/kernel/time/hrtimer.rs
+++ b/rust/kernel/time/hrtimer.rs
@@ -404,7 +404,7 @@
 //! [`Arc`]: kernel::sync::Arc
 
 use super::{ClockSource, Delta, Instant};
-use crate::{prelude::*, types::Opaque};
+use crate::{interrupt::LocalInterruptDisabled, prelude::*, types::Opaque};
 use core::{marker::PhantomData, ptr::NonNull};
 use pin_init::PinInit;
 
@@ -900,6 +900,11 @@ pub trait HrTimerMode: private::Sealed {
     type Expires: HrTimerExpires;
 }
 
+/// A timer mode whose callback runs with local interrupts disabled.
+///
+/// This trait is sealed by [`HrTimerMode`].
+pub trait HardHrTimerMode: HrTimerMode {}
+
 /// Timer that expires at a fixed point in time.
 pub struct AbsoluteMode<C: ClockSource>(PhantomData<C>);
 
@@ -982,6 +987,7 @@ impl<C: ClockSource> HrTimerMode for AbsoluteHardMode<C> {
     type Clock = C;
     type Expires = Instant<C>;
 }
+impl<C: ClockSource> HardHrTimerMode for AbsoluteHardMode<C> {}
 
 /// Timer with relative expiration, handled in hard irq context.
 pub struct RelativeHardMode<C: ClockSource>(PhantomData<C>);
@@ -991,6 +997,7 @@ impl<C: ClockSource> HrTimerMode for RelativeHardMode<C> {
     type Clock = C;
     type Expires = Delta;
 }
+impl<C: ClockSource> HardHrTimerMode for RelativeHardMode<C> {}
 
 /// Timer with absolute expiration, pinned to CPU and handled in hard irq context.
 pub struct AbsolutePinnedHardMode<C: ClockSource>(PhantomData<C>);
@@ -1000,6 +1007,7 @@ impl<C: ClockSource> HrTimerMode for AbsolutePinnedHardMode<C> {
     type Clock = C;
     type Expires = Instant<C>;
 }
+impl<C: ClockSource> HardHrTimerMode for AbsolutePinnedHardMode<C> {}
 
 /// Timer with relative expiration, pinned to CPU and handled in hard irq context.
 pub struct RelativePinnedHardMode<C: ClockSource>(PhantomData<C>);
@@ -1009,6 +1017,7 @@ impl<C: ClockSource> HrTimerMode for RelativePinnedHardMode<C> {
     type Clock = C;
     type Expires = Delta;
 }
+impl<C: ClockSource> HardHrTimerMode for RelativePinnedHardMode<C> {}
 
 /// Privileged smart-pointer for a [`HrTimer`] callback context.
 ///
@@ -1065,6 +1074,16 @@ pub fn forward(&mut self, now: HrTimerInstant<T>, interval: Delta) -> u64 {
     pub fn forward_now(&mut self, duration: Delta) -> u64 {
         self.forward(HrTimerInstant::<T>::now(), duration)
     }
+
+    /// Returns proof that local interrupts are disabled for a hard timer callback.
+    pub fn local_interrupt_disabled(&self) -> &LocalInterruptDisabled
+    where
+        T::TimerMode: HardHrTimerMode,
+    {
+        // SAFETY: `Self` can only be constructed while running this timer's callback, and the
+        // `HardHrTimerMode` bound guarantees that the callback runs in hard interrupt context.
+        unsafe { LocalInterruptDisabled::assume_disabled() }
+    }
 }
 
 /// Use to implement the [`HasHrTimer<T>`] trait.

Re: [PATCH 7/9] rust: hrtimer: expose interrupt state in hard callbacks

[Andreas Hindborg]

"Mike Lothian" <mike@fireburn.co.uk> writes:

> Hard hrtimer modes guarantee that their callbacks run with local
> interrupts disabled. Carry that guarantee through HrTimerCallbackContext
> so users of IRQ-aware locks do not need to assert the callback
> context themselves.

This looks good to me. We were pondering on removing the context type
though [1]. We might have to keep it around for this to work.

Best regards,
Andreas Hindborg

[1] https://lore.kernel.org/rust-for-linux/20260825-expires-v2-v1-3-90411c6217c7@kernel.org/

[PATCH 8/9] rust: error: expose EPROTO

[Mike Lothian]

Add the named protocol-error constant so Rust protocol drivers
can return the same specific errno as their C counterparts without
constructing it from a raw integer.

Assisted-by: Claude:claude-opus-5
Signed-off-by: Mike Lothian <mike@fireburn.co.uk>
---
 rust/kernel/error.rs | 1 +
 1 file changed, 1 insertion(+)

diff --git a/rust/kernel/error.rs b/rust/kernel/error.rs
index a56ba6309594..9492471c2677 100644
--- a/rust/kernel/error.rs
+++ b/rust/kernel/error.rs
@@ -64,6 +64,7 @@ macro_rules! declare_err {
     declare_err!(EPIPE, "Broken pipe.");
     declare_err!(EDOM, "Math argument out of domain of func.");
     declare_err!(ERANGE, "Math result not representable.");
+    declare_err!(EPROTO, "Protocol error.");
     declare_err!(EOVERFLOW, "Value too large for defined data type.");
     declare_err!(EMSGSIZE, "Message too long.");
     declare_err!(ETIMEDOUT, "Connection timed out.");

Re: [PATCH 8/9] rust: error: expose EPROTO

[Miguel Ojeda]

On Wed, Aug 26, 2026 at 6:29 PM Mike Lothian <mike@fireburn.co.uk> wrote:
>
> Add the named protocol-error constant so Rust protocol drivers
> can return the same specific errno as their C counterparts without
> constructing it from a raw integer.
>
> Assisted-by: Claude:claude-opus-5
> Signed-off-by: Mike Lothian <mike@fireburn.co.uk>

This is already in mainline, please see commit b93fb6e76ec1 ("rust:
error: add remaining error codes").

Cheers,
Miguel

[PATCH 9/9] rust: time: add ktime_get_real_seconds

[Mike Lothian]

Reading an `Instant<RealTime>` is the wrong tool for a caller that only
wants a calendar time in seconds: it takes a full nanosecond timestamp and
then needs a 64-bit division to get back to what the timekeeping core
already maintains as a plain seconds field.

Wrap `ktime_get_real_seconds()`, which is that field. Document the property
that matters at the call site and that the type cannot express: the value
follows CLOCK_REALTIME, so it is not monotonic and can move in either
direction.

Assisted-by: Claude:claude-opus-5
Signed-off-by: Mike Lothian <mike@fireburn.co.uk>
---
 rust/kernel/time.rs | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/rust/kernel/time.rs b/rust/kernel/time.rs
index 363e93cbb139..a9922f1b493d 100644
--- a/rust/kernel/time.rs
+++ b/rust/kernel/time.rs
@@ -129,6 +129,20 @@ fn ktime_get() -> bindings::ktime_t {
     }
 }
 
+/// Returns the coarse wall-clock time in whole seconds since the Unix epoch.
+///
+/// This is the cheap counterpart to reading an [`Instant<RealTime>`]: it reads the seconds field
+/// the timekeeping core maintains, with no 64-bit division, and is what a caller that only needs a
+/// calendar time should use.
+///
+/// The value follows CLOCK_REALTIME, so it is not monotonic: settimeofday(2), NTP steps and leap
+/// second handling can move it in either direction.
+pub fn ktime_get_real_seconds() -> i64 {
+    // SAFETY: reading the timekeeping core's seconds field has no preconditions and is safe from
+    // any context.
+    unsafe { bindings::ktime_get_real_seconds() }
+}
+
 /// A monotonic that ticks while system is suspended.
 ///
 /// A nonsettable system-wide clock that is identical to CLOCK_MONOTONIC,

Re: [PATCH 9/9] rust: time: add ktime_get_real_seconds

[Andreas Hindborg]

"Mike Lothian" <mike@fireburn.co.uk> writes:

> Reading an `Instant<RealTime>` is the wrong tool for a caller that only
> wants a calendar time in seconds: it takes a full nanosecond timestamp and
> then needs a 64-bit division to get back to what the timekeeping core
> already maintains as a plain seconds field.
>
> Wrap `ktime_get_real_seconds()`, which is that field. Document the property
> that matters at the call site and that the type cannot express: the value
> follows CLOCK_REALTIME, so it is not monotonic and can move in either
> direction.

We recently added the concept of `TimeUnit`. For now it is exposed via
`Delta<U: TimeUnit>`. We could extend this to `Instant` as well to have
a seconds based `Instant`.


Best regards,
Andreas Hindborg

Re: [PATCH 9/9] rust: time: add ktime_get_real_seconds

[FUJITA Tomonori]

On Thu, 27 Aug 2026 15:39:53 +0200
Andreas Hindborg <a.hindborg@kernel.org> wrote:

> "Mike Lothian" <mike@fireburn.co.uk> writes:
> 
>> Reading an `Instant<RealTime>` is the wrong tool for a caller that only
>> wants a calendar time in seconds: it takes a full nanosecond timestamp and
>> then needs a 64-bit division to get back to what the timekeeping core
>> already maintains as a plain seconds field.
>>
>> Wrap `ktime_get_real_seconds()`, which is that field. Document the property
>> that matters at the call site and that the type cannot express: the value
>> follows CLOCK_REALTIME, so it is not monotonic and can move in either
>> direction.
> 
> We recently added the concept of `TimeUnit`. For now it is exposed via
> `Delta<U: TimeUnit>`. We could extend this to `Instant` as well to have
> a seconds based `Instant`.

I don't think that is a good idea.

`Instant` is a point in time that exists to produce a `Delta`: `now()` is its
only constructor, and what you do with it is `elapsed()` or `Instant -
Instant`. So a seconds based `Instant` has to define what `Instant - Instant`
returns, and `Delta<Sec>` would have no consumer. Every interface that takes a
span takes a `Delta<Nsec>`: `fsleep()`, `udelay()`, `HrTimer::forward()`,
`read_poll_timeout()`. `Delta` also already treats seconds as an input format
rather than a unit, since `Delta::from_secs()` returns a `Delta<Nsec>`. That is
the difference from `Delta<Jiffy>`, which earned a type because the C side takes
jiffies at the boundary and the conversion is lossy; `time64_t` is an `i64` and
seconds to nanoseconds is exact.

And that is not how `ktime_get_real_seconds()` is used in the first place. Its
callers need a calendar value in seconds because something outside the kernel
fixes the format: an on-disk field, a value passed to firmware, or a userspace
ABI field. Many of them compare it against an expiry time that came from the
wire or from disk.

Does that make sense?

Re: [PATCH 9/9] rust: time: add ktime_get_real_seconds

[Andreas Hindborg]

FUJITA Tomonori <tomo@flapping.org> writes:

> On Thu, 27 Aug 2026 15:39:53 +0200
> Andreas Hindborg <a.hindborg@kernel.org> wrote:
>
>> "Mike Lothian" <mike@fireburn.co.uk> writes:
>> 
>>> Reading an `Instant<RealTime>` is the wrong tool for a caller that only
>>> wants a calendar time in seconds: it takes a full nanosecond timestamp and
>>> then needs a 64-bit division to get back to what the timekeeping core
>>> already maintains as a plain seconds field.
>>>
>>> Wrap `ktime_get_real_seconds()`, which is that field. Document the property
>>> that matters at the call site and that the type cannot express: the value
>>> follows CLOCK_REALTIME, so it is not monotonic and can move in either
>>> direction.
>> 
>> We recently added the concept of `TimeUnit`. For now it is exposed via
>> `Delta<U: TimeUnit>`. We could extend this to `Instant` as well to have
>> a seconds based `Instant`.
>
> I don't think that is a good idea.
>
> `Instant` is a point in time that exists to produce a `Delta`: `now()` is its
> only constructor,

`Instant` is a point in time. `ktime_get_real_seconds` return a point in
time. Whether the constructor is `Delta::now` or should be
`Instant::now` could be discussed.

> and what you do with it is `elapsed()`

I don't see the issue with `Instant<RealSeconds>::elapsed()`. You would
get a duration of seconds that has elapsed since the instant? Of course
you get all the inaccuracy that comes with using seconds resolution.

> or `Instant -
> Instant`.

Same.

> So a seconds based `Instant` has to define what `Instant - Instant`
> returns,

A `Delta<Seconds>` would be the obvious choice? I perfer `Seconds` and
`NanoSeconds`, but the abbreviated pattern is already prevalent, so
probably best to go with that.

> and `Delta<Sec>` would have no consumer.

True, but OK I guess.

> Every interface that takes a
> span takes a `Delta<Nsec>`: `fsleep()`, `udelay()`, `HrTimer::forward()`,
> `read_poll_timeout()`.

That is fine. Those APIs do not have to take `Delta<Seconds>`, they can
keep taking `Delta<Nsec>`

> `Delta` also already treats seconds as an input format
> rather than a unit, since `Delta::from_secs()` returns a
> `Delta<Nsec>`.

That is fine. In the context of `Delta::from_secs` the argument is a
duration. `Instant<Seconds>` is a logically different concept. It is a
point in time, not a duration.

> That is
> the difference from `Delta<Jiffy>`, which earned a type because the C side takes
> jiffies at the boundary and the conversion is lossy; `time64_t` is an `i64` and
> seconds to nanoseconds is exact.

Yes, we made `Delta<Jiffy>` from a need to pass a jiffy based duration
to C code. That should not prevent us from having a seconds based `Instant`.

If you are concerned about the dead code in a seconds based `Delta`, we
can gate the impls.

> And that is not how `ktime_get_real_seconds()` is used in the first place. Its
> callers need a calendar value in seconds because something outside the kernel
> fixes the format: an on-disk field, a value passed to firmware, or a userspace
> ABI field. Many of them compare it against an expiry time that came from the
> wire or from disk.

Again, sure, that is why we originally introduced these types. But I
don't think we should gate our time representing types on the rationale
of the first use case. We should represent points in time and duration
of time with a single set of types.

> Does that make sense?

I think I understand your concern, but I do not share it.

I would appreciate others to chime in on this - in either direction. How
should we represent time in general.


Best regards,
Andreas Hindborg

Re: [PATCH 9/9] rust: time: add ktime_get_real_seconds

[Mike Lothian]

On Tue, 8 Sep 2026, Andreas Hindborg wrote:
> We should represent points in time and duration of time with a single
> set of types.

On Tue, 8 Sep 2026, FUJITA Tomonori wrote:
> I could not find a user of this in the posted series, including the
> drm/vino v3 one, which looks like it uses `Instant<Monotonic>`
> everywhere.  Where can I see the code that calls this, and what does
> it do with the value?

Sorry, the user wasn't in anything I'd posted when you asked.  It's in
the drm/vino series that sits on top of this one, 7/14 in the new
posting, which I haven't sent yet

The dock has a real-time clock and the DisplayLink driver sets it during
session bring-up.  The message carries the calendar date and time in
broken-down form, so the code takes the seconds, adds a UTC offset that
comes from a module parameter, and works out year, month, day, hour,
minute, second, weekday and day of year.  That's the only use, it's read
once per bring-up and nothing is compared against it

So it's the case you described, Tomonori: the format is fixed outside
the kernel, by the dock's firmware, and what the caller wants is an i64
of seconds since the epoch.  It never gets subtracted from anything, so a
seconds based Instant would only be there to be converted straight back

I don't have a strong view on Instant<Seconds> versus the plain function.
If you two settle on the Instant, I'll respin on it, but I'd rather not
block the rest of rust-core on that, and the function is small enough to
change when the types land

Mike

Re: [PATCH 9/9] rust: time: add ktime_get_real_seconds

[FUJITA Tomonori]

On Fri, 30 Oct 2026 07:57:50 +0000
Mike Lothian <mike@fireburn.co.uk> wrote:

> So it's the case you described, Tomonori: the format is fixed outside
> the kernel, by the dock's firmware, and what the caller wants is an i64
> of seconds since the epoch.  It never gets subtracted from anything, so a
> seconds based Instant would only be there to be converted straight back

Right, you only need an i64 of seconds since the epoch and do no
arithmetic or comparison on it. A type is useful when it guards those
operations, and there are none here. So the plain function is fine
with me. If a caller that needs them shows up later, we can add a type
then.

Re: [PATCH 9/9] rust: time: add ktime_get_real_seconds

[Boqun Feng]

On Fri, Oct 30, 2026 at 07:05:02PM +0900, FUJITA Tomonori wrote:
> On Fri, 30 Oct 2026 07:57:50 +0000
> Mike Lothian <mike@fireburn.co.uk> wrote:
> 
> > So it's the case you described, Tomonori: the format is fixed outside
> > the kernel, by the dock's firmware, and what the caller wants is an i64
> > of seconds since the epoch.  It never gets subtracted from anything, so a
> > seconds based Instant would only be there to be converted straight back

Even that, I think Instant<Sec> would still be more clear than returning
an i64. Also regarding Tomo's concern:

| So a seconds based `Instant` has to define what `Instant - Instant`
| returns, and `Delta<Sec>` would have no consumer.

We can probably only impl ops::Sub for Instant<C, NSec>, then we don't
have to deal with `Delta<Sec>` until there is a user. (We probably want
to avoid a from_ktime() for Instant<Sec> as well, so separate impl
blocks make sense).

> 
> Right, you only need an i64 of seconds since the epoch and do no
> arithmetic or comparison on it. A type is useful when it guards those
> operations, and there are none here. So the plain function is fine

The way I see it is from kernel::time perspective, we still want to make
sure the APIs are still in the same abstraction layer, a
ktime_get_real_seconds() co-exists with Instant::now() as the public
interface layer breaks that in my opinion. And the generic type
parameter should be flexible enough to avoid introduce anything we don't
have a user yet.

Thoughts?

Regards,
Boqun

> with me. If a caller that needs them shows up later, we can add a type
> then.

Re: [PATCH 9/9] rust: time: add ktime_get_real_seconds

[FUJITA Tomonori]

On Fri, 30 Oct 2026 11:59:24 -0700
Boqun Feng <boqun@kernel.org> wrote:

> The way I see it is from kernel::time perspective, we still want to make
> sure the APIs are still in the same abstraction layer, a
> ktime_get_real_seconds() co-exists with Instant::now() as the public
> interface layer breaks that in my opinion. And the generic type
> parameter should be flexible enough to avoid introduce anything we don't
> have a user yet.

OK. I sent a series that adds a unit parameter to `Instant` and a
seconds based `Instant` on top of it, with `Sub` and the other
arithmetic on `Instant<C, Nsec>` only:

https://lore.kernel.org/rust-for-linux/20261031003334.4161188-1-tomo@flapping.org/

What it costs is a new trait `InstantUnit` with a read function, a
second method on `ClockId`, and per-unit invariants on
`Instant`. Please take a look and tell me if this is fine.

Re: [PATCH 9/9] rust: time: add ktime_get_real_seconds

[FUJITA Tomonori]

On Wed, 26 Aug 2026 17:28:43 +0100
Mike Lothian <mike@fireburn.co.uk> wrote:

> Reading an `Instant<RealTime>` is the wrong tool for a caller that only
> wants a calendar time in seconds: it takes a full nanosecond timestamp and
> then needs a 64-bit division to get back to what the timekeeping core
> already maintains as a plain seconds field.
> 
> Wrap `ktime_get_real_seconds()`, which is that field. Document the property
> that matters at the call site and that the type cannot express: the value
> follows CLOCK_REALTIME, so it is not monotonic and can move in either
> direction.
> 
> Assisted-by: Claude:claude-opus-5
> Signed-off-by: Mike Lothian <mike@fireburn.co.uk>
> ---
>  rust/kernel/time.rs | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)

I could not find a user of this in the posted series, including the
drm/vino v3 one, which looks like it uses `Instant<Monotonic>`
everywhere.  Where can I see the code that calls this, and what does
it do with the value? I would like to see the use case before judging
what this should return.