summaryrefslogtreecommitdiff
path: root/rust
AgeCommit message (Collapse)Author
2026-05-27rust: device: make Core and CoreInternal lifetime-parameterizedDanilo Krummrich
Device<Core> references in probe callbacks are scoped to the callback, not the full binding duration. Add a lifetime parameter to Core and CoreInternal to accurately represent this in the type system. Suggested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260525202921.124698-12-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-27rust: device: implement Sync for Device<Bound>Danilo Krummrich
Implement Sync for Device<Bound> in addition to Device<Normal>. Device<Bound> uses the same underlying struct device as Device<Normal>; Bound is a zero-sized type-state marker that does not affect thread safety. This is needed for types that hold &'bound Device<Bound>, such as io::mem::IoMem, to be Send. Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Uwe Kleine-König <ukleinek@kernel.org> Tested-by: Dirk Behme <dirk.behme@de.bosch.com> Link: https://patch.msgid.link/20260525202921.124698-11-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-27rust: usb: implement Sync for Device<Bound>Danilo Krummrich
Implement Sync for Device<Bound> in addition to Device<Normal>. Device<Bound> uses the same underlying struct usb_device as Device<Normal>; Bound is a zero-sized type-state marker that does not affect thread safety. This is needed for drivers to store &'bound usb::Device<Bound> in their private data while remaining Send. Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Uwe Kleine-König <ukleinek@kernel.org> Tested-by: Dirk Behme <dirk.behme@de.bosch.com> Link: https://patch.msgid.link/20260525202921.124698-10-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-27rust: auxiliary: implement Sync for Device<Bound>Danilo Krummrich
Implement Sync for Device<Bound> in addition to Device<Normal>. Device<Bound> uses the same underlying struct auxiliary_device as Device<Normal>; Bound is a zero-sized type-state marker that does not affect thread safety. This is needed for drivers to store &'bound auxiliary::Device<Bound> in their private data while remaining Send. Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Uwe Kleine-König <ukleinek@kernel.org> Tested-by: Dirk Behme <dirk.behme@de.bosch.com> Link: https://patch.msgid.link/20260525202921.124698-9-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-27rust: platform: implement Sync for Device<Bound>Danilo Krummrich
Implement Sync for Device<Bound> in addition to Device<Normal>. Device<Bound> uses the same underlying struct platform_device as Device<Normal>; Bound is a zero-sized type-state marker that does not affect thread safety. This is needed for drivers to store &'bound platform::Device<Bound> in their private data while remaining Send. Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Uwe Kleine-König <ukleinek@kernel.org> Tested-by: Dirk Behme <dirk.behme@de.bosch.com> Link: https://patch.msgid.link/20260525202921.124698-8-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-27rust: pci: implement Sync for Device<Bound>Danilo Krummrich
Implement Sync for Device<Bound> in addition to Device<Normal>. Device<Bound> uses the same underlying struct pci_dev as Device<Normal>; Bound is a zero-sized type-state marker that does not affect thread safety. This is needed for drivers to store &'bound pci::Device<Bound> in their private data while remaining Send. Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Uwe Kleine-König <ukleinek@kernel.org> Tested-by: Dirk Behme <dirk.behme@de.bosch.com> Link: https://patch.msgid.link/20260525202921.124698-7-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-27rust: driver core: drop drvdata before devres releaseDanilo Krummrich
Move the post_unbind_rust callback before devres_release_all() in device_unbind_cleanup(). With drvdata() removed, the driver's bus device private data is only accessible by the owning driver itself. It is hence safe to drop the driver's bus device private data before devres actions are released. This reordering is the key enabler for Higher-Ranked Lifetime Types (HRT) in Rust device drivers -- it allows driver structs to hold direct references to devres-managed resources, because the bus device private data (and with it all such references) is guaranteed to be dropped while the underlying devres resources are still alive. Without this change, devres resources would be freed first, leaving the driver's bus device private data with dangling references during its destructor. Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/20260525202921.124698-6-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-27rust: driver: decouple driver private data from driver typeDanilo Krummrich
Add a type Data<'bound> associated type to all bus driver traits, decoupling the driver's bus device private data type from the driver struct itself. In the context of adding a 'bound lifetime, making this an associated type has the advantage that it allows us to avoid a driver trait global lifetime and it avoids the need for ForLt for bus device private data; both of which make the subsequent implementation by buses much simpler. All existing drivers and doc examples set type Data = Self to preserve the current behavior. Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/20260525202921.124698-5-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-27rust: driver: move 'static bounds to constructorGary Guo
With the ForeignOwnable lifetime change, the 'static bound is no longer necessary on the drvdata methods or bus adapter impls. Move it to the Registration constructor instead. Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260525202921.124698-4-dakr@kernel.org Co-developed-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-27rust: alloc: remove `'static` bound on `ForeignOwnable`Gary Guo
The `'static` bound is currently necessary because there's no restriction on the lifetime of the GAT. Add a `Self: 'a` bound to restrict possible lifetimes on `Borrowed` and `BorrowedMut`, and lift the `'static` requirement. Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Gary Guo <gary@garyguo.net> Acked-by: Miguel Ojeda <ojeda@kernel.org> Link: https://patch.msgid.link/20260525202921.124698-3-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-27rust: pci: use 'static lifetime for PCI BAR resource namesDanilo Krummrich
pci_request_region() stores the name pointer directly in struct resource; use &'static CStr to ensure the pointer remains valid even if the Bar is leaked. Cc: stable@vger.kernel.org Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/all/20260522004943.CDA7C1F000E9@smtp.kernel.org/ Fixes: 3c2e31d717ac ("rust: pci: move I/O infrastructure to separate file") Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260525202921.124698-2-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-27rust: module_param: use `pr_warn_once!` for null pointer warningAndreas Hindborg
Replace `pr_warn!` and the accompanying TODO with `pr_warn_once!`, now that the macro is available. [ Note: Adarsh Das independently authored an identical patch on the rust-for-linux list, but it missed the modules tree. ] Suggested-by: Adarsh Das <adarshdas950@gmail.com> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Aaron Tomlin <atomlin@atomlin.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Daniel Gomez <da.gomez@samsung.com> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
2026-05-25opp: rust: mark OPP methods as inlineNicolás Antinori
When building the kernel using llvm-19.1.7-rust-1.85.0-x86_64, the following symbols are generated: $ nm vmlinux | grep ' _R'.*OPP | rustfilt ffffffff81801560 T <kernel::opp::OPP>::freq ffffffff81801540 T <kernel::opp::OPP as kernel::sync::aref::AlwaysRefCounted>::dec_ref ffffffff81801520 T <kernel::opp::OPP as kernel::sync::aref::AlwaysRefCounted>::inc_ref However, these Rust symbols are trivial wrappers around the `dev_pm_opp_get`, `dev_pm_opp_put` and `dev_pm_opp_get_freq_indexed` functions. It doesn't make sense to go through a trivial wrapper for these functions. After applying this patch, the above command will produce no output. Link: https://github.com/Rust-for-Linux/linux/issues/1145 Suggested-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Nicolás Antinori <nico.antinori.7@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2026-05-25Merge tag 'v7.1-rc5' into driver-core-nextDanilo Krummrich
We need the driver-core fixes in here as well to build on top of. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-23rust: miscdevice: remove redundant importsAlvin Sun
Drop `Error`, `Result`, `Pin`, `c_int`, `c_long`, `c_uint`, and `c_ulong` imports already provided by `kernel::prelude`. Signed-off-by: Alvin Sun <alvin.sun@linux.dev> Reviewed-by: Onur Özkan <work@onurozkan.dev> Link: https://patch.msgid.link/20260520-miscdev-use-format-v2-3-64dc48fc1345@linux.dev Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-23rust: miscdevice: use vertical import styleAlvin Sun
Convert `use` imports to vertical layout for better readability and maintainability. Signed-off-by: Alvin Sun <alvin.sun@linux.dev> Reviewed-by: Onur Özkan <work@onurozkan.dev> Link: https://patch.msgid.link/20260520-miscdev-use-format-v2-1-64dc48fc1345@linux.dev Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-20rust: alloc: cleanup doctest imports to "kernel vertical" styleDanilo Krummrich
Change all imports in the alloc module's doctests to use the "kernel vertical" import style [1]. While at it, drop imports that are automatically included in doctests. Link: https://docs.kernel.org/rust/coding-guidelines.html#imports [1] Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260513190946.619810-2-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-20rust: alloc: cleanup imports and use "kernel vertical" styleDanilo Krummrich
Change all imports in the alloc module to use the "kernel vertical" import style [1]. While at it, drop unnecessary imports covered by prelude::*. Link: https://docs.kernel.org/rust/coding-guidelines.html#imports [1] Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260513190946.619810-1-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-20rust: fmt: use vertical import styleKe Sun
Switch single-line `use` imports in fmt.rs to vertical style for better readability and easier maintenance. Signed-off-by: Ke Sun <sunke@kylinos.cn> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260512-clean-fmt-use-v1-1-7ae7858192ac@kylinos.cn Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-05-20rust: doc: disable doc inlining for all prelude itemsGary Guo
Somehow the rustdoc heuristics determined that a large chunk of the items found in prelude should have documentation inlined. This bloats the generated documentation size. Also, for crates that optimize documentation with `cfg(doc)`, as the documentation inlining makes use of the metadata compiled by just rustc, it will not pick up the `cfg(doc)` attributes from the inlined documentation. pin-init for example optimizes tuple/fn rendering using the nightly fake_variadic feature [1], but this is missing from the inlined version [2]. Thus, mark all prelude items as `#[doc(no_inline)]`. Link: https://rust.docs.kernel.org/next/pin_init/trait.Zeroable.html#impl-Zeroable-for-(J,) [1] Link: https://rust.docs.kernel.org/next/kernel/prelude/trait.Zeroable.html#impl-Zeroable-for-(J,) [2] Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260420161636.1790502-1-gary@kernel.org [ Reworded for typo. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-05-18rust: pin-init: internal: project using full slotGary Guo
Instead of projecting using pointer to a field project the full slot. This further shifts the code generation from the initializer site to the struct definition site, which means less code is generated overall. It also makes the safety comment easier to justify, as now the projection is done by the `#[pin_data]` macro which has full visibility of pinnedness of fields. The field alignment could also be checked on the `#[pin_data]` side; however, since `init!()` macro works for other type of structs, we cannot remove the alignment check from `init!`/`pin_init!` side anyway, so I opted to still keep the alignment check in init.rs. Signed-off-by: Gary Guo <gary@garyguo.net>
2026-05-18rust: pin-init: internal: project slots instead of referencesGary Guo
By projecting slots, the `pin_init!` and `init!` code path can be more unified. This also reduces the amount of macro-generated code and shifts them to the shared infrastructure. Signed-off-by: Gary Guo <gary@garyguo.net>
2026-05-18rust: pin-init: internal: make `make_closure` inherent methodsGary Guo
The `InitData` and `PinData` traits do not need to exist, the inference helpers could be inherent methods instead. There is no risk for calling the wrong methods even when user defines it, as inherent methods take priority over trait methods. With this change, it unlocks the possibility of attaching additional bounds to the method per type, which is not possible for trait methods. Signed-off-by: Gary Guo <gary@garyguo.net>
2026-05-18rust: pin-init: internal: use marker on drop guard type for pinned fieldsGary Guo
Instead of projecting the created reference, simply create drop guards with different marker types and have the `let_binding()` method of guards of different marker produce different type instead. This allows more flexible lifetime as this is now controlled by the guard. This will be needed when implementing self-referential fields. Signed-off-by: Gary Guo <gary@garyguo.net>
2026-05-18rust: pin-init: internal: init: handle code blocks earlyGary Guo
`InitializerKind::Code` is a special case where it does not initialize a field, and thus generate no guard and accessors. Handle it earlier and make the rest of the code more linear. Signed-off-by: Gary Guo <gary@garyguo.net>
2026-05-14rust: pin-init: internal: add `PhantomInvariant` and `PhantomInvariantLifetime`Gary Guo
Currently, the `pin_init` library has an `Invariant` type alias, and it is instantiated using `PhantomData`. Generated code from `pin_data` on the other hand cannot access the crate-local type alias, so it generates `PhantomData<fn(T) -> T>` directly. This is all very inconsistent, despite the exact same use case of ensuring invariance. Add `PhantomInvariant` and `PhantomInvariantLifetime` and switch all users that need to express the concept of invariance to use these. They're polyfills of unstable types in the same names in the Rust standard library. Link: https://patch.msgid.link/20260512-pin-init-sync-v1-3-81963130dfbd@garyguo.net Signed-off-by: Gary Guo <gary@garyguo.net>
2026-05-14rust: pin-init: internal: pin_data: add struct to record field infoMohamad Alsadhan
Introduce `FieldInfo` struct to encapsulate field and other relevant data, instead of carrying a pair of `(pinned, field)` in all places. This allows us to add more information to the struct in the future. Signed-off-by: Mohamad Alsadhan <mo@sdhn.cc> Co-developed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260512-pin-init-sync-v1-2-81963130dfbd@garyguo.net Signed-off-by: Gary Guo <gary@garyguo.net>
2026-05-14rust: pin-init: internal: pin_data: use closure for `handle_field`Gary Guo
`handle_field` is currently a function, which precludes it from referencing things in the scope of the parent function. Given that it's only called once, inline its contents to the closure that invokes it instead, so it can directly reference `struct_name` without having to pass in as argument. Link: https://patch.msgid.link/20260512-pin-init-sync-v1-1-81963130dfbd@garyguo.net Signed-off-by: Gary Guo <gary@garyguo.net>
2026-05-13Merge patch series "rust: auxiliary: replace drvdata() with registration data"Danilo Krummrich
Danilo Krummrich <dakr@kernel.org> says: When drvdata() was introduced in commit 6f61a2637abe ("rust: device: introduce Device::drvdata()"), its commit message already noted that a direct accessor to the driver's bus device private data is not commonly required -- bus callbacks provide access through &self, and other entry points (IRQs, workqueues, IOCTLs, etc.) carry their own private data. The sole motivation for drvdata() was inter-driver interaction, e.g. a parent driver deriving its bus device private data from the child driver via the auxiliary bus. However, drvdata() exposes the driver's bus device private data beyond the driver's own scope. This creates ordering constraints -- drvdata may not be set yet when the first caller of drvdata() can appear -- and forces the driver's bus device private data to outlive all registrations that access it; a requirement that causes unnecessary complications. Private data should be private to the entity that issues it; bus device private data belongs to bus callbacks, class device private data to class callbacks, IRQ private data to the IRQ handler, etc. This series replaces drvdata() with a dedicated registration_data pointer on struct auxiliary_device. The parent stores its private data explicitly during registration; the data is private to the registration and lives as long as the Registration object. On teardown, Registration::drop() first triggers auxiliary_device_delete() (unbinding the child), then frees the registration data. Ordering constraints are structural -- the child's lifecycle is scoped to the registration by construction, not by convention. With no remaining use case for drvdata(), drvdata(), match_type_id(), set_type_id() and struct driver_type are removed. This is a prerequisite for [1], which builds on the removal of drvdata() to enable Higher-Ranked Lifetime Types (HRT) for Rust device drivers. [1] https://lore.kernel.org/driver-core/20260427221155.2144848-1-dakr@kernel.org/ Link: https://patch.msgid.link/20260505152400.3905096-1-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-12rust: alloc: fix `Vec::extend_with` SAFETY commentHsiu Che Yu
Fix an incorrect operator in the SAFETY comment, changing `<` to `<=`, since `Vec::reserve` guarantees capacity for exactly n additional elements, so the equal case should be included. Signed-off-by: Hsiu Che Yu <yu.whisper.personal@gmail.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Fixes: 2aac4cd7dae3d ("rust: alloc: implement kernel `Vec` type") Link: https://patch.msgid.link/18fc8eee2f057a6bfbcadae156d1d0b7c40d0077.1777111268.git.yu.whisper.personal@gmail.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-12rust: alloc: add doc test for `Vec::extend_with`Hsiu Che Yu
Add a doc test for `Vec::extend_with` demonstrating basic usage and the zero-length case. Signed-off-by: Hsiu Che Yu <yu.whisper.personal@gmail.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/a02bc604cde78ba505441a5555400e6f575e8a8a.1777111268.git.yu.whisper.personal@gmail.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-12rust: alloc: fix assert in `Vec::reserve` doc testHsiu Che Yu
The assert in the doctest used `>= 10`, which only checks that the capacity can hold `additional` elements, ignoring the existing length of `v`. The correct check should ensure there is room for `additional` *extra* elements on top of what is already in the vector. Fix the assert to use `>= v.len() + 10` so the example accurately reflects the actual semantics of the function. Reported-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> Closes: https://lore.kernel.org/rust-for-linux/CANiq72nkXWhjK9iFRrhGtkMZGsvNE_zVsu4JnxaFRfxWL7RRdg@mail.gmail.com/ Fixes: 2aac4cd7dae3d ("rust: alloc: implement kernel `Vec` type") Signed-off-by: Hsiu Che Yu <yu.whisper.personal@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260427-doctest-kvec-reserve-v1-1-0623abcd9c2e@gmail.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-11rust: driver core: remove drvdata() and driver_typeDanilo Krummrich
When drvdata() was introduced in commit 6f61a2637abe ("rust: device: introduce Device::drvdata()"), its commit message already noted that a direct accessor to the driver's bus device private data is not commonly required -- bus callbacks provide access through &self, and other entry points (IRQs, workqueues, IOCTLs, etc.) carry their own private data. The sole motivation for drvdata() was inter-driver interaction -- an auxiliary driver deriving the parent's bus device private data from the parent device. However, drvdata() exposes the driver's bus device private data beyond the driver's own scope. This creates ordering constraints; for instance drvdata may not be set yet when the first caller of drvdata() can appear. It also forces the driver's bus device private data to outlive all registrations that access it, which causes unnecessary complications. Private data should be private to the entity that issues it, i.e. bus device private data belongs to bus callbacks, class device private data to class callbacks, IRQ private data to the IRQ handler, etc. With registration-private data now available through the auxiliary bus, there is no remaining user of drvdata(), thus remove it. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260505152400.3905096-4-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-11rust: auxiliary: add registration data to auxiliary devicesDanilo Krummrich
Add a registration_data pointer to struct auxiliary_device, allowing the registering (parent) driver to attach private data to the device at registration time and retrieve it later when called back by the auxiliary (child) driver. By tying the data to the device's registration, Rust drivers can bind the lifetime of device resources to it, since the auxiliary bus guarantees that the parent driver remains bound while the auxiliary device is bound. On the Rust side, Registration<T> takes ownership of the data via ForeignOwnable. A TypeId is stored alongside the data for runtime type checking, making Device::registration_data<T>() a safe method. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260505152400.3905096-3-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-11rust: alloc: add Box::zeroed()Danilo Krummrich
Add Box::zeroed() for T: Zeroable types. This allocates with __GFP_ZERO directly, letting the underlying allocator deal with zeroing out the memory compared to Box::new(T::zeroed(), flags). Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260505152400.3905096-2-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-10rust: pin-init: examples: fix `useless_borrows_in_formatting` clippy warningGary Guo
Clippy 1.97 introduces new `useless_borrows_in_formatting` warning which fires on the examples as we have `&*expr` where the format macro takes reference already. Remove the extra borrow. Link: https://patch.msgid.link/20260505115138.2466966-1-gary@kernel.org Signed-off-by: Gary Guo <gary@garyguo.net>
2026-05-10rust: pin-init: internal: remove `collect_tuple` polyfill after MSRV bumpGary Guo
Tuples implement `FromIterator` since Rust 1.79. Remove the `collect_tuple` polyfill now the MSRV is above 1.79. To avoid over-identing the closure, I move the `Field` destructure from the closure parameter to a let binding. This keeps the diff small. Link: https://patch.msgid.link/20260501134445.3809731-1-gary@garyguo.net Signed-off-by: Gary Guo <gary@garyguo.net>
2026-05-10rust: pin-init: internal: turn `PhantomPinned` error into warningsGary Guo
The `PhantomPinned` detection is just a lint, and is emitted as an error because there is no `compile_warning!()` macro, and `proc-macro-diagnostics` is not stable. Use of `#[deprecated = ""]` attribute to approximate custom proc-macro warnings. A new line is added before message for visual clarity. An example warning with this trick looks like this: warning: use of deprecated function `_::warn`: The field `pin` of type `PhantomPinned` only has an effect if it has the `#[pin]` attribute --> test.rs:9:5 | 9 | pin: marker::PhantomPinned, | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Suggested-by: Benno Lossin <lossin@kernel.org> Link: https://github.com/Rust-for-Linux/pin-init/issues/51 Link: https://patch.msgid.link/20260428-pin-init-sync-v1-10-07f9bd3859fb@garyguo.net Signed-off-by: Gary Guo <gary@garyguo.net>
2026-05-10rust: pin-init: cleanup workaround for old Rust compilerGary Guo
The workaround mentions it's for Rust versions before 1.81. The minimum is now 1.82, thus clean up. Link: https://patch.msgid.link/20260428-pin-init-sync-v1-9-07f9bd3859fb@garyguo.net Signed-off-by: Gary Guo <gary@garyguo.net>
2026-05-10rust: pin-init: fix badge URL in READMEGary Guo
The old CI workflow has been deleted ~1 year ago. Fix the URL to point to the correct one. Link: https://patch.msgid.link/20260428-pin-init-sync-v1-8-07f9bd3859fb@garyguo.net Signed-off-by: Gary Guo <gary@garyguo.net>
2026-05-10rust: pin-init: internal: adjust license identifier of `zeroable.rs`Benno Lossin
The pin-init crate has been licensed under `Apache-2.0 OR MIT` since the beginning. I introduced in commit 071cedc84e90 ("rust: add derive macro for `Zeroable`") `zeroable.rs` with incompatible GPL-2.0 SPDX identifier. The file has not been modified by other authors, so relicense it under the above license. Signed-off-by: Benno Lossin <lossin@kernel.org> [ Reworded commit message - Gary ] Link: https://patch.msgid.link/20260428-pin-init-sync-v1-7-07f9bd3859fb@garyguo.net Signed-off-by: Gary Guo <gary@garyguo.net>
2026-05-10rust: pin-init: internal: remove redundant `#[pin]` filteringGary Guo
The `generate_projections` and `generate_the_pin_data` function already receive filtered field lists, they do not need to filter out `#[pin]` again. Reviewed-by: Benno Lossin <lossin@kernel.org> Link: https://patch.msgid.link/20260428-pin-init-sync-v1-6-07f9bd3859fb@garyguo.net Signed-off-by: Gary Guo <gary@garyguo.net>
2026-05-10rust: pin-init: internal: add missing where clause to projection typesMohamad Alsadhan
`#[pin_data]` failed to propagate the struct's `where` clause to the generated projection struct. As a result, bounds written in a `where` clause could be dropped during expansion, causing type errors when fields depended on those bounds. Fix this by adding the missing `where` clause to the generated projection struct. Reported-by: Andreas Hindborg <a.hindborg@kernel.org> Closes: https://rust-for-linux.zulipchat.com/#narrow/channel/561532-pin-init/topic/generic.20bounds.20and.20.60.23.5Bpin_data.5D.60/with/578381591 Signed-off-by: Mohamad Alsadhan <mo@sdhn.cc> Reviewed-by: Gary Guo <gary@garyguo.net> [ Reworded commit message - Gary ] Link: https://patch.msgid.link/20260428-pin-init-sync-v1-5-07f9bd3859fb@garyguo.net Signed-off-by: Gary Guo <gary@garyguo.net>
2026-05-10rust: pin-init: extend `impl_zeroable_option` macro to handle genericsMohamad Alsadhan
Improve impl_zeroable_option macro to handle generic impls for types like `&T`, `&mut T`, `NonNull<T>`, and others (for which `Option<T>` is guaranteed to be zeroable) with similar approach to `impl_zeroable`. Also, update old declarations to use generics e.g. `NonZeroU8` to `NonZero<u8>`. Signed-off-by: Mohamad Alsadhan <mo@sdhn.cc> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260428-pin-init-sync-v1-4-07f9bd3859fb@garyguo.net Signed-off-by: Gary Guo <gary@garyguo.net>
2026-05-10rust: pin-init: cleanup `Zeroable` and `ZeroableOptions`Mohamad Alsadhan
Place definitions and implementations (incl. macro invocations) of the `Zeroable` trait first in the relevant section of `src/lib.rs`, followed by the ZeroableOption trait and its implementations. Rename `impl_non_zero_int_zeroable_option` to `impl_zeroable_option` for consistency. This commit should not introduce any functional changes. Signed-off-by: Mohamad Alsadhan <mo@sdhn.cc> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260428-pin-init-sync-v1-3-07f9bd3859fb@garyguo.net Signed-off-by: Gary Guo <gary@garyguo.net>
2026-05-10rust: pin-init: bump minimum Rust version to 1.82Gary Guo
Following the kernel minimum version bump in commit f32fb9c58a5b ("rust: bump Rust minimum supported version to 1.85.0 (Debian Trixie)"), bump pin-init's minimum Rust version to 1.82. This removes the `lint_reasons` feature which is stabilized in 1.81 and the `raw_ref_ops` and `new_uninit` features which are stabilized in 1.82. Given we do not use any features that are stabilized in 1.82..=1.85 range, and pin-init crate is useful for other projects which may have their own MSRV requirements, the minimum version is not straightly bumped to 1.85. Reviewed-by: Benno Lossin <lossin@kernel.org> Link: https://patch.msgid.link/20260428-pin-init-sync-v1-2-07f9bd3859fb@garyguo.net Signed-off-by: Gary Guo <gary@garyguo.net>
2026-05-10rust: pin-init: examples: mark as `#[inline]` all `From::from()`s for `Error`Alistair Francis
There was a recent request in kernel [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 as `#[inline]`. While in pin-init crate the relevant code is just examples, it nevertheless does not hurt to use good practice for them. 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> Reviewed-by: Gary Guo <gary@garyguo.net> [ Reworded commit message - Gary ] Link: https://patch.msgid.link/20260428-pin-init-sync-v1-1-07f9bd3859fb@garyguo.net Signed-off-by: Gary Guo <gary@garyguo.net>
2026-05-09Merge tag 'rust-fixes-7.1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux Pull Rust fixes from Miguel Ojeda: "Toolchain and infrastructure: - Add 'bindgen' target to make UML 32-bit builds work with GCC - Disable two Clippy warnings ('collapsible_{if,match}') 'pin-init' crate: - Fix unsoundness issue that created &'static references" * tag 'rust-fixes-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux: rust: allow `clippy::collapsible_if` globally rust: allow `clippy::collapsible_match` globally rust: pin-init: fix incorrect accessor reference lifetime rust: pin-init: internal: move alignment check to `make_field_check` rust: arch: um: Fix building 32-bit UML with GCC
2026-05-05drm/gpuvm: rust: add RUST_DRM_GPUVM option to KconfigAlice Ryhl
Since Rust uses GPUVM via the kernel crate, which is built-in, the GPUVM module must also be built-in to use GPUVM from Rust. Adjust the Kconfig settings accordingly. Suggested-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260427-gpuvm-config-v1-1-8ece03771f8a@google.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-05rust: gpuvm: add GpuVmCore::sm_map()Alice Ryhl
Finally also add the operation for creating new mappings. Mapping operations need extra data in the context since they involve a vm_bo coming from the outside. Co-developed-by: Asahi Lina <lina+kernel@asahilina.net> Signed-off-by: Asahi Lina <lina+kernel@asahilina.net> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260409-gpuvm-rust-v6-5-b16e6ada7261@google.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>