summaryrefslogtreecommitdiffstats
path: root/rust/kernel
AgeCommit message (Collapse)AuthorLines
2026-03-23rust: dma: add Coherent:init() and Coherent::init_with_attrs()Danilo Krummrich-0/+38
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-1/+153
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-8/+85
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-139/+226
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-4/+12
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-0/+622
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-0/+350
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-0/+336
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-6/+20
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-0/+6
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>
2026-03-23rust: str: improve safety comment for CString::try_from_fmtNakamura Shuta-1/+4
Improve the safety comment for the `inc_len()` call in `CString::try_from_fmt()` to clarify why `bytes_written()` is guaranteed not to exceed the buffer capacity. The current comment states that bytes written is bounded by size, but does not explain that this invariant is maintained because: 1. The `Formatter` is created with `size` as its capacity limit 2. The `?` operators on `write_fmt` and `write_str` ensure early return if writing exceeds this limit Suggested-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/rust-for-linux/20221114145329.0f47a3ab@GaryWorkstation/ Link: https://github.com/Rust-for-Linux/linux/issues/936 Signed-off-by: Nakamura Shuta <nakamura.shuta@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260119062925.1647-1-nakamura.shuta@gmail.com [ Updated tags: it was a suggestion from Gary from the mailing list (the linked issue is mostly about adding a `debug_assert_eq!`). - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-03-18rust: devres: embed struct devres_node directlyDanilo Krummrich-47/+140
Currently, the Devres<T> container uses devm_add_action() to register a devres callback. devm_add_action() allocates a struct action_devres, which on top of struct devres_node, just keeps a data pointer and release function pointer. This is an unnecessary indirection, given that analogous to struct devres, the Devres<T> container can just embed a struct devres_node directly without an additional allocation. In contrast to struct devres, we don't need to force an alignment of ARCH_DMA_MINALIGN (as struct devres does to account for the worst case) since we have generics in Rust. I.e. the compiler already ensures correct alignment of the embedded T in Devres<T>. Thus, get rid of devm_add_action() and instead embed a struct devres_node directly. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/20260213220718.82835-6-dakr@kernel.org [ * Improve comment about core::any::type_name(), * add #[must_use] to devres_node_remove(), * use container_of!() in devres_node_free_node(). - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17Merge tag 'rust_io-7.1-rc1' of ↵Danilo Krummrich-365/+1857
git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core into drm-rust-next Register abstraction and I/O infrastructure improvements Introduce the register!() macro to define type-safe I/O register accesses. Refactor the IoCapable trait into a functional trait, which simplifies I/O backends and removes the need for overloaded Io methods. This is a stable tag for other trees to merge. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17Merge tag 'rust_io-7.1-rc1' into driver-core-nextDanilo Krummrich-432/+2248
Register abstraction and I/O infrastructure improvements Introduce the register!() macro to define type-safe I/O register accesses. Refactor the IoCapable trait into a functional trait, which simplifies I/O backends and removes the need for overloaded Io methods. This is a stable tag for other trees to merge. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17rust: io: introduce `write_reg` and `LocatedRegister`Alexandre Courbot-2/+120
Some I/O types, like fixed address registers, carry their location alongside their values. For these types, the regular `Io::write` method can lead into repeating the location information twice: once to provide the location itself, another time to build the value. We are also considering supporting making all register values carry their full location information for convenience and safety. Add a new `Io::write_reg` method that takes a single argument implementing `LocatedRegister`, a trait that decomposes implementors into a `(location, value)` tuple. This allows write operations on fixed offset registers to be done while specifying their name only once. Suggested-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/all/DH0XBLXZD81K.22SWIZ1ZAOW1@kernel.org/ Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260314-register-v9-8-86805b2f7e9d@nvidia.com [ Replace FIFO with VERSION register in the examples. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17rust: io: add `register!` macroAlexandre Courbot-1/+1233
Add a macro for defining hardware register types with I/O accessors. Each register field is represented as a `Bounded` of the appropriate bit width, ensuring field values are never silently truncated. Fields can optionally be converted to/from custom types, either fallibly or infallibly. The address of registers can be direct, relative, or indexed, supporting most of the patterns in which registers are arranged. Suggested-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/all/20250306222336.23482-6-dakr@kernel.org/ Co-developed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Gary Guo <gary@garyguo.net> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260314-register-v9-7-86805b2f7e9d@nvidia.com [ * Improve wording and formatting of doc-comments, * Import build_assert!(), * Add missing inline annotations, * Call static_assert!() with absolute path, * Use expect instead of allow. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17rust: io: use generic read/write accessors for primitive accessesAlexandre Courbot-68/+150
By providing the required `IoLoc` implementations on `usize`, we can leverage the generic accessors and reduce the number of unsafe blocks in the module. This also allows us to directly call the generic `read/write/update` methods with primitive types, so add examples illustrating this. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260314-register-v9-6-86805b2f7e9d@nvidia.com [ Slightly improve wording in doc-comment. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17rust: io: add IoLoc type and generic I/O accessorsAlexandre Courbot-0/+124
I/O accesses are defined by the following properties: - An I/O location, which consists of a start address, a width, and a type to interpret the read value as, - A value, which is returned for reads or provided for writes. Introduce the `IoLoc` trait, which allows implementing types to fully specify an I/O location. This allows I/O operations to be made generic through the new `read` and `write` methods. This design will allow us to factorize the I/O code working with primitives, and to introduce ways to perform I/O with a higher degree of control through register types. Co-developed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Gary Guo <gary@garyguo.net> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260314-register-v9-5-86805b2f7e9d@nvidia.com [ Fix incorrect reference to io_addr_assert() in try_update(). - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17rust: num: make Bounded::get constAlexandre Courbot-2/+5
There is a need to access the inner value of a `Bounded` in const context, notably for bitfields and registers. Remove the invariant check of `Bounded::get`, which allows us to make it const. Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260314-register-v9-4-86805b2f7e9d@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17rust: num: add `into_bool` method to `Bounded`Alexandre Courbot-0/+21
Single-bit numbers are typically treated as booleans. There is an `Into<bool>` implementation for those, but invoking it from contexts that lack type expectations is not always convenient. Add an `into_bool` method as a simpler shortcut. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Yury Norov <yury.norov@gmail.com> Tested-by: Dirk Behme <dirk.behme@de.bosch.com> Acked-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260314-register-v9-3-86805b2f7e9d@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17rust: num: add `shr` and `shl` methods to `Bounded`Alexandre Courbot-0/+42
Shifting a `Bounded` left or right changes the number of bits required to represent the value. Add methods that perform the shift and return a `Bounded` with the appropriately adjusted bit width. These methods are particularly useful for bitfield extraction. Suggested-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Tested-by: Dirk Behme <dirk.behme@de.bosch.com> Acked-by: Miguel Ojeda <ojeda@kernel.org> Acked-by: Yury Norov <ynorov@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260314-register-v9-2-86805b2f7e9d@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17rust: enable the `generic_arg_infer` featureAlexandre Courbot-0/+3
This feature is stable since 1.89, and used in subsequent patches. Reviewed-by: Gary Guo <gary@garyguo.net> Tested-by: Dirk Behme <dirk.behme@de.bosch.com> Acked-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260314-register-v9-1-86805b2f7e9d@nvidia.com [ Resolve merge conflict. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17rust: io: remove overloaded Io methods of MmioAlexandre Courbot-207/+0
Since `Mmio` now has the relevant implementations of `IoCapable`, the default methods of `Io` can be used in place of the overloaded ones. Remove them as well as the macros generating them. Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Acked-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260206-io-v2-6-71dea20a06e6@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17rust: pci: io: remove overloaded Io methods of ConfigSpaceAlexandre Courbot-74/+0
Since `ConfigSpace` now has the relevant implementations of `IoCapable`, the default methods of `Io` can be used in place of the overloaded ones. Remove them as well as the macros generating them. Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Acked-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260206-io-v2-5-71dea20a06e6@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17rust: io: remove legacy relaxed accessors of MmioAlexandre Courbot-40/+0
The relaxed access functionality is now provided by the `RelaxedMmio` wrapper type, and we don't have any user of the legacy methods left. Remove them. Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Acked-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260206-io-v2-4-71dea20a06e6@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17rust: io: provide Mmio relaxed ops through a wrapper typeAlexandre Courbot-0/+66
Relaxed I/O accessors for `Mmio` are currently implemented as an extra set of methods that mirror the ones defined in `Io`, but with the `_relaxed` suffix. This makes these methods impossible to use with generic code, which is a highly plausible proposition now that we have the `Io` trait. Address this by adding a new `RelaxedMmio` wrapper type for `Mmio` that provides its own `IoCapable` implementations relying on the relaxed C accessors. This makes it possible to use relaxed operations on a `Mmio` simply by wrapping it, and to use `RelaxedMmio` in code generic against `Io`. Acked-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260206-io-v2-3-71dea20a06e6@nvidia.com [ Use kernel import style in examples. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17rust: io: mem: use non-relaxed I/O ops in examplesAlexandre Courbot-4/+6
The `_relaxed` I/O variant methods are about to be replaced by a wrapper type exposing this access pattern with the regular methods of the `Io` trait. Thus replace the examples to use the regular I/O methods. Since these are examples, we want them to use the most standard ops anyway, and the relaxed variants were but an addition that was MMIO-specific. Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Acked-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260206-io-v2-2-71dea20a06e6@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17rust: io: turn IoCapable into a functional traitAlexandre Courbot-43/+163
`IoCapable<T>` is currently used as a marker trait to signal that the methods of the `Io` trait corresponding to `T` have been overridden by the implementor (the default implementations triggering a build-time error). This goes against the DRY principle and separates the signaling of the capability from its implementation, making it possible to forget a step while implementing a new `Io`. Another undesirable side-effect is that it makes the implementation of I/O backends boilerplate-y and convoluted: currently this is done using two levels of imbricated macros that generate unsafe code. Fix these issues by turning `IoCapable` into a functional trait that includes the raw implementation of the I/O access for `T` using unsafe methods that work with an arbitrary address. This allows us to turn the default methods of `Io` into regular methods that check the passed offset, turn it into an address, and call into the corresponding `IoCapable` functions, removing the need to overload them at all. `IoCapable` must still be implemented for all supported primitive types, which is still done more concisely using a macro, but this macro becomes much simpler and does not require calling into another one. Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Acked-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260206-io-v2-1-71dea20a06e6@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-15Merge tag 'v7.0-rc4' into drm-rust-nextDanilo Krummrich-121/+500
We need the latest fixes from drm-rust-fixes in drm-rust-next as well to build on top of. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-15rust: types: remove temporary re-exports of ARef and AlwaysRefCountedShankari Anand-2/+0
Remove the temporary re-exports of `ARef` and `AlwaysRefCounted` from `types.rs` now that all in-tree users have been updated to import them directly from `sync::aref`. These re-exports were originally added to avoid breaking the kernel build during the transition period while call sites were incrementally migrated. With all users updated, they are no longer needed. Suggested-by: Benno Lossin <lossin@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/1173 Signed-off-by: Shankari Anand <shankari.ak0208@gmail.com> Link: https://patch.msgid.link/20260102202714.184223-5-shankari.ak0208@gmail.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-03-15rust: usb: Update AlwaysRefCounted imports to use sync::arefShankari Anand-4/+2
Update call sites in `usb.rs` to import `AlwaysRefCounted` from `sync::aref` instead of `types`. This aligns with the ongoing effort to move `ARef` and `AlwaysRefCounted` to sync. Suggested-by: Benno Lossin <lossin@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/1173 Signed-off-by: Shankari Anand <shankari.ak0208@gmail.com> Link: https://patch.msgid.link/20260102202714.184223-4-shankari.ak0208@gmail.com [ Rebase. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-03-15rust: i2c: Update ARef and AlwaysRefCounted imports to use sync::arefShankari Anand-7/+6
Update call sites in `i2c.rs` to import `ARef` and `AlwaysRefCounted` from `sync::aref` instead of `types`. This aligns with the ongoing effort to move `ARef` and `AlwaysRefCounted` to sync. Suggested-by: Benno Lossin <lossin@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/1173 Signed-off-by: Shankari Anand <shankari.ak0208@gmail.com> Acked-by: Igor Korotin <igor.korotin.linux@gmail.com> Link: https://patch.msgid.link/20260102202714.184223-3-shankari.ak0208@gmail.com [ Move `ARef` import into the `kernel` `use` tree above. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-03-15rust: str: update `c_str!` documentationTamir Duberstein-3/+16
Now that all literals are C-Strings, update the documentation to explain that use of this macro should be limited to non-literal strings. Link: https://github.com/Rust-for-Linux/linux/issues/1075 Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260309-cstr-rename-macro-v2-1-25f7de75944e@kernel.org [ Apply sentence case to comment. Reword title. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-03-14Merge tag 'rust-fixes-7.0-2' of ↵Linus Torvalds-2/+3
git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux Pull Rust fixes from Miguel Ojeda: "Toolchain and infrastructure: - Remap paths to avoid absolute ones starting with the upcoming Rust 1.95.0 release. This improves build reproducibility, avoids leaking the exact path and avoids having the same path appear in two forms The approach here avoids remapping debug information as well, in order to avoid breaking tools that used the paths to access source files, which was the previous attempt that needed to be reverted - Allow 'unused_features' lint for the upcoming Rust 1.96.0 release. While well-intentioned, we do not benefit much from the new lint - Emit dependency information into '$(depfile)' directly to avoid a temporary '.d' file (it was an old approach) 'kernel' crate: - 'str' module: fix warning under '!CONFIG_BLOCK' by making 'NullTerminatedFormatter' public - 'cpufreq' module: suppress false positive Clippy warning 'pin-init' crate: - Remove '#[disable_initialized_field_access]' attribute which was unsound. This means removing the support for structs with unaligned fields (through the 'repr(packed)' attribute), for now And document the load-bearing fact of field accessors (i.e. that they are required for soundness) - Replace shadowed return token by 'unsafe'-to-create token in order to remain sound in the face of the likely upcoming Type Alias Impl Trait (TAIT) and the next trait solver in upstream Rust" * tag 'rust-fixes-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux: rust: kbuild: allow `unused_features` rust: cpufreq: suppress clippy::double_parens in Policy doctest rust: pin-init: replace shadowed return token by `unsafe`-to-create token rust: pin-init: internal: init: document load-bearing fact of field accessors rust: pin-init: internal: init: remove `#[disable_initialized_field_access]` rust: build: remap path to avoid absolute path rust: kbuild: emit dep-info into $(depfile) directly rust: str: make NullTerminatedFormatter public
2026-03-13Merge tag 'drm-rust-fixes-2026-03-12' of ↵Dave Airlie-65/+388
https://gitlab.freedesktop.org/drm/rust/kernel into drm-fixes Core Changes: - Fix safety issue in dma_read! and dma_write!. Driver Changes (Nova Core): - Fix UB in DmaGspMem pointer accessors. - Fix stack overflow in GSP memory allocation. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/abNBSol3CLRCqlkZ@google.com
2026-03-12rust: cpufreq: suppress clippy::double_parens in Policy doctestJohn Hubbard-0/+1
The kernel fmt! proc macro wraps each format argument as &(arg). Passing a tuple such as (a, b) produces &((a, b)) after expansion. Clippy flags that as double_parens, but it is a false positive fixed in Clippy 1.92 [1] [2]. Suppress the warning on the affected doctest function with a reason attribute so it can be removed once the minimum toolchain moves past 1.92. [ We may end up deciding to support per-version Clippy lints, in which case we will need [3]. In the future, if [4] gets fixed, we may be able to use `Delimiter::None` as Gary suggested in [5]. Link: https://lore.kernel.org/rust-for-linux/20260307170929.153892-1-ojeda@kernel.org/ [3] Link: https://github.com/rust-lang/rust/issues/67062 [4] Link: https://lore.kernel.org/rust-for-linux/DGUA5GY2DGYN.3PG0FKLG7GFN1@garyguo.net/ [5] - Miguel ] Link: https://github.com/rust-lang/rust-clippy/issues/15852 [1] Link: https://github.com/rust-lang/rust-clippy/pull/15939 [2] Suggested-by: Gary Guo <gary@garyguo.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://patch.msgid.link/20260312041934.362840-2-jhubbard@nvidia.com [ Reworded to replace GitHub-like short link with full URLs in Link tags. Reworded reason string to match the style of a couple others we have elsewhere. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-03-11rust: disallow use of `CStr::as_ptr` and `CStr::from_ptr`Gary Guo-0/+3
As kernel always use unsigned char and not the platform ABI's default, an user should always use `as_char_ptr` provided via `CStrExt` instead. Therefore configure `disallow-methods` feature of clippy to catch incorrect usage. Similarly, the dual `from_ptr` is also disallowed. [ As an example, without the previous commit, we would get a warning like: warning: use of a disallowed method `core::ffi::CStr::as_ptr` --> rust/kernel/task.rs:422:54 | 422 | unsafe { crate::bindings::__might_sleep(file.as_ptr().cast(), loc.line() as i32) } | ^^^^^^ help: kernel's `char` is always unsigned, use `as_char_ptr` instead: `kernel::prelude::CStrExt::as_char_ptr` | = help: for further information visit https://rust-lang.github.io/rust-clippy/rust-1.94.0/index.html#disallowed_methods = note: `-W clippy::disallowed-methods` implied by `-W clippy::all` = help: to override `-W clippy::all` add `#[allow(clippy::disallowed_methods)]` - Miguel ] Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Tamir Duberstein <tamird@kernel.org> Link: https://patch.msgid.link/20260203130745.868762-2-gary@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-03-10rust: task: use `as_char_ptr` instead of `as_ptr().cast()`Gary Guo-4/+3
`as_char_ptr` would provide the correct (unsigned char) type without needing to convert to an intermediate type and cast the pointer. The `as_ptr()` function is going to be disallowed by clippy warning, so fix this usage. This is used only if CONFIG_DEBUG_ATOMIC_SLEEP=y. Instead of conditionally importing `CStrExt`, import it via prelude instead, and remove other imports that are already available via the prelude. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202601221157.89t3Sqbl-lkp@intel.com/ Signed-off-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260203130745.868762-1-gary@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-03-10rust: add EMSGSIZE error codeEliot Courtney-0/+1
Add the EMSGSIZE error code, which indicates that a message is too long. Tested-by: Zhi Wang <zhiw@nvidia.com> Acked-by: Miguel Ojeda <ojeda@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260306-cmdq-continuation-v6-3-cc7b629200ee@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-09Merge tag 'v7.0-rc3' into driver-core-nextDanilo Krummrich-0/+8
We need the driver-core fixes in here as well to build on top of. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-08rust: atomic: Update a safety comment in impl of `fetch_add()`Andreas Hindborg-1/+1
The safety comment used in the implementation of `fetch_add()` could be read as just saying something it is true without justifying it. Update the safety comment to include justification. Suggested-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org> Signed-off-by: Boqun Feng <boqun@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260220-atomic-sub-v3-3-e63cbed1d2aa@kernel.org Link: https://patch.msgid.link/20260303201701.12204-14-boqun@kernel.org
2026-03-08rust: sync: atomic: Update documentation for `fetch_add()`Andreas Hindborg-6/+4
The documentation for `fetch_add()` does not indicate that the original value is returned by `fetch_add()`. Update the documentation so this is clear. Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org> Signed-off-by: Boqun Feng <boqun@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260220-atomic-sub-v3-2-e63cbed1d2aa@kernel.org Link: https://patch.msgid.link/20260303201701.12204-13-boqun@kernel.org
2026-03-08rust: sync: atomic: Add fetch_sub()Andreas Hindborg-0/+48
Add `Atomic::fetch_sub()` with implementation and documentation in line with existing `Atomic::fetch_add()` implementation. Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org> Signed-off-by: Boqun Feng <boqun@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260220-atomic-sub-v3-1-e63cbed1d2aa@kernel.org Link: https://patch.msgid.link/20260303201701.12204-12-boqun@kernel.org
2026-03-08rust: sync: atomic: Add atomic operation helpers over raw pointersBoqun Feng-0/+150
In order to synchronize with C or external memory, atomic operations over raw pointers are need. Although there is already an `Atomic::from_ptr()` to provide a `&Atomic<T>`, it's more convenient to have helpers that directly perform atomic operations on raw pointers. Hence a few are added, which are basically an `Atomic::from_ptr().op()` wrapper. Note: for naming, since `atomic_xchg()` and `atomic_cmpxchg()` have a conflict naming to 32bit C atomic xchg/cmpxchg, hence the helpers are just named as `xchg()` and `cmpxchg()`. For `atomic_load()` and `atomic_store()`, their 32bit C counterparts are `atomic_read()` and `atomic_set()`, so keep the `atomic_` prefix. [boqun: Fix typo spotted by Alice and fix broken sentence spotted by Gary] Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260120115207.55318-3-boqun.feng@gmail.com Link: https://patch.msgid.link/20260303201701.12204-11-boqun@kernel.org
2026-03-08rust: list: Use AtomicFlag in AtomicTrackerFUJITA Tomonori-4/+4
Make AtomicTracker use AtomicFlag instead of Atomic<bool> to avoid slow byte-sized RMWs on architectures that don't support them. Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Signed-off-by: Boqun Feng <boqun@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260129122622.3896144-3-tomo@aliasing.net Link: https://patch.msgid.link/20260303201701.12204-10-boqun@kernel.org
2026-03-08rust: sync: atomic: Add performance-optimal Flag type for atomic booleansFUJITA Tomonori-0/+142
Add AtomicFlag type for boolean flags. Document when AtomicFlag is generally preferable to Atomic<bool>: in particular, when RMW operations such as xchg()/cmpxchg() may be used and minimizing memory usage is not the top priority. On some architectures without byte-sized RMW instructions, Atomic<bool> can be slower for RMW operations. Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Signed-off-by: Boqun Feng <boqun@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260129122622.3896144-2-tomo@aliasing.net Link: https://patch.msgid.link/20260303201701.12204-9-boqun@kernel.org
2026-03-08rust: sync: atomic: Add Atomic<*{mut,const} T> supportBoqun Feng-10/+72
Atomic pointer support is an important piece of synchronization algorithm, e.g. RCU, hence provide the support for that. Note that instead of relying on atomic_long or the implementation of `Atomic<usize>`, a new set of helpers (atomic_ptr_*) is introduced for atomic pointer specifically, this is because ptr2int casting would lose the provenance of a pointer and even though in theory there are a few tricks the provenance can be restored, it'll still be a simpler implementation if C could provide atomic pointers directly. The side effects of this approach are: we don't have the arithmetic and logical operations for pointers yet and the current implementation only works on ARCH_SUPPORTS_ATOMIC_RMW architectures, but these are implementation issues and can be added later. Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Link: https://patch.msgid.link/20260120140503.62804-3-boqun.feng@gmail.com Link: https://patch.msgid.link/20260303201701.12204-8-boqun@kernel.org
2026-03-08rust: sync: atomic: Clarify the need of CONFIG_ARCH_SUPPORTS_ATOMIC_RMWBoqun Feng-6/+13
Currently, since all the architectures that support Rust all have CONFIG_ARCH_SUPPORTS_ATOMIC_RMW selected, the helpers of atomic load/store on i8 and i16 relies on CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y. It's generally fine since most of architectures support that. The plan for CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=n architectures is adding their (probably lock-based) atomic load/store for i8 and i16 as their atomic_{read,set}() and atomic64_{read,set}() counterpart when they plans to support Rust. Hence use a statis_assert!() to check this and remind the future us the need of the helpers. This is more clear than the #[cfg] on impl blocks of i8 and i16. Suggested-by: Dirk Behme <dirk.behme@gmail.com> Suggested-by: Benno Lossin <lossin@kernel.org> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260120140503.62804-2-boqun.feng@gmail.com Link: https://patch.msgid.link/20260303201701.12204-7-boqun@kernel.org
2026-03-08rust: sync: atomic: Add example for Atomic::get_mut()FUJITA Tomonori-0/+11
Add an example for Atomic::get_mut(). No functional change. Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Signed-off-by: Boqun Feng <boqun@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260128123313.3850604-1-tomo@aliasing.net Link: https://patch.msgid.link/20260303201701.12204-3-boqun@kernel.org
2026-03-08rust: sync: atomic: Remove bound `T: Sync` for `Atomic::from_ptr()`Boqun Feng-4/+1
Originally, `Atomic::from_ptr()` requires `T` being a `Sync` because I thought having the ability to do `from_ptr()` meant multiplle `&Atomic<T>`s shared by different threads, which was identical (or similar) to multiple `&T`s shared by different threads. Hence `T` was required to be `Sync`. However this is not true, since `&Atomic<T>` is not the same at `&T`. Moreover, having this bound makes `Atomic::<*mut T>::from_ptr()` impossible, which is definitely not intended. Therefore remove the `T: Sync` bound. [boqun: Fix title typo spotted by Alice & Gary] Fixes: 29c32c405e53 ("rust: sync: atomic: Add generic atomics") Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260120115207.55318-2-boqun.feng@gmail.com Link: https://patch.msgid.link/20260303201701.12204-2-boqun@kernel.org
generated by cgit v1.2.3 (git 2.46.0) at 2026-05-04 23:43:02 +0000