summaryrefslogtreecommitdiff
path: root/rust/kernel
AgeCommit message (Collapse)Author
2026-04-07rust: remove `RUSTC_HAS_SLICE_AS_FLATTENED` and simplify codeMiguel Ojeda
With the Rust version bump in place, the `RUSTC_HAS_SLICE_AS_FLATTENED` Kconfig (automatic) option is always true. Thus remove the option and simplify the code. In particular, this includes removing the `slice` module which contained the temporary slice helpers, i.e. the `AsFlattened` extension trait and its `impl`s. Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-10-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: bump Clippy's MSRV and clean `incompatible_msrv` allowsMiguel Ojeda
Following the Rust compiler bump, we can now update Clippy's MSRV we set in the configuration, which will improve the diagnostics it generates. Thus do so and clean a few of the `allow`s that are not needed anymore. Reviewed-by: Tamir Duberstein <tamird@kernel.org> Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-7-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-06Merge tag 'v7.0-rc7' into char-misc-nextGreg Kroah-Hartman
We need the char/misc/iio/comedi fixes in here as well for testing Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-04-05mm: rename zap_page_range_single() to zap_vma_range()David Hildenbrand (Arm)
Let's rename it to make it better match our new naming scheme. While at it, polish the kerneldoc. [akpm@linux-foundation.org: fix rustfmtcheck] Link: https://lkml.kernel.org/r/20260227200848.114019-15-david@kernel.org Signed-off-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org> Acked-by: Puranjay Mohan <puranjay@kernel.org> Cc: Alexander Gordeev <agordeev@linux.ibm.com> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Alice Ryhl <aliceryhl@google.com> Cc: Andrii Nakryiko <andrii@kernel.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Arve <arve@android.com> Cc: "Borislav Petkov (AMD)" <bp@alien8.de> Cc: Carlos Llamas <cmllamas@google.com> Cc: Christian Borntraeger <borntraeger@linux.ibm.com> Cc: Christian Brauner <brauner@kernel.org> Cc: Claudio Imbrenda <imbrenda@linux.ibm.com> Cc: Daniel Borkman <daniel@iogearbox.net> Cc: Dave Airlie <airlied@gmail.com> Cc: David Ahern <dsahern@kernel.org> Cc: David Rientjes <rientjes@google.com> Cc: David S. Miller <davem@davemloft.net> Cc: Dimitri Sivanich <dimitri.sivanich@hpe.com> Cc: Eric Dumazet <edumazet@google.com> Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Hartley Sweeten <hsweeten@visionengravers.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Ian Abbott <abbotti@mev.co.uk> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jakub Kacinski <kuba@kernel.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Jann Horn <jannh@google.com> Cc: Janosch Frank <frankja@linux.ibm.com> Cc: Jarkko Sakkinen <jarkko@kernel.org> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Jonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Leon Romanovsky <leon@kernel.org> Cc: Liam Howlett <liam.howlett@oracle.com> Cc: Madhavan Srinivasan <maddy@linux.ibm.com> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Michal Hocko <mhocko@suse.com> Cc: Miguel Ojeda <ojeda@kernel.org> Cc: Mike Rapoport <rppt@kernel.org> Cc: Namhyung kim <namhyung@kernel.org> Cc: Neal Cardwell <ncardwell@google.com> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Pedro Falcato <pfalcato@suse.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Shakeel Butt <shakeel.butt@linux.dev> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Todd Kjos <tkjos@android.com> Cc: Tvrtko Ursulin <tursulin@ursulin.net> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Vincenzo Frascino <vincenzo.frascino@arm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-04-05mm/memory: remove "zap_details" parameter from zap_page_range_single()David Hildenbrand (Arm)
Nobody except memory.c should really set that parameter to non-NULL. So let's just drop it and make unmap_mapping_range_vma() use zap_page_range_single_batched() instead. [david@kernel.org: format on a single line] Link: https://lkml.kernel.org/r/8a27e9ac-2025-4724-a46d-0a7c90894ba7@kernel.org Link: https://lkml.kernel.org/r/20260227200848.114019-3-david@kernel.org Signed-off-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org> Acked-by: Puranjay Mohan <puranjay@kernel.org> Cc: Alexander Gordeev <agordeev@linux.ibm.com> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Alice Ryhl <aliceryhl@google.com> Cc: Andrii Nakryiko <andrii@kernel.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Arve <arve@android.com> Cc: "Borislav Petkov (AMD)" <bp@alien8.de> Cc: Carlos Llamas <cmllamas@google.com> Cc: Christian Borntraeger <borntraeger@linux.ibm.com> Cc: Christian Brauner <brauner@kernel.org> Cc: Claudio Imbrenda <imbrenda@linux.ibm.com> Cc: Daniel Borkman <daniel@iogearbox.net> Cc: Dave Airlie <airlied@gmail.com> Cc: David Ahern <dsahern@kernel.org> Cc: David Rientjes <rientjes@google.com> Cc: David S. Miller <davem@davemloft.net> Cc: Dimitri Sivanich <dimitri.sivanich@hpe.com> Cc: Eric Dumazet <edumazet@google.com> Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Hartley Sweeten <hsweeten@visionengravers.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Ian Abbott <abbotti@mev.co.uk> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jakub Kacinski <kuba@kernel.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Jann Horn <jannh@google.com> Cc: Janosch Frank <frankja@linux.ibm.com> Cc: Jarkko Sakkinen <jarkko@kernel.org> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Jonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Leon Romanovsky <leon@kernel.org> Cc: Liam Howlett <liam.howlett@oracle.com> Cc: Madhavan Srinivasan <maddy@linux.ibm.com> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Michal Hocko <mhocko@suse.com> Cc: Miguel Ojeda <ojeda@kernel.org> Cc: Mike Rapoport <rppt@kernel.org> Cc: Namhyung kim <namhyung@kernel.org> Cc: Neal Cardwell <ncardwell@google.com> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Pedro Falcato <pfalcato@suse.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Shakeel Butt <shakeel.butt@linux.dev> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Todd Kjos <tkjos@android.com> Cc: Tvrtko Ursulin <tursulin@ursulin.net> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Vincenzo Frascino <vincenzo.frascino@arm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-04-04Merge tag 'amd-pstate-v7.1-2026-04-02' of ↵Rafael J. Wysocki
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/superm1/linux Pull amd-pstate new content for 7.1 (2026-04-02) from Mario Limonciello: "Add support for new features: * CPPC performance priority * Dynamic EPP * Raw EPP * New unit tests for new features Fixes for: * PREEMPT_RT * sysfs files being present when HW missing * Broken/outdated documentation" * tag 'amd-pstate-v7.1-2026-04-02' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/superm1/linux: (22 commits) MAINTAINERS: amd-pstate: Step down as maintainer, add Prateek as reviewer cpufreq: Pass the policy to cpufreq_driver->adjust_perf() cpufreq/amd-pstate: Pass the policy to amd_pstate_update() cpufreq/amd-pstate-ut: Add a unit test for raw EPP cpufreq/amd-pstate: Add support for raw EPP writes cpufreq/amd-pstate: Add support for platform profile class cpufreq/amd-pstate: add kernel command line to override dynamic epp cpufreq/amd-pstate: Add dynamic energy performance preference Documentation: amd-pstate: fix dead links in the reference section cpufreq/amd-pstate: Cache the max frequency in cpudata Documentation/amd-pstate: Add documentation for amd_pstate_floor_{freq,count} Documentation/amd-pstate: List amd_pstate_prefcore_ranking sysfs file Documentation/amd-pstate: List amd_pstate_hw_prefcore sysfs file amd-pstate-ut: Add a testcase to validate the visibility of driver attributes amd-pstate-ut: Add module parameter to select testcases amd-pstate: Introduce a tracepoint trace_amd_pstate_cppc_req2() amd-pstate: Add sysfs support for floor_freq and floor_count amd-pstate: Add support for CPPC_REQ2 and FLOOR_PERF x86/cpufeatures: Add AMD CPPC Performance Priority feature. amd-pstate: Make certain freq_attrs conditionally visible ...
2026-04-04rust: prelude: use the "kernel vertical" imports styleMiguel Ojeda
Format the Rust prelude to use the "kernel vertical" imports style [1]. No functional changes intended. Link: https://docs.kernel.org/rust/coding-guidelines.html#imports [1] Link: https://patch.msgid.link/20260208224659.18406-2-ojeda@kernel.org [ Rebased. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-03rust: clk: implement Send and SyncAlice Ryhl
These traits are required for drivers to embed the Clk type in their own data structures because driver data structures are usually required to be Send. Since the Clk type is thread-safe, implement the relevant traits. Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Brian Masney <bmasney@redhat.com> # Active contributor to clk Link: https://patch.msgid.link/20260223-clk-send-sync-v5-1-181bf2f35652@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-03rust: ptr: add const_align_up()John Hubbard
Add const_align_up() to kernel::ptr as the const-compatible equivalent of Alignable::align_up(). Suggested-by: Danilo Krummrich <dakr@kernel.org> Suggested-by: Gary Guo <gary@garyguo.net> Suggested-by: Miguel Ojeda <ojeda@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260326013902.588242-17-jhubbard@nvidia.com [ Adjusted imports style. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-03rust: error: clarify that `from_err_ptr` can return `Ok(NULL)`Mirko Adzic
Improve the doc comment of `from_err_ptr` by explicitly stating that it will return `Ok(NULL)` when passed a null pointer, as it isn't an error value. Add a doctest case that tests the behavior described above, as well as other scenarios (non-null/non-error pointer, error value). Suggested-by: Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/rust-for-linux/20260322193830.89324-1-ojeda@kernel.org/ Link: https://github.com/Rust-for-Linux/linux/issues/1231 Signed-off-by: Mirko Adzic <adzicmirko97@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260329104319.131057-1-adzicmirko97@gmail.com [ - Added `expect` for `clippy::missing_safety_doc`. - Simplified and removed unsafe block using `Error::to_ptr()`. - Added intra-doc link. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-02cpufreq: Pass the policy to cpufreq_driver->adjust_perf()K Prateek Nayak
cpufreq_cpu_get() can sleep on PREEMPT_RT in presence of concurrent writer(s), however amd-pstate depends on fetching the cpudata via the policy's driver data which necessitates grabbing the reference. Since schedutil governor can call "cpufreq_driver->update_perf()" during sched_tick/enqueue/dequeue with rq_lock held and IRQs disabled, fetching the policy object using the cpufreq_cpu_get() helper in the scheduler fast-path leads to "BUG: scheduling while atomic" on PREEMPT_RT [1]. Pass the cached cpufreq policy object in sg_policy to the update_perf() instead of just the CPU. The CPU can be inferred using "policy->cpu". The lifetime of cpufreq_policy object outlasts that of the governor and the cpufreq driver (allocated when the CPU is onlined and only reclaimed when the CPU is offlined / the CPU device is removed) which makes it safe to be referenced throughout the governor's lifetime. Closes:https://lore.kernel.org/all/20250731092316.3191-1-spasswolf@web.de/ [1] Fixes: 1d215f0319c2 ("cpufreq: amd-pstate: Add fast switch function for AMD P-State") Reported-by: Bert Karwatzki <spasswolf@web.de> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com> Acked-by: Gary Guo <gary@garyguo.net> # Rust Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260316081849.19368-3-kprateek.nayak@amd.com Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2026-04-01rust: task: implement == operator for TaskAlice Ryhl
It's useful to compare if two tasks are the same task or not. Rust Binder wants this to check if a certain task is equal to the group leader of current. Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260324-close-fd-check-current-v3-2-b94274bedac7@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-04-01rust: sync: implement == operator for ARefAlice Ryhl
Rust Binder wants to perform a comparison between ARef<Task> and &Task, so define the == operator for ARef<_> when compared with another ARef<_> or just a reference. The operator is implemented in terms of the same operator applied to the inner type. Note that PartialEq<U> cannot be implemented because it would overlap with the impl for ARef<U>. Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260324-close-fd-check-current-v3-1-b94274bedac7@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-04-01Merge tag 'drm-rust-next-2026-03-30' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/rust/kernel into drm-next DRM Rust changes for v7.1-rc1 - DMA: - Rework the DMA coherent API: introduce Coherent<T> as a generalized container for arbitrary types, replacing the slice-only CoherentAllocation<T>. Add CoherentBox for memory initialization before exposing a buffer to hardware (converting to Coherent when ready), and CoherentHandle for allocations without kernel mapping. - Add Coherent::init() / init_with_attrs() for one-shot initialization via pin-init, and from-slice constructors for both Coherent and CoherentBox - Add uaccess write_dma() for copying from DMA buffers to userspace and BinaryWriter support for Coherent<T> - DRM: - Add GPU buddy allocator abstraction - Add DRM shmem GEM helper abstraction - Allow drm::Device to dispatch work and delayed work items to driver private data - Add impl_aref_for_gem_obj!() macro to reduce GEM refcount boilerplate, and introduce DriverObject::Args for constructor context - Add dma_resv_lock helper and raw_dma_resv() accessor on GEM objects - Clean up imports across the DRM module - I/O: - Merged via a signed tag from the driver-core tree: register!() macro and I/O infrastructure improvements (IoCapable refactor, RelaxedMmio wrapper, IoLoc trait, generic accessors, write_reg / LocatedRegister) - Nova (Core): - Fix and harden the GSP command queue: correct write pointer advancing, empty slot handling, and ring buffer indexing; add mutex locking and make Cmdq a pinned type; distinguish wait vs no-wait commands - Add support for large RPCs via continuation records, splitting oversized commands across multiple queue slots - Simplify GSP sequencer and message handling code: remove unused trait and Display impls, derive Debug and Zeroable where applicable, warn on unconsumed message data - Refactor Falcon firmware handling: create DMA objects lazily, add PIO upload support, and use the Generic Bootloader to boot FWSEC on Turing - Convert all register definitions (PMC, PBUS, PFB, GC6, FUSE, PDISP, Falcon) to the kernel register!() macro; add bounded_enum macro to define enums usable as register fields - Migrate all DMA usage to the new Coherent, CoherentBox, and CoherentHandle APIs - Harden firmware parsing with checked arithmetic throughout FWSEC, Booter, RISC-V parsing paths - Add debugfs support for reading GSP-RM log buffers; replace module_pci_driver!() with explicit module init to support module-level debugfs setup - Fix auxiliary device registration for multi-GPU systems - Various cleanups: import style, firmware parsing refactoring, framebuffer size logging - Rust: - Add interop::list module providing a C linked list interface - Extend num::Bounded with shift operations, into_bool(), and const get() to support register bitfield manipulation - Enable the generic_arg_infer Rust feature and add EMSGSIZE error code - Tyr: - Adopt vertical import style per kernel Rust guidelines - Clarify driver/device type names and use DRM device type alias consistently across the driver - Fix GPU model/version decoding in GpuInfo - Workqueue: - Add ARef<T> support for work and delayed work Signed-off-by: Dave Airlie <airlied@redhat.com> From: "Danilo Krummrich" <dakr@kernel.org> Link: https://patch.msgid.link/DHGH4BLT03BU.ZJH5U52WE8BY@kernel.org
2026-03-31rust_binder: introduce TransactionInfoAlice Ryhl
Rust Binder exposes information about transactions that are sent in various ways: printing to the kernel log, tracepoints, files in binderfs, and the upcoming netlink support. Currently all these mechanisms use disparate ways of obtaining the same information, so let's introduce a single Info struct that collects all the required information in a single place, so that all of these different mechanisms can operate in a more uniform way. For now, the new info struct is only used to replace a few things: * The BinderTransactionDataSg struct that is passed as an argument to several methods is removed as the information is moved into the new info struct and passed down that way. * The oneway spam detection fields on Transaction and Allocation can be removed, as the information can be returned to the caller via the mutable info struct instead. But several other uses of the info struct are planned in follow-up patches. Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260306-transaction-info-v1-1-fda58fca558b@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-03-30rust: rework `build_assert!` documentationGary Guo
Add a detailed comparison and recommendation of the three types of build-time assertion macro as module documentation (and un-hide the module to render them). The documentation on the macro themselves are simplified to only cover the scenarios where they should be used; links to the module documentation is added instead. Reviewed-by: Yury Norov <ynorov@nvidia.com> Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260319121653.2975748-4-gary@kernel.org [ Added periods on comments. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-03-30rust: add `const_assert!` macroGary Guo
The macro is a more powerful version of `static_assert!` for use inside function contexts. This is powered by inline consts, so enable the feature for old compiler versions that does not have it stably. While it is possible already to write `const { assert!(...) }`, this provides a short hand that is more uniform with other assertions. It also formats nicer with rustfmt where it will not be formatted into multiple lines. Two users that would route via the Rust tree are converted. Reviewed-by: Yury Norov <ynorov@nvidia.com> Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260319121653.2975748-3-gary@kernel.org [ Rebased. Fixed period typo. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-03-28rust: move `static_assert` into `build_assert`Gary Guo
Conceptually, `static_assert` is also a build-time assertion that occurs earlier in the pipeline. Consolidate the implementation so that we can use this as the canonical place to add more useful build-time assertions. Reviewed-by: Yury Norov <ynorov@nvidia.com> Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260319121653.2975748-2-gary@kernel.org [ Used kernel vertical style. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-03-28rust: dma: add from-slice constructors for Coherent and CoherentBoxAlexandre Courbot
A very common pattern is to create a block of coherent memory with the content of an already-existing slice of bytes (e.g. a loaded firmware blob). `CoherentBox` makes this easier, but still implies a potentially panicking operation with `copy_from_slice` that requires a `PANIC` comment. Add `from_slice_with_attrs` and `from_slice` methods to both `Coherent` and `CoherentBox` to turn this into a trivial one-step operation. Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260327-b4-nova-dma-removal-v2-1-616e1d0b5cb3@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-28rust: dma: add CoherentHandle for DMA allocations without kernel mappingDanilo Krummrich
Add CoherentHandle, an opaque DMA allocation type for buffers that are only ever accessed by hardware. Unlike Coherent<T>, it does not provide CPU access to the allocated memory. CoherentHandle implicitly sets DMA_ATTR_NO_KERNEL_MAPPING and stores the value returned by dma_alloc_attrs() as an opaque handle (NonNull<c_void>) rather than a typed pointer, since with this flag the C API returns an opaque cookie (e.g. struct page *), not a CPU pointer to the allocated memory. Only the DMA bus address is exposed to drivers; the opaque handle is used solely to free the allocation on drop. This commit is for reference only; there is currently no in-tree user. Signed-off-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260321172749.592387-2-dakr@kernel.org [acourbot: fix conflict in dma.rs.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-28rust: dma: remove DMA_ATTR_NO_KERNEL_MAPPING from public attrsDanilo Krummrich
When DMA_ATTR_NO_KERNEL_MAPPING is passed to dma_alloc_attrs(), the returned CPU address is not a pointer to the allocated memory but an opaque handle (e.g. struct page *). Coherent<T> (or CoherentAllocation<T> respectively) stores this value as NonNull<T> and exposes methods that dereference it and even modify its contents. Remove the flag from the public attrs module such that drivers cannot pass it to Coherent<T> (or CoherentAllocation<T> respectively) in the first place. Instead DMA_ATTR_NO_KERNEL_MAPPING can be supported with an additional opaque type (e.g. CoherentHandle) which does not provide access to the allocated memory. Cc: stable@vger.kernel.org Fixes: ad2907b4e308 ("rust: add dma coherent allocator abstraction") Signed-off-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260321172749.592387-1-dakr@kernel.org Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-27rust: dma: generalize BinaryWriter impl for Coherent<T>Danilo Krummrich
Generalize the BinaryWriter implementation from Coherent<[u8]> to Coherent<T> where T: KnownSize + AsBytes + ?Sized. The implementation only uses size() and write_dma(), neither of which depends on the inner type being a byte slice. This allows any Coherent allocation with an AsBytes inner type to be exposed as a debugfs binary file. Acked-by: Gary Guo <gary@garyguo.net> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260325003921.3420-2-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-27rust: uaccess: generalize write_dma() to accept any Coherent<T>Danilo Krummrich
Generalize write_dma() from &Coherent<[u8]> to &Coherent<T> where T: KnownSize + AsBytes + ?Sized. The function body only uses as_ptr() and size(), which work for any such T, so there is no reason to restrict it to byte slices. Acked-by: Miguel Ojeda <ojeda@kernel.org> Acked-by: Gary Guo <gary@garyguo.net> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260325003921.3420-1-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-27rust: drm: gem: shmem: Add DRM shmem helper abstractionAsahi Lina
The DRM shmem helper includes common code useful for drivers which allocate GEM objects as anonymous shmem. Add a Rust abstraction for this. Drivers can choose the raw GEM implementation or the shmem layer, depending on their needs. Signed-off-by: Asahi Lina <lina@asahilina.net> Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Janne Grunau <j@jananu.net> Tested-by: Deborah Brouwer <deborah.brouwer@collabora.com> Link: https://patch.msgid.link/20260316211646.650074-6-lyude@redhat.com [ * DRM_GEM_SHMEM_HELPER is a tristate; when a module driver selects it, it becomes =m. The Rust kernel crate and its C helpers are always built into vmlinux and can't reference symbols from a module, causing link errors. Thus, add RUST_DRM_GEM_SHMEM_HELPER bool Kconfig that selects DRM_GEM_SHMEM_HELPER, forcing it built-in when Rust drivers need it; use cfg(CONFIG_RUST_DRM_GEM_SHMEM_HELPER) for the shmem module. * Add cfg_attr(not(CONFIG_RUST_DRM_GEM_SHMEM_HELPER), expect(unused)) on pub(crate) use impl_aref_for_gem_obj and BaseObjectPrivate, so that unused warnings are suppressed when shmem is not enabled. * Enable const_refs_to_static (stabilized in 1.83) to prevent build errors with older compilers. * Use &raw const for bindings::drm_gem_shmem_vm_ops and add #[allow(unused_unsafe, reason = "Safe since Rust 1.82.0")]. * Fix incorrect C Header path and minor spelling and formatting issues. * Drop shmem::Object::sg_table() as the current implementation is unsound. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-27rust: drm: gem: Add raw_dma_resv() functionLyude Paul
For retrieving a pointer to the struct dma_resv for a given GEM object. We also introduce it in a new trait, BaseObjectPrivate, which we automatically implement for all gem objects and don't expose to users outside of the crate. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Janne Grunau <j@jananu.net> Tested-by: Janne Grunau <j@jannau.net> Tested-by: Deborah Brouwer <deborah.brouwer@collabora.com> Link: https://patch.msgid.link/20260316211646.650074-3-lyude@redhat.com [ Fix incorrect reference in safety comment. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-27rust: kernel: mark as `#[inline]` all `From::from()`s for `Error`Alistair Francis
There was a recent request [1] to mark as `#[inline]` the simple `From::from()` functions implemented for `Error`. Thus mark all of the existing impl From<...> for Error { fn from(err: ...) -> Self { ... } } functions in the `kernel` crate as `#[inline]`. Suggested-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/all/8403c8b7a832b5274743816eb77abfa4@garyguo.net/ [1] Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://patch.msgid.link/20260326020406.1438210-1-alistair.francis@wdc.com [ Dropped `projection.rs` since it is in another tree and already marked as `inline(always)` and reworded accordingly. Changed Link tag to Gary's original message and added Suggested-by. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-03-27rust: list: hide macros from top-level kernel docGary Guo
Due to Rust macro scoping rules, all macros defined in a crate using `#[macro_export]` end up in the top-level. For the list macros, we re-export them inside the list module, and expect users to use `kernel::list::macro_name!()`. Use `#[doc(hidden)]` on the macro definition, and use `#[doc(inline)]` on the re-export to make the macro appear to be defined at module-level inside documentation. The other exported types are already automatically `#[doc(inline)]` because they are defined in a non-public module, so there is no need to split the macro re-exports out. Signed-off-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260312174700.4016015-1-gary@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-03-26rust: drm: use new sync::aref path for importsAlice Ryhl
ARef and AlwaysRefCounted are being moved to sync::aref, and the re-exports under types are planned to be removed. Thus, update imports to the new path. Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260326-drm-rust-next-fix-aref-v1-2-7f6f58d2828a@google.com Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2026-03-26rust: workqueue: use new sync::aref path for importsAlice Ryhl
ARef and AlwaysRefCounted are being moved to sync::aref, and the re-exports under types are planned to be removed. Thus, update imports to the new path. Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260326-drm-rust-next-fix-aref-v1-1-7f6f58d2828a@google.com Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2026-03-26rust: drm: dispatch delayed work items to the private dataDaniel Almeida
Much like the patch that dispatched (regular) work items, we also need to dispatch delayed work items in order not to trigger the orphan rule. This allows a drm::Device<T> to dispatch the delayed work to T::Data. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com> Link: https://lore.kernel.org/r/20260323-aref-workitem-v3-4-f59729b812aa@collabora.com Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2026-03-26rust: workqueue: add delayed work support for ARef<T>Daniel Almeida
The preceding patches added support for ARef<T> work items. By the same token, add support for delayed work items too. The rationale is the same: it may be convenient or even necessary at times to implement HasDelayedWork directly on ARef<T>. A follow up patch will also implement support for drm::Device as the first user. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com> Link: https://lore.kernel.org/r/20260323-aref-workitem-v3-3-f59729b812aa@collabora.com Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2026-03-26rust: drm: dispatch work items to the private dataDaniel Almeida
This implementation dispatches any work enqueued on ARef<drm::Device<T>> to its driver-provided handler. It does so by building upon the newly-added ARef<T> support in workqueue.rs in order to call into the driver implementations for work_container_of and raw_get_work. This is notably important for work items that need access to the drm device, as it was not possible to enqueue work on a ARef<drm::Device<T>> previously without failing the orphan rule. The current implementation needs T::Data to live inline with drm::Device in order for work_container_of to function. This restriction is already captured by the trait bounds. Drivers that need to share their ownership of T::Data may trivially get around this: // Lives inline in drm::Device struct DataWrapper { work: ..., // Heap-allocated, shared ownership. data: Arc<DriverData>, } Reviewed-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com> Link: https://lore.kernel.org/r/20260323-aref-workitem-v3-2-f59729b812aa@collabora.com Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2026-03-26rust: workqueue: add support for ARef<T>Daniel Almeida
Add support for the ARef<T> smart pointer. This allows an instance of ARef<T> to handle deferred work directly, which can be convenient or even necessary at times, depending on the specifics of the driver or subsystem. The implementation is similar to that of Arc<T>, and a subsequent patch will implement support for drm::Device as the first user. This is notably important for work items that need access to the drm device, as it was not possible to enqueue work on a ARef<drm::Device<T>> previously without failing the orphan rule. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com> Link: https://lore.kernel.org/r/20260323-aref-workitem-v3-1-f59729b812aa@collabora.com Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2026-03-26rust: gem: Introduce DriverObject::ArgsLyude Paul
This is an associated type that may be used in order to specify a data-type to pass to gem objects when constructing them, allowing for drivers to more easily initialize their private-data for gem objects. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Janne Grunau <j@jananu.net> Tested-by: Deborah Brouwer <deborah.brouwer@collabora.com> Link: https://patch.msgid.link/20260316211646.650074-5-lyude@redhat.com [ Resolve merge conflicts in Tyr. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-26rust: drm: Add gem::impl_aref_for_gem_obj!Lyude Paul
In the future we're going to be introducing more GEM object types in rust then just gem::Object<T>. Since all types of GEM objects have refcounting, let's introduce a macro that we can use in the gem crate in order to copy this boilerplate implementation for each type: impl_aref_for_gem_obj!(). Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Janne Grunau <j@jananu.net> Tested-by: Deborah Brouwer <deborah.brouwer@collabora.com> Link: https://patch.msgid.link/20260316211646.650074-2-lyude@redhat.com [ Resolve merge conflicts. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-25rust: dma: implement BinaryWriter for Coherent<[u8]>Timur Tabi
Implement the BinaryWriter trait for Coherent<[u8]>, enabling DMA coherent allocations to be exposed as readable binary files. The implementation handles offset tracking and bounds checking, copying data from the coherent allocation to userspace via write_dma(). Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: John Hubbard <jhubbard@nvidia.com> Tested-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260319212658.2541610-4-ttabi@nvidia.com [ Rebase onto Coherent<T> changes. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-25rust: uaccess: add write_dma() for copying from DMA buffers to userspaceTimur Tabi
Add UserSliceWriter::write_dma() to copy data from a Coherent<[u8]> to userspace. This provides a safe interface for copying DMA buffer contents to userspace without requiring callers to work with raw pointers. Because write_dma() and write_slice() have common code, factor that code out into a helper function, write_raw(). The method handles bounds checking and offset calculation internally, wrapping the unsafe copy_to_user() call. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: John Hubbard <jhubbard@nvidia.com> Tested-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260319212658.2541610-3-ttabi@nvidia.com [ Rebase onto Coherent<T> changes; remove unnecessary turbofish from cast(). - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-24rust: device: add device name methodTimur Tabi
Add a name() method to the `Device` type, which returns a CStr that contains the device name. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Tested-by: John Hubbard <jhubbard@nvidia.com> Tested-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260319212658.2541610-2-ttabi@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-24rust: regulator: do not assume that regulator_get() returns non-nullAlice Ryhl
The Rust `Regulator` abstraction uses `NonNull` to wrap the underlying `struct regulator` pointer. When `CONFIG_REGULATOR` is disabled, the C stub for `regulator_get` returns `NULL`. `from_err_ptr` does not treat `NULL` as an error, so it was passed to `NonNull::new_unchecked`, causing undefined behavior. Fix this by using a raw pointer `*mut bindings::regulator` instead of `NonNull`. This allows `inner` to be `NULL` when `CONFIG_REGULATOR` is disabled, and leverages the C stubs which are designed to handle `NULL` or are no-ops. Fixes: 9b614ceada7c ("rust: regulator: add a bare minimum regulator abstraction") Reported-by: Miguel Ojeda <ojeda@kernel.org> Closes: https://lore.kernel.org/r/20260322193830.89324-1-ojeda@kernel.org Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Link: https://patch.msgid.link/20260324-regulator-fix-v1-1-a5244afa3c15@google.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-03-23rust: dma: remove dma::CoherentAllocation<T>Danilo Krummrich
Now that everything has been converted to the new dma::Coherent<T> API, remove dma::CoherentAllocation<T>. Suggested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/DH8O47F2GM1Z.3H3E13RSKIV22@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-23rust: dma: add Coherent:init() and Coherent::init_with_attrs()Danilo Krummrich
Analogous to Coherent::zeroed() and Coherent::zeroed_with_attrs(), add Coherent:init() and Coherent::init_with_attrs() which both take an impl Init<T, E> argument initializing the DMA coherent memory. Compared to CoherentInit, Coherent::init() is a one-shot constructor that runs an Init closure and immediately exposes the DMA handle, whereas CoherentInit is a multi-stage initializer that provides safe &mut T access by withholding the DMA address until converted to Coherent. Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260320194626.36263-6-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-23rust: dma: introduce dma::CoherentBox for memory initializationDanilo Krummrich
Currently, dma::Coherent cannot safely provide (mutable) access to its underlying memory because the memory might be concurrently accessed by a DMA device. This makes it difficult to safely initialize the memory before handing it over to the hardware. Introduce dma::CoherentBox, a type that encapsulates a dma::Coherent before its DMA address is exposed to the device. dma::CoherentBox can guarantee exclusive access to the inner dma::Coherent and implement Deref and DerefMut. Once the memory is properly initialized, dma::CoherentBox can be converted into a regular dma::Coherent. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260320194626.36263-5-dakr@kernel.org [ Remove unnecessary trait bounds. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-23rust: dma: add zeroed constructor to `Coherent`Gary Guo
These constructors create a coherent container of a single object instead of slice. They are named `zeroed` and `zeroed_with_attrs` to emphasis that they are created initialized zeroed. It is intended that there'll be new constructors that take `PinInit` instead of zeroing. Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260320194626.36263-4-dakr@kernel.org [ Use kernel import style. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-23rust: dma: add generalized container for types other than slicesGary Guo
Currently, `CoherentAllocation` is concecptually a DMA coherent container of a slice of `[T]` of runtime-checked length. Generalize it by creating `dma::Coherent<T>` which can hold any value of `T`. `Coherent::alloc_with_attrs` is implemented but not yet exposed, as I believe we should not expose the way to obtain an uninitialized coherent region. `Coherent<[T]>` provides a `len` method instead of the previous `count()` method to be consistent with methods on slices. The existing type is re-defined as a type alias of `Coherent<[T]>` to ease transition. Methods in use are not yet removed. Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260320194626.36263-3-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-23rust: dma: use "kernel vertical" style for importsDanilo Krummrich
Convert all imports to use "kernel vertical" style. With this, subsequent patches neither introduce unrelated changes nor leave an inconsistent import pattern. While at it, drop unnecessary imports covered by prelude::*. Link: https://docs.kernel.org/rust/coding-guidelines.html#imports Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260320194626.36263-2-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-23rust: gpu: Add GPU buddy allocator bindingsJoel Fernandes
Add safe Rust abstractions over the Linux kernel's GPU buddy allocator for physical memory management. The GPU buddy allocator implements a binary buddy system useful for GPU physical memory allocation. nova-core will use it for physical memory allocation. Cc: Nikola Djukic <ndjukic@nvidia.com> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260320045711.43494-2-joelagnelf@nvidia.com [ * Use doc-comments for GpuBuddyAllocMode methods and GpuBuddyGuard, * Fix comma splice in GpuBuddyParams::chunk_size doc-comment, * Remove redundant summary in GpuBuddy::new doc-comment, * Drop Rust helper for gpu_buddy_block_size(). - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-23rust: interop: Add list module for C linked list interfaceJoel Fernandes
Add a new module `kernel::interop::list` for working with C's doubly circular linked lists. Provide low-level iteration over list nodes. Typed iteration over actual items is provided with a `clist_create` macro to assist in creation of the `CList` type. Cc: Nikola Djukic <ndjukic@nvidia.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Gary Guo <gary@garyguo.net> Acked-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Link: https://patch.msgid.link/20260319210722.1543776-1-joelagnelf@nvidia.com [ * Remove stray empty comment and double blank line in doctest, * Improve wording and fix a few typos, * Use markdown emphasis instead of caps, * Move interop/mod.rs to interop.rs. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-23hrtimer: add usage examples to documentationAndreas Hindborg
Add documentation examples showing various ways to use hrtimers: - Box-allocated timers with shared state in Arc. - Arc-allocated timers. - Stack-based timers for scoped usage. - Mutable stack-based timers with shared state. Tested-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://msgid.link/20260219-hrtimer-examples-v6-19-rc1-v2-1-810cc06ca9f6@kernel.org Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
2026-03-23rust: time: make ClockSource unsafe traitFUJITA Tomonori
Mark the ClockSource trait as unsafe and document its safety requirements. Specifically, implementers must guarantee that their `ktime_get()` implementation returns a value in the inclusive range [0, KTIME_MAX]. Update all existing implementations to use `unsafe impl` with corresponding safety comments. Note that there could be potential users of a customized clock source [1] so we don't seal the trait. Link: https://lore.kernel.org/rust-for-linux/Z9xb1r1x5tOzAIZT@boqun-archlinux/ [1] Suggested-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://msgid.link/20250630131011.405219-1-fujita.tomonori@gmail.com [ Change range expressions in docs. - Andreas ] Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
2026-03-23rust/time: Add Delta::from_nanos()Lyude Paul
Since rvkms is going to need to create its own Delta instances, and we already have functions for creating Delta with every other unit of time. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://msgid.link/20251114184207.459335-1-lyude@redhat.com Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>