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

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 <[email protected]>
---
 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,