summaryrefslogtreecommitdiff
path: root/rust
AgeCommit message (Collapse)Author
2026-01-23rust: io: separate generic I/O helpers from MMIO implementationZhi Wang
The previous Io<SIZE> type combined both the generic I/O access helpers and MMIO implementation details in a single struct. This coupling prevented reusing the I/O helpers for other backends, such as PCI configuration space. Establish a clean separation between the I/O interface and concrete backends by separating generic I/O helpers from MMIO implementation. Introduce a new trait hierarchy to handle different access capabilities: - IoCapable<T>: A marker trait indicating that a backend supports I/O operations of a certain type (u8, u16, u32, or u64). - Io trait: Defines fallible (try_read8, try_write8, etc.) and infallibile (read8, write8, etc.) I/O methods with runtime bounds checking and compile-time bounds checking. - IoKnownSize trait: The marker trait for types support infallible I/O methods. Move the MMIO-specific logic into a dedicated Mmio<SIZE> type that implements the Io traits. Rename IoRaw to MmioRaw and update consumers to use the new types. Cc: Alexandre Courbot <acourbot@nvidia.com> Cc: Alice Ryhl <aliceryhl@google.com> Cc: Bjorn Helgaas <helgaas@kernel.org> Cc: Gary Guo <gary@garyguo.net> Cc: Danilo Krummrich <dakr@kernel.org> Cc: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Zhi Wang <zhiw@nvidia.com> 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/20260121202212.4438-3-zhiw@nvidia.com [ Add #[expect(unused)] to define_{read,write}!(). - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-23rust/drm: Fix Registration::{new,new_foreign_owned}() docsLyude Paul
Looks like we've actually had a malformed rustdoc reference in the rustdocs for Registration::new_foreign_owned() for a while that, when fixed, still couldn't resolve properly because it refers to a private item. This is probably leftover from when Registration::new() was public, so drop the documentation from that function and fixup the documentation for Registration::new_foreign_owned(). Signed-off-by: Lyude Paul <lyude@redhat.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Fixes: 0600032c54b7 ("rust: drm: add DRM driver registration") Cc: <stable@vger.kernel.org> # v6.16+ Link: https://patch.msgid.link/20260122221037.3462081-1-lyude@redhat.com
2026-01-23rust: devres: style for importsZhi Wang
Convert all imports in the devres to use "kernel vertical" style. Cc: Gary Guo <gary@garyguo.net> Cc: Miguel Ojeda <ojeda@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Zhi Wang <zhiw@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260121202212.4438-2-zhiw@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-23rust: proc-macro2: rebuild if the version text changesMiguel Ojeda
The Rust compiler cannot use dependencies built by other versions, e.g.: error[E0514]: found crate `proc_macro2` compiled by an incompatible version of rustc --> rust/quote/ext.rs:5:5 | 5 | use proc_macro2::{TokenStream, TokenTree}; | ^^^^^^^^^^^ | = note: the following crate versions were found: crate `proc_macro2` compiled by rustc 1.92.0 (ded5c06cf 2025-12-08): ./rust/libproc_macro2.rlib = help: please recompile that crate using this compiler (rustc 1.93.0 (254b59607 2026-01-19)) (consider running `cargo clean` first) Thus trigger a rebuild if the version text changes like we do in other top-level cases (e.g. see commit aeb0e24abbeb ("kbuild: rust: replace proc macros dependency on `core.o` with the version text")). The build errors for now are hard to trigger, since we do not yet use the new crates we just introduced (the use cases are coming in the next merge window), but they can still be seen if e.g. one manually removes one of the targets, so fix it already. Fixes: 158a3b72118a ("rust: proc-macro2: enable support in kbuild") Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260122054135.138445-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-01-22rust: iommu: fix `srctree` link warningMiguel Ojeda
The Rust kernel code should be kept `rustdoc`-clean [1]. Our custom `srctree` link checker in the `rustdoc` target reports: warning: srctree/ link to include/io-pgtable.h does not exist Thus fix it. Link: https://rust-for-linux.com/contributing#submit-checklist-addendum [1] Fixes: 2e2f6b0ef855 ("rust: iommu: add io_pgtable abstraction") Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-01-22rust: iommu: fix Rust formattingMiguel Ojeda
The Rust kernel code should be kept `rustfmt`-clean [1]. Thus run the `rustfmt` target to fix the formatting issue. Link: https://rust-for-linux.com/contributing#submit-checklist-addendum [1] Fixes: 2e2f6b0ef855 ("rust: iommu: add io_pgtable abstraction") Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-01-21rust: block: mq: use pin_init::zeroed() for tag_setKe Sun
Replace unsafe core::mem::zeroed() with pin_init::zeroed() for blk_mq_tag_set initialization. Signed-off-by: Ke Sun <sunke@kylinos.cn> Acked-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20260120083824.477339-4-sunke@kylinos.cn Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-01-21rust: block: mq: use pin_init::zeroed() for queue_limitsKe Sun
Replace unsafe core::mem::zeroed() with pin_init::zeroed() for queue_limits initialization. Signed-off-by: Ke Sun <sunke@kylinos.cn> Acked-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20260120083824.477339-3-sunke@kylinos.cn Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-01-20net: remove HIPPI support and RoadRunner HIPPI driverEthan Nelson-Moore
HIPPI has not been relevant for over two decades. It was rapidly eclipsed by Fibre Channel, and even when it was new, it was confined to very high-end hardware. The HIPPI code has only received tree-wide changes and fixes by inspection in the entire Git history. Remove HIPPI support and the rrunner HIPPI driver, and move the former maintainer to the CREDITS file. Keep the include/uapi/linux/if_hippi.h header because it is used by the TUN code, and to avoid breaking userspace, however unlikely that may be. Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Link: https://patch.msgid.link/20260119022451.22344-1-enelsonmoore@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-20rust: pwm: Add __rust_helper to helpersAlice Ryhl
This is needed to inline these helpers into Rust code. Signed-off-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Michal Wilczynski <m.wilczynski@samsung.com> Link: https://patch.msgid.link/20260105-define-rust-helper-v2-14-51da5f454a67@google.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2026-01-20rust: pwm: Simplify to_result call sites and unsafe blocksKari Argillander
Remove unnecessary temporary variables around to_result() calls and move trailing semicolons outside unsafe blocks to improve readability and produce cleaner rustfmt output. No functional change intended. Signed-off-by: Kari Argillander <kari.argillander@gmail.com> Acked-by: Michal Wilczynski <m.wilczynski@samsung.com> Link: https://patch.msgid.link/20260102-pwm-rust-v2-2-2702ce57d571@gmail.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2026-01-20rust: pwm: Fix potential memory leak on init errorKari Argillander
When initializing a PWM chip using pwmchip_alloc(), the allocated device owns an initial reference that must be released on all error paths. If __pinned_init() were to fail, the allocated pwm_chip would currently leak because the error path returns without calling pwmchip_put(). Fixes: 7b3dce814a15 ("rust: pwm: Add Kconfig and basic data structures") Signed-off-by: Kari Argillander <kari.argillander@gmail.com> Acked-by: Michal Wilczynski <m.wilczynski@samsung.com> Link: https://patch.msgid.link/20260102-pwm-rust-v2-1-2702ce57d571@gmail.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2026-01-20rust: pwm: Add UnregisteredChip wrapper around ChipMarkus Probst
The `pwm::Registration::register` function provides no guarantee that the function isn't called twice with the same pwm chip, which is considered unsafe. Add `pwm::UnregisteredChip` as wrapper around `pwm::Chip`. Implement `pwm::UnregisteredChip::register` for the registration. This function takes ownership of `pwm::UnregisteredChip` and therefore guarantees that the registration can't be called twice on the same pwm chip. Signed-off-by: Markus Probst <markus.probst@posteo.de> Tested-by: Michal Wilczynski <m.wilczynski@samsung.com> Acked-by: Michal Wilczynski <m.wilczynski@samsung.com> Link: https://patch.msgid.link/20251202-pwm_safe_register-v2-1-7a2e0d1e287f@posteo.de [ukleinek: fixes a typo that Michal pointed out during review] Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2026-01-20rust: pwm: Update ARef and AlwaysRefCounted imports to use sync::arefShankari Anand
Update call sites in `pwm.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: Michal Wilczynski <m.wilczynski@samsung.com> Link: https://patch.msgid.link/20251123092438.182251-7-shankari.ak0208@gmail.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2026-01-19rust: debugfs: Use kernel Atomic type in docs exampleFUJITA Tomonori
Switch the read_callback_file() documentation example from core::sync::atomic::AtomicU32 to the kernel's Atomic because Rust native atomics are not allowed to use in kernel. Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251203000411.30434-1-fujita.tomonori@gmail.com [ Use kernel vertical import style. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-19rust: iommu: add io_pgtable abstractionAsahi Lina
This will be used by the Tyr driver to create and modify the page table of each address space on the GPU. Each time a mapping gets created or removed by userspace, Tyr will call into GPUVM, which will figure out which calls to map_pages and unmap_pages are required to map the data in question in the page table so that the GPU may access those pages when using that address space. The Rust type wraps the struct using a raw pointer rather than the usual Opaque+ARef approach because Opaque+ARef requires the target type to be refcounted. Signed-off-by: Asahi Lina <lina+kernel@asahilina.net> Acked-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Tested-by: Deborah Brouwer <deborah.brouwer@collabora.com> Co-developed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Danilo Krummrich <dakr@kernel.org> [joro: Fixed up Rust import style] Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-01-19Merge 6.19-rc6 usb-nextGreg Kroah-Hartman
We need the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-19rust: rbtree: reduce unsafe blocks on pointer derefsOnur Özkan
Refactors parts of the get() and find_best_match() traversal logic to minimize the scope of unsafe blocks and avoid duplicating same safety comments. One of the removed comments was also misleading: // SAFETY: `node` is a non-null node... Ordering::Equal => return Some(unsafe { &(*this).value }), as `node` should have been `this`. No functional changes intended; this is purely a safety improvement that reduces the amount of unsafe blocks while keeping all invariants intact. [ Alice writes: "One consequence of creating a &_ to the bindings::rb_node struct means that we assert immutability for the entire struct and not just the rb_left/rb_right fields, but I have verified that this is ok." - Miguel ] Signed-off-by: Onur Özkan <work@onurozkan.dev> Reviewed-by: Charalampos Mitrodimas <charmitro@posteo.net> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20251113144547.502-1-work@onurozkan.dev [ Reworded title and replaced `cursor_lower_bound()` with `find_best_match()` in message. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-01-19rust: kunit: replace `kernel::c_str!` with C-StringsTamir Duberstein
C-String literals were added in Rust 1.77. Replace instances of `kernel::c_str!` with C-String literals where possible. Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <lossin@kernel.org> Signed-off-by: Tamir Duberstein <tamird@gmail.com> Reviewed-by: David Gow <davidgow@google.com> Link: https://patch.msgid.link/20251222-cstr-kunit-v1-1-39d999672f35@gmail.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-01-19rust: i2c: replace `kernel::c_str!` with C-StringsTamir Duberstein
C-String literals were added in Rust 1.77. Replace instances of `kernel::c_str!` with C-String literals where possible. Signed-off-by: Tamir Duberstein <tamird@gmail.com> Acked-by: Igor Korotin <igor.korotin.linux@gmail.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Link: https://patch.msgid.link/20251222-cstr-i2c-v1-1-df1c258d4615@gmail.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-01-19rust: ptr: replace unneeded use of `build_assert`Alexandre Courbot
Since `ALIGN` is a const parameter, this assertion can be done in const context using the `assert!` macro. Suggested-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20251216-ptr_assert-v1-1-d8b2d5c5741d@nvidia.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-01-19rust: build_assert: add instructions for use with function argumentsAlexandre Courbot
`build_assert` relies on the compiler to optimize out its error path, lest build fails with the dreaded error: ERROR: modpost: "rust_build_error" [path/to/module.ko] undefined! It has been observed that very trivial code performing I/O accesses (sometimes even using an immediate value) would seemingly randomly fail with this error whenever `CLIPPY=1` was set. The same behavior was also observed until different, very similar conditions [1][2]. The cause appears to be that the failing function is eventually using `build_assert` with its argument, but is only annotated with `#[inline]`. This gives the compiler freedom to not inline the function, which it notably did when Clippy was active, triggering the error. The fix is to annotate functions passing their argument to `build_assert` with `#[inline(always)]`, telling the compiler to be as aggressive as possible with their inlining. This is also the correct behavior as inlining is mandatory for correct behavior in these cases. Add a paragraph instructing to annotate such functions with `#[inline(always)]` in `build_assert`'s documentation, and split its example to illustrate. Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20251208-io-build-assert-v3-1-98aded02c1ea@nvidia.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-01-18rust: num: bounded: add missing comment for always inlined functionAlexandre Courbot
This code is always inlined to avoid a build error if the error path of `build_assert` cannot be optimized out. Add a comment justifying the `#[inline(always)]` property to avoid it being taken away by mistake. Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20251208-io-build-assert-v3-7-98aded02c1ea@nvidia.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-01-18rust: sync: refcount: always inline functions using build_assert with argumentsAlexandre Courbot
`build_assert` relies on the compiler to optimize out its error path. Functions using it with its arguments must thus always be inlined, otherwise the error path of `build_assert` might not be optimized out, triggering a build error. Cc: stable@vger.kernel.org Fixes: bb38f35b35f9 ("rust: implement `kernel::sync::Refcount`") Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251208-io-build-assert-v3-5-98aded02c1ea@nvidia.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-01-18rust: bits: always inline functions using build_assert with argumentsAlexandre Courbot
`build_assert` relies on the compiler to optimize out its error path. Functions using it with its arguments must thus always be inlined, otherwise the error path of `build_assert` might not be optimized out, triggering a build error. Cc: stable@vger.kernel.org Fixes: cc84ef3b88f4 ("rust: bits: add support for bits/genmask macros") Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20251208-io-build-assert-v3-4-98aded02c1ea@nvidia.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-01-17rust: pin-init: Implement `InPlaceWrite<T>` for `&'static mut MaybeUninit<T>`Oleksandr Babak
This feature allows users to use `&'static mut MaybeUninit<T>` as a place to initialize the value. It mirrors an existing implemetation for `Box<MaybeUninit>`, but enables users to use external allocation mechanisms such as `static_cell` [1]. Signed-off-by: Oleksandr Babak <alexanderbabak@proton.me> Link: https://crates.io/crates/static_cell [1] [ Added link to `static_cell` - Benno ] Signed-off-by: Benno Lossin <lossin@kernel.org>
2026-01-17rust: pin-init: internal: init: simplify Zeroable safety checkBenno Lossin
The `Zeroable` type check uses a small dance with a raw pointer to aid type inference. It turns out that this is not necessary and type inference is powerful enough to resolve any ambiguity. Thus remove it. Suggested-by: Gary Guo <gary@garyguo.net> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Benno Lossin <lossin@kernel.org>
2026-01-17rust: pin-init: internal: init: add escape hatch for referencing initialized ↵Benno Lossin
fields The initializer macro emits mutable references for already initialized fields, which allows modifying or accessing them later in code blocks or when initializing other fields. This behavior results in compiler errors when combining with packed structs, since those do not permit creating references to misaligned fields. For example: #[repr(C, packed)] struct Foo { a: i8, b: i32, } fn main() { let _ = init!(Foo { a: -42, b: 42 }); } This will lead to an error like this: error[E0793]: reference to field of packed struct is unaligned --> tests/ui/compile-fail/init/packed_struct.rs:10:13 | 10 | let _ = init!(Foo { a: -42, b: 42 }); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: this struct is 1-byte aligned, but the type of this field may require higher alignment = note: creating a misaligned reference is undefined behavior (even if that reference is never dereferenced) = help: copy the field contents to a local variable, or replace the reference with a raw pointer and use `read_unaligned`/`write_unaligned` (loads and stores via `*p` must be properly aligned even when using raw pointers) = note: this error originates in the macro `init` (in Nightly builds, run with -Z macro-backtrace for more info) This was requested by Janne Grunau [1] and will most certainly be used by the kernel when we eventually end up with trying to initialize packed structs. Thus add an initializer attribute `#[disable_initialized_field_access]` that does what the name suggests: do not generate references to already initialized fields. There is space for future work: add yet another attribute which can be applied on fields of initializers that ask for said field to be made accessible. We can add that when the need arises. Requested-by: Janne Grunau <j@jannau.net> Link: https://lore.kernel.org/all/20251206170214.GE1097212@robin.jannau.net [1] Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Benno Lossin <lossin@kernel.org>
2026-01-17rust: pin-init: internal: init: add support for attributes on initializer fieldsBenno Lossin
Initializer fields ought to support the same attributes that are allowed in struct initializers on fields. For example, `cfg` or lint levels such as `expect`, `allow` etc. Add parsing support for these attributes using syn to initializer fields and adjust the macro expansion accordingly. Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Benno Lossin <lossin@kernel.org>
2026-01-17rust: init: use `#[default_error(err)]` for the initializer macrosBenno Lossin
Initializer macros should use this attribute instead of manually parsing the macro's input. This is because the syntax is now parsed using `syn`, which permits more complex constructs to be parsed. In addition, this ensures that the kernel's initializer marcos will have the exact same syntax as the ones from pin-init. Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Benno Lossin <lossin@kernel.org>
2026-01-17rust: pin-init: add `#[default_error(<type>)]` attribute to initializer macrosBenno Lossin
The `#[default_error(<type>)]` attribute can be used to supply a default type as the error used for the `[pin_]init!` macros. This way one can easily define custom `try_[pin_]init!` variants that default to your project specific error type. Just write the following declarative macro: macro_rules! try_init { ($($args:tt)*) => { ::pin_init::init!( #[default_error(YourCustomErrorType)] $($args)* ) } } Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Benno Lossin <lossin@kernel.org>
2026-01-17rust: pin-init: rewrite the initializer macros using `syn`Benno Lossin
Rewrite the initializer macros `[pin_]init!` using `syn`. No functional changes intended aside from improved error messages on syntactic and semantical errors. For example if one forgets to use `<-` with an initializer (and instead uses `:`): impl Bar { fn new() -> impl PinInit<Self> { ... } } impl Foo { fn new() -> impl PinInit<Self> { pin_init!(Self { bar: Bar::new() }) } } Then the declarative macro would report: error[E0308]: mismatched types --> tests/ui/compile-fail/init/colon_instead_of_arrow.rs:21:9 | 14 | fn new() -> impl PinInit<Self> { | ------------------ the found opaque type ... 21 | pin_init!(Self { bar: Bar::new() }) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | | | expected `Bar`, found opaque type | arguments to this function are incorrect | = note: expected struct `Bar` found opaque type `impl pin_init::PinInit<Bar>` note: function defined here --> $RUST/core/src/ptr/mod.rs | | pub const unsafe fn write<T>(dst: *mut T, src: T) { | ^^^^^ = note: this error originates in the macro `$crate::__init_internal` which comes from the expansion of the macro `pin_init` (in Nightly builds, run with -Z macro-backtrace for more info) And the new error is: error[E0308]: mismatched types --> tests/ui/compile-fail/init/colon_instead_of_arrow.rs:21:31 | 14 | fn new() -> impl PinInit<Self> { | ------------------ the found opaque type ... 21 | pin_init!(Self { bar: Bar::new() }) | --- ^^^^^^^^^^ expected `Bar`, found opaque type | | | arguments to this function are incorrect | = note: expected struct `Bar` found opaque type `impl pin_init::PinInit<Bar>` note: function defined here --> $RUST/core/src/ptr/mod.rs | | pub const unsafe fn write<T>(dst: *mut T, src: T) { | ^^^^^ Importantly, this error gives much more accurate span locations, pointing to the offending field, rather than the entire macro invocation. Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Benno Lossin <lossin@kernel.org>
2026-01-17rust: pin-init: add `?Sized` bounds to traits in `#[pin_data]` macroBenno Lossin
The `#[pin_data]` macro uses some auxiliary traits to ensure that a user does not implement `Drop` for the annotated struct, as that is unsound and can lead to UB. However, if the struct that is annotated is `!Sized`, the current bounds do not work, because `Sized` is an implicit bound for generics. This is *not* a soundness hole of pin-init, as it currently is impossible to construct an unsized struct using pin-init. Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Benno Lossin <lossin@kernel.org>
2026-01-17rust: pin-init: rewrite `#[pin_data]` using `syn`Benno Lossin
Rewrite the attribute macro `#[pin_data]` using `syn`. No functional changes intended aside from improved error messages on syntactic and semantical errors. For example if one forgets a comma at the end of a field: #[pin_data] struct Foo { a: Box<Foo> b: Box<Foo> } The declarative macro reports the following errors: error: expected `,`, or `}`, found `b` --> tests/ui/compile-fail/pin_data/missing_comma.rs:5:16 | 5 | a: Box<Foo> | ^ help: try adding a comma: `,` error: recursion limit reached while expanding `$crate::__pin_data!` --> tests/ui/compile-fail/pin_data/missing_comma.rs:3:1 | 3 | #[pin_data] | ^^^^^^^^^^^ | = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`$CRATE`) = note: this error originates in the macro `$crate::__pin_data` which comes from the expansion of the attribute macro `pin_data` (in Nightly builds, run with -Z macro-backtrace for more info) The new `syn` version reports: error: expected `,`, or `}`, found `b` --> tests/ui/compile-fail/pin_data/missing_comma.rs:5:16 | 5 | a: Box<Foo> | ^ help: try adding a comma: `,` error: expected `,` --> tests/ui/compile-fail/pin_data/missing_comma.rs:6:5 | 6 | b: Box<Foo> | ^ Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Benno Lossin <lossin@kernel.org>
2026-01-17rust: pin-init: rewrite the `#[pinned_drop]` attribute macro using `syn`Benno Lossin
Rewrite the attribute macro for implementing `PinnedDrop` using `syn`. Otherwise no functional changes intended aside from improved error messages on syntactic and semantical errors. For example: When missing the `drop` function in the implementation, the old error was: error: no rules expected `)` --> tests/ui/compile-fail/pinned_drop/no_fn.rs:6:1 | 6 | #[pinned_drop] | ^^^^^^^^^^^^^^ no rules expected this token in macro call | note: while trying to match keyword `fn` --> src/macros.rs | | fn drop($($sig:tt)*) { | ^^ = note: this error originates in the attribute macro `pinned_drop` (in Nightly builds, run with -Z macro-backtrace for more info) And the new one is: error[E0046]: not all trait items implemented, missing: `drop` --> tests/ui/compile-fail/pinned_drop/no_fn.rs:7:1 | 7 | impl PinnedDrop for Foo {} | ^^^^^^^^^^^^^^^^^^^^^^^ missing `drop` in implementation | = help: implement the missing item: `fn drop(self: Pin<&mut Self>, _: OnlyCallFromDrop) { todo!() }` Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Benno Lossin <lossin@kernel.org>
2026-01-17rust: pin-init: rewrite `derive(Zeroable)` and `derive(MaybeZeroable)` using ↵Benno Lossin
`syn` Rewrite the two derive macros for `Zeroable` using `syn`. One positive side effect of this change is that tuple structs are now supported by them. Additionally, syntax errors and the error emitted when trying to use one of the derive macros on an `enum` are improved. Otherwise no functional changes intended. For example: #[derive(Zeroable)] enum Num { A(u32), B(i32), } Produced this error before this commit: error: no rules expected keyword `enum` --> tests/ui/compile-fail/zeroable/enum.rs:5:1 | 5 | enum Num { | ^^^^ no rules expected this token in macro call | note: while trying to match keyword `struct` --> src/macros.rs | | $vis:vis struct $name:ident | ^^^^^^ Now the error is: error: cannot derive `Zeroable` for an enum --> tests/ui/compile-fail/zeroable/enum.rs:5:1 | 5 | enum Num { | ^^^^ error: cannot derive `Zeroable` for an enum Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Benno Lossin <lossin@kernel.org>
2026-01-17rust: pin-init: internal: add utility API for syn error handlingBenno Lossin
The API is similar to diagnostics handling in rustc and uses a `ErrorGuaranteed` value to signify that an error has been emitted. It supports both fatal errors (which abort the macro expansion immediately by returning `Err(ErrorGuaranteed)`) and non-fatal ones at generation time. These errors are appended to the token stream after generation has finished normally. This allows giving good errors while still expanding most of the code as expected to avoid the user encountering additional errors (for example missing definitions). Suggested-by: Gary Guo <gary@garyguo.net> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> [ remove duplicate word in commit message - Benno ] Signed-off-by: Benno Lossin <lossin@kernel.org>
2026-01-17rust: pin-init: add `syn` dependency and remove `proc-macro[2]` and `quote` ↵Benno Lossin
workarounds `syn` makes parsing Rust from proc-macros a lot simpler. `pin-init` has not used `syn` up until now, because the we did not support it. That changed in commit 54e3eae85562 ("Merge patch series "`syn` support""), so we can finally utilize the added ergonomics of parsing proc-macro input with `syn`. Previously we only had the `proc-macro` library available, whereas the user-space version also used `proc-macro2` and `quote`. Now both are available, so remove the workarounds. Due to these changes, clippy emits warnings about unnecessary `.to_string()` as `proc-macro2` provides an additional `PartialEq` impl on `Ident`, so the warnings are fixed. [ Adjusted wording from upstream version and added build system changes for the kernel - Benno ] Co-developed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Tamir Duberstein <tamird@gmail.com> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Signed-off-by: Benno Lossin <lossin@kernel.org>
2026-01-17rust: pin-init: allow the crate to refer to itself as `pin-init` in doc testsBenno Lossin
The `syn` approach requires use of `::pin_init::...` instead of the `$crate::...` construct available to declarative macros. To be able to use the `pin_init` crate from itself (which includes doc tests), we have to declare it as such. Reviewed-by: Gary Guo <gary@garyguo.net> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Signed-off-by: Benno Lossin <lossin@kernel.org>
2026-01-17rust: pin-init: remove `try_` versions of the initializer macrosBenno Lossin
The `try_[pin_]init!` versions of the initializer macros are superfluous. Instead of forcing the user to always write an error in `try_[pin_]init!` and not allowing one in `[pin_]init!`, combine them into `[pin_]init!` that defaults the error to `core::convert::Infallible`, but also allows to specify a custom one. Projects using pin-init still can provide their own defaulting initializers using the `try_` prefix by using the `#[default_error]` attribute added in a future patch. [ Adjust the definition of the kernel's version of the `try_` initializer macros - Benno] Reviewed-by: Gary Guo <gary@garyguo.net> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Signed-off-by: Benno Lossin <lossin@kernel.org>
2026-01-16Merge tag 'v6.19-rc5' into drm-rust-nextDanilo Krummrich
We need the drm-rust fixes from -rc5 in here for nova-core to build on top of. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-16rust: redefine `bindings::compat_ptr_ioctl` in RustAlice Ryhl
There is currently an inconsistency between C and Rust, which is that when Rust requires cfg(CONFIG_COMPAT) on compat_ioctl when using the compat_ptr_ioctl symbol because '#define compat_ptr_ioctl NULL' does not get translated to anything by bindgen. But it's not *just* a matter of translating the '#define' into Rust when CONFIG_COMPAT=n. This is because when CONFIG_COMPAT=y, the type of compat_ptr_ioctl is a non-nullable function pointer, and to seamlessly use it regardless of the config, we need a nullable function pointer. I think it's important to do something about this; I've seen the mistake of accidentally forgetting '#[cfg(CONFIG_COMPAT)]' when compat_ptr_ioctl is used multiple times now. This explicitly declares 'bindings::compat_ptr_ioctl' as an Option that is always defined but might be None. This matches C, but isn't ideal: it modifies the bindings crate. But I'm not sure if there's a better way to do it. If we just redefine in kernel/, then people may still use the one in bindings::, since that is where you would normally find it. I am open to suggestions. Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260105-redefine-compat_ptr_ioctl-v1-1-25edb3d91acc@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-15Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-6.19-rc6). No conflicts, or adjacent changes. Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-16rust: driver: drop device private data post unbindDanilo Krummrich
Currently, the driver's device private data is allocated and initialized from driver core code called from bus abstractions after the driver's probe() callback returned the corresponding initializer. Similarly, the driver's device private data is dropped within the remove() callback of bus abstractions after calling the remove() callback of the corresponding driver. However, commit 6f61a2637abe ("rust: device: introduce Device::drvdata()") introduced an accessor for the driver's device private data for a Device<Bound>, i.e. a device that is currently bound to a driver. Obviously, this is in conflict with dropping the driver's device private data in remove(), since a device can not be considered to be fully unbound after remove() has finished: We also have to consider registrations guarded by devres - such as IRQ or class device registrations - which are torn down after remove() in devres_release_all(). Thus, it can happen that, for instance, a class device or IRQ callback still calls Device::drvdata(), which then runs concurrently to remove() (which sets dev->driver_data to NULL and drops the driver's device private data), before devres_release_all() started to tear down the corresponding registration. This is because devres guarded registrations can, as expected, access the corresponding Device<Bound> that defines their scope. In C it simply is the driver's responsibility to ensure that its device private data is freed after e.g. an IRQ registration is unregistered. Typically, C drivers achieve this by allocating their device private data with e.g. devm_kzalloc() before doing anything else, i.e. before e.g. registering an IRQ with devm_request_threaded_irq(), relying on the reverse order cleanup of devres. Technically, we could do something similar in Rust. However, the resulting code would be pretty messy: In Rust we have to differentiate between allocated but uninitialized memory and initialized memory in the type system. Thus, we would need to somehow keep track of whether the driver's device private data object has been initialized (i.e. probe() was successful and returned a valid initializer for this memory) and conditionally call the destructor of the corresponding object when it is freed. This is because we'd need to allocate and register the memory of the driver's device private data *before* it is initialized by the initializer returned by the driver's probe() callback, because the driver could already register devres guarded registrations within probe() outside of the driver's device private data initializer. Luckily there is a much simpler solution: Instead of dropping the driver's device private data at the end of remove(), we just drop it after the device has been fully unbound, i.e. after all devres callbacks have been processed. For this, we introduce a new post_unbind() callback private to the driver-core, i.e. the callback is neither exposed to drivers, nor to bus abstractions. This way, the driver-core code can simply continue to conditionally allocate the memory for the driver's device private data when the driver's initializer is returned from probe() - no change needed - and drop it when the driver-core code receives the post_unbind() callback. Closes: https://lore.kernel.org/all/DEZMS6Y4A7XE.XE7EUBT5SJFJ@kernel.org/ Fixes: 6f61a2637abe ("rust: device: introduce Device::drvdata()") Acked-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Igor Korotin <igor.korotin.linux@gmail.com> Link: https://patch.msgid.link/20260107103511.570525-7-dakr@kernel.org [ Remove #ifdef CONFIG_RUST, rename post_unbind() to post_unbind_rust(). - Danilo] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-16rust: driver: add DriverData type to the DriverLayout traitDanilo Krummrich
Add an associated type DriverData to the DriverLayout trait indicating the type of the driver's device private data. Acked-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Igor Korotin <igor.korotin.linux@gmail.com> Link: https://patch.msgid.link/20260107103511.570525-6-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-16rust: driver: add DEVICE_DRIVER_OFFSET to the DriverLayout traitDanilo Krummrich
Add an associated const DEVICE_DRIVER_OFFSET to the DriverLayout trait indicating the offset of the embedded struct device_driver within Self::DriverType, i.e. the specific driver structs, such as struct pci_driver or struct platform_driver. Acked-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Igor Korotin <igor.korotin.linux@gmail.com> Link: https://patch.msgid.link/20260107103511.570525-5-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-16rust: driver: introduce a DriverLayout traitDanilo Krummrich
The DriverLayout trait describes the layout of a specific driver structure, such as `struct pci_driver` or `struct platform_driver`. In a first step, this replaces the associated type RegType of the RegistrationOps with the DriverLayout::DriverType associated type. Acked-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Igor Korotin <igor.korotin.linux@gmail.com> Link: https://patch.msgid.link/20260107103511.570525-4-dakr@kernel.org [ Rename driver::Driver to driver::DriverLayout, as it represents the layout of a driver structure rather than the driver structure itself. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-15rust: xarray: add __rust_helper to helpersAlice Ryhl
This is needed to inline these helpers into Rust code. 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: Tamir Duberstein <tamird@gmail.com> Link: https://lore.kernel.org/r/20260105-define-rust-helper-v2-27-51da5f454a67@google.com Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
2026-01-15rust: configfs: replace `kernel::c_str!` with C-StringsTamir Duberstein
C-String literals were added in Rust 1.77. Replace instances of `kernel::c_str!` with C-String literals where possible. Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <lossin@kernel.org> Signed-off-by: Tamir Duberstein <tamird@gmail.com> Acked-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20251222-cstr-configfs-v1-1-cc1665c51c43@gmail.com Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
2026-01-15rust: auxiliary: add Driver::unbind() callbackDanilo Krummrich
Add missing unbind() callback to auxiliary::Driver, since it will be needed by drivers eventually (e.g. the Nova DRM driver). Acked-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260107103511.570525-3-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
generated by cgit v1.2.3 (git 2.0.4) at 2026-04-12 00:54:31 +0000