aboutsummaryrefslogtreecommitdiffstats
path: root/rust (follow)
AgeCommit message (Collapse)AuthorFilesLines
2025-09-17Merge tag 'drm-rust-next-2025-09-16' of ↵Dave Airlie23-109/+1337
https://gitlab.freedesktop.org/drm/rust/kernel into drm-next DRM Rust changes for v6.18 Alloc - Add BorrowedPage type and AsPageIter trait - Implement Vmalloc::to_page() and VmallocPageIter - Implement AsPageIter for VBox and VVec DMA & Scatterlist - Add dma::DataDirection and type alias for dma_addr_t - Abstraction for struct scatterlist and struct sg_table DRM - In the DRM GEM module, simplify overall use of generics, add DriverFile type alias and drop Object::SIZE. Nova (Core) - Various register!() macro improvements (paving the way for lifting it to common driver infrastructure) - Minor VBios fixes and refactoring - Minor firmware request refactoring - Advance firmware boot stages; process Booter and patch its signature, process GSP and GSP bootloader - Switch development fimrware version to r570.144 - Add basic firmware bindings for r570.144 - Move GSP boot code to its own module - Clean up and take advantage of pin-init features to store most of the driver's private data within a single allocation - Update ARef import from sync::aref - Add website to MAINTAINERS entry Nova (DRM) - Update ARef import from sync::aref - Add website to MAINTAINERS entry Pin-Init - Merge pin-init PR from Benno - `#[pin_data]` now generates a `*Projection` struct similar to the `pin-project` crate. - Add initializer code blocks to `[try_][pin_]init!` macros: make initializer macros accept any number of `_: {/* arbitrary code */},` & make them run the code at that point. - Make the `[try_][pin_]init!` macros expose initialized fields via a `let` binding as `&mut T` or `Pin<&mut T>` for later fields. Rust - Various methods for AsBytes and FromBytes traits Tyr - Initial Rust driver skeleton for ARM Mali GPUs. - It can power up the GPU, query for GPU metatdata through MMIO and provide the metadata to userspace via DRM device IOCTL (struct drm_panthor_dev_query). Signed-off-by: Dave Airlie <airlied@redhat.com> From: "Danilo Krummrich" <dakr@kernel.org> Link: https://lore.kernel.org/r/DCUC4SY6SRBD.1ZLHAIQZOC6KG@kernel.org
2025-09-15Merge tag 'v6.17-rc6' into drm-nextDave Airlie9-60/+356
This is a backmerge of Linux 6.17-rc6, needed for msm, also requested by misc. Signed-off-by: Dave Airlie <airlied@redhat.com>
2025-09-13Merge tag 'driver-core-6.17-rc6' of ↵Linus Torvalds1-2/+3
git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core Pull driver core fixes from Danilo Krummrich: - Fix UAF in cgroup pressure polling by using kernfs_get_active_of() to prevent operations on released file descriptors - Fix unresolved intra-doc link in the documentation of struct Device when CONFIG_DRM != y - Update the DMA Rust MAINTAINERS entry * tag 'driver-core-6.17-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core: MAINTAINERS: Update the DMA Rust entry kernfs: Fix UAF in polling when open file is released rust: device: fix unresolved link to drm::Device
2025-09-12Merge tag 'pin-init-v6.18' of https://github.com/Rust-for-Linux/linux into ↵Danilo Krummrich6-48/+226
drm-rust-next pin-init changes for v6.18 Changed: - `#[pin_data]` now generates a `*Projection` struct similar to the `pin-project` crate. - Add initializer code blocks to `[try_][pin_]init!` macros: make initializer macros accept any number of `_: {/* arbitrary code */},` & make them run the code at that point. - Make the `[try_][pin_]init!` macros expose initialized fields via a `let` binding as `&mut T` or `Pin<&mut T>` for later fields. Upstream dev news: - Released v0.0.10 before the changes included in this tag. - Inform users of the impending rename from `pinned-init` to `pin-init` (in the kernel the rename already happened). - More CI improvements. Signed-off-by: Danilo Krummrich <dakr@kernel.org> From: Benno Lossin <lossin@kernel.org> Link: https://lore.kernel.org/r/20250912174148.373530-1-lossin@kernel.org
2025-09-11rust: pin-init: add references to previously initialized fieldsBenno Lossin2-38/+117
After initializing a field in an initializer macro, create a variable holding a reference that points at that field. The type is either `Pin<&mut T>` or `&mut T` depending on the field's structural pinning kind. [ Applied fixes to devres and rust_driver_pci sample - Benno] Reviewed-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Benno Lossin <lossin@kernel.org>
2025-09-11rust: pin-init: add code blocks to `[try_][pin_]init!` macrosBenno Lossin2-0/+31
Allow writing `_: { /* any number of statements */ }` in initializers to run arbitrary code during initialization. try_init!(MyStruct { _: { if check_something() { return Err(MyError); } }, foo: Foo::new(val), _: { println!("successfully initialized `MyStruct`"); }, }) Tested-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Tested-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Benno Lossin <lossin@kernel.org>
2025-09-11rust: pin-init: add pin projections to `#[pin_data]`Benno Lossin2-8/+62
Make the `#[pin_data]` macro generate a `*Projection` struct that holds either `Pin<&mut Field>` or `&mut Field` for every field of the original struct. Which version is chosen depends on weather there is a `#[pin]` or not respectively. Access to this projected version is enabled through generating `fn project(self: Pin<&mut Self>) -> SelfProjection<'_>`. [ Adapt workqueue to use the new projection instead of its own, custom one - Benno ] Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Benno Lossin <lossin@kernel.org>
2025-09-11rust: pin-init: rename `project` -> `project_this` in doctestBenno Lossin1-1/+1
The next commit makes the `#[pin_data]` attribute generate a `project` function that would collide with any existing ones. Signed-off-by: Benno Lossin <lossin@kernel.org>
2025-09-11rust: pin-init: README: add information banner on the rename to `pin-init`Benno Lossin1-0/+12
Signed-off-by: Benno Lossin <lossin@kernel.org>
2025-09-11rust: pin-init: examples: error: use `Error` in `fn main()`Benno Lossin1-1/+3
When running this example with no cargo features enabled, the compiler warns on 1.89: error: struct `Error` is never constructed --> examples/error.rs:11:12 | 11 | pub struct Error; | ^^^^^ | = note: `-D dead-code` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(dead_code)]` Thus use the error in the main function to avoid this warning. Signed-off-by: Benno Lossin <lossin@kernel.org>
2025-09-11rust: drm: Introduce the Tyr driver for Arm Mali GPUsDaniel Almeida1-0/+1
Add a Rust driver for ARM Mali CSF-based GPUs. It is a port of Panthor and therefore exposes Panthor's uAPI and name to userspace, and the product of a joint effort between Collabora, Arm and Google engineers. The aim is to incrementally develop Tyr with the abstractions that are currently available until it is consider to be in parity with Panthor feature-wise. The development of Tyr itself started in January, after a few failed attempts of converting Panthor piecewise through a mix of Rust and C code. There is a downstream branch that's much further ahead in terms of capabilities than this initial patch. The downstream code is capable of booting the MCU, doing sync VM_BINDS through the work-in-progress GPUVM abstraction and also doing (trivial) submits through Asahi's drm_scheduler and dma_fence abstractions. So basically, most of what one would expect a modern GPU driver to do, except for power management and some other very important adjacent pieces. It is not at the point where submits can correctly deal with dependencies, or at the point where it can rotate access to the GPU hardware fairly through a software scheduler, but that is simply a matter of writing more code. This first patch, however, only implements a subset of the current features available downstream, as the rest is not implementable without pulling in even more abstractions. In particular, a lot of things depend on properly mapping memory on a given VA range, which itself depends on the GPUVM abstraction that is currently work-in-progress. For this reason, we still cannot boot the MCU and thus, cannot do much for the moment. This constitutes a change in the overall strategy that we have been using to develop Tyr so far. By submitting small parts of the driver upstream iteratively, we aim to: a) evolve together with Nova and rvkms, hopefully reducing regressions due to upstream changes (that may break us because we were not there, in the first place) b) prove any work-in-progress abstractions by having them run on a real driver and hardware and, c) provide a reason to work on and review said abstractions by providing a user, which would be tyr itself. Despite its limited feature-set, we offer IGT tests. It is only tested on the rk3588, so any other SoC is probably not going to work at all for now. The skeleton is basically taken from Nova and also rust_platform_driver.rs. Lastly, the name "Tyr" is inspired by Norse mythology, reflecting ARM's tradition of naming their GPUs after Nordic mythological figures and places. Co-developed-by: Beata Michalska <beata.michalska@arm.com> Signed-off-by: Beata Michalska <beata.michalska@arm.com> Co-developed-by: Carsten Haitzler <carsten.haitzler@foss.arm.com> Signed-off-by: Carsten Haitzler <carsten.haitzler@foss.arm.com> Co-developed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://www.collabora.com/news-and-blog/news-and-events/introducing-tyr-a-new-rust-drm-driver.html Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com> Acked-by: Boris Brezillon <boris.brezillon@collabora.com> [aliceryhl: minor Kconfig update on apply] [aliceryhl: s/drm::device::/drm::/] Link: https://lore.kernel.org/r/20250910-tyr-v3-1-dba3bc2ae623@collabora.com Co-developed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2025-09-10Merge drm-misc-next-2025-08-21 into drm-rust-nextDanilo Krummrich5-10/+25
We need the DRM Rust changes that went into drm-misc before the existence of the drm-rust tree in here as well. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-09-08rust: drm: gem: Drop Object::SIZELyude Paul1-4/+1
Drive-by fix, it doesn't seem like anything actually uses this constant anymore. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250908185239.135849-4-lyude@redhat.com Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2025-09-08rust: drm: gem: Add DriverFile type aliasLyude Paul1-11/+12
Just to reduce the clutter with the File<…> types in gem.rs. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250908185239.135849-3-lyude@redhat.com Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2025-09-08rust: drm: gem: Simplify use of genericsLyude Paul2-43/+37
Now that my rust skills have been honed, I noticed that there's a lot of generics in our gem bindings that don't actually need to be here. Currently the hierarchy of traits in our gem bindings looks like this: * Drivers implement: * BaseDriverObject<T: DriverObject> (has the callbacks) * DriverObject (has the drm::Driver type) * Crate implements: * IntoGEMObject for Object<T> where T: DriverObject Handles conversion to/from raw object pointers * BaseObject for T where T: IntoGEMObject Provides methods common to all gem interfaces Also of note, this leaves us with two different drm::Driver associated types: * DriverObject::Driver * IntoGEMObject::Driver I'm not entirely sure of the original intent here unfortunately (if anyone is, please let me know!), but my guess is that the idea would be that some objects can implement IntoGEMObject using a different ::Driver than DriverObject - presumably to enable the usage of gem objects from different drivers. A reasonable usecase of course. However - if I'm not mistaken, I don't think that this is actually how things would go in practice. Driver implementations are of course implemented by their associated drivers, and generally drivers are not linked to each-other when building the kernel. Which is to say that even in a situation where we would theoretically deal with gem objects from another driver, we still wouldn't have access to its drm::driver::Driver implementation. It's more likely we would simply want a variant of gem objects in such a situation that have no association with a drm::driver::Driver type. Taking that into consideration, we can assume the following: * Anything that implements BaseDriverObject will implement DriverObject In other words, all BaseDriverObjects indirectly have an associated ::Driver type - so the two traits can be combined into one with no generics. * Not everything that implements IntoGEMObject will have an associated ::Driver, and that's OK. And with this, we now can do quite a bit of cleanup with the use of generics here. As such, this commit: * Removes the generics on BaseDriverObject * Moves DriverObject::Driver into BaseDriverObject * Removes DriverObject * Removes IntoGEMObject::Driver * Add AllocImpl::Driver, which we can use as a binding to figure out the correct File type for BaseObject Leaving us with a simpler trait hierarchy that now looks like this: * Drivers implement: BaseDriverObject * Crate implements: * IntoGEMObject for Object<T> where T: DriverObject * BaseObject for T where T: IntoGEMObject Which makes the code a lot easier to understand and build on :). Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250908185239.135849-2-lyude@redhat.com Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2025-09-06Merge tag 'rust-fixes-6.17-2' of ↵Linus Torvalds1-5/+10
git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux Pull rust fixes from Miguel Ojeda: - Two changes to prepare for the future Rust 1.91.0 release (expected 2025-10-30, currently in nightly): a target specification format change and a renamed, soon-to-be-stabilized 'core' function. * tag 'rust-fixes-6.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux: rust: support Rust >= 1.91.0 target spec rust: use the new name Location::file_as_c_str() in Rust >= 1.91.0
2025-09-04rust: scatterlist: Add abstraction for sg_tableDanilo Krummrich4-0/+517
Add a safe Rust abstraction for the kernel's scatter-gather list facilities (`struct scatterlist` and `struct sg_table`). This commit introduces `SGTable<T>`, a wrapper that uses a generic parameter to provide compile-time guarantees about ownership and lifetime. The abstraction provides two primary states: - `SGTable<Owned<P>>`: Represents a table whose resources are fully managed by Rust. It takes ownership of a page provider `P`, allocates the underlying `struct sg_table`, maps it for DMA, and handles all cleanup automatically upon drop. The DMA mapping's lifetime is tied to the associated device using `Devres`, ensuring it is correctly unmapped before the device is unbound. - `SGTable<Borrowed>` (or just `SGTable`): A zero-cost representation of an externally managed `struct sg_table`. It is created from a raw pointer using `SGTable::from_raw()` and provides a lifetime-bound reference (`&'a SGTable`) for operations like iteration. The API exposes a safe iterator that yields `&SGEntry` references, allowing drivers to easily access the DMA address and length of each segment in the list. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Co-developed-by: Abdiel Janulgue <abdiel.janulgue@gmail.com> Signed-off-by: Abdiel Janulgue <abdiel.janulgue@gmail.com> Link: https://lore.kernel.org/r/20250828133323.53311-4-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-09-04rust: dma: add type alias for bindings::dma_addr_tDanilo Krummrich1-4/+14
Add a type alias for bindings::dma_addr_t (DmaAddress), such that we do not have to access bindings directly. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Suggested-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250828133323.53311-3-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-09-04rust: dma: implement DataDirectionDanilo Krummrich2-0/+69
Add the `DataDirection` struct, a newtype wrapper around the C `enum dma_data_direction`. This provides a type-safe Rust interface for specifying the direction of DMA transfers. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250828133323.53311-2-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-09-04rust: alloc: kvec: implement AsPageIter for VVecDanilo Krummrich1-1/+39
Implement AsPageIter for VVec; this allows to iterate and borrow the backing pages of a VVec. This, for instance, is useful in combination with VVec backing a scatterlist. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Link: https://lore.kernel.org/r/20250820145434.94745-8-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-09-04rust: alloc: layout: implement ArrayLayout::size()Danilo Krummrich1-0/+5
Provide a convenience method for ArrayLayout to calculate the size of the ArrayLayout in bytes. Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Abdiel Janulgue <abdiel.janulgue@gmail.com> Link: https://lore.kernel.org/r/20250820145434.94745-7-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-09-04rust: alloc: kbox: implement AsPageIter for VBoxDanilo Krummrich1-1/+39
Implement AsPageIter for VBox; this allows to iterate and borrow the backing pages of a VBox. This, for instance, is useful in combination with VBox backing a scatterlist. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250820145434.94745-6-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-09-04rust: page: define trait AsPageIterDanilo Krummrich1-0/+12
The AsPageIter trait provides a common interface for types that provide a page iterator, such as VmallocPageIter. Subsequent patches will leverage this to let VBox and VVec provide a VmallocPageIter though this trait. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Link: https://lore.kernel.org/r/20250820145434.94745-5-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-09-04rust: alloc: implement VmallocPageIterDanilo Krummrich3-0/+134
Introduce the VmallocPageIter type; an instance of VmallocPageIter may be exposed by owners of vmalloc allocations to provide borrowed access to its backing pages. For instance, this is useful to access and borrow the backing pages of allocation primitives, such as Box and Vec, backing a scatterlist. Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Suggested-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250820145434.94745-4-dakr@kernel.org [ Drop VmallocPageIter::base_address(), move to allocator/iter.rs and stub VmallocPageIter for allocator_test.rs. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-09-04rust: alloc: vmalloc: implement Vmalloc::to_page()Danilo Krummrich1-0/+49
Implement an abstraction of vmalloc_to_page() for subsequent use in the AsPageIter implementation of VBox and VVec. Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Link: https://lore.kernel.org/r/20250820145434.94745-3-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-09-04rust: page: implement BorrowedPageDanilo Krummrich2-1/+75
Currently, a Page always owns the underlying struct page. However, sometimes a struct page may be owned by some other entity, e.g. a vmalloc allocation. Hence, introduce BorrowedPage to support such cases, until the Ownable solution [1] lands. This is required by the scatterlist abstractions. Acked-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Link: https://lore.kernel.org/rust-for-linux/ZnCzLIly3DRK2eab@boqun-archlinux/ [1] Link: https://lore.kernel.org/r/20250820145434.94745-2-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-09-02rust: device: fix unresolved link to drm::DeviceDanilo Krummrich1-2/+3
drm::Device is only available when CONFIG_DRM=y, which we have to consider for intra-doc links, otherwise the rustdoc make target produces the following warning. >> warning: unresolved link to `kernel::drm::Device` --> rust/kernel/device.rs:154:22 | 154 | /// [`drm::Device`]: kernel::drm::Device | ^^^^^^^^^^^^^^^^^^^ no item named `drm` in module `kernel` | = note: `#[warn(rustdoc::broken_intra_doc_links)]` on by default Fix this by making the intra-doc link conditional on CONFIG_DRM being enabled. Fixes: d6e26c1ae4a6 ("device: rust: expand documentation for Device") Suggested-by: Alice Ryhl <aliceryhl@google.com> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202508261644.9LclwUgt-lkp@intel.com/ Reviewed-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250829195745.31174-1-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-08-31rust: use the new name Location::file_as_c_str() in Rust >= 1.91.0Alice Ryhl1-5/+10
As part of the stabilization of Location::file_with_nul(), it was brought up that the with_nul() suffix usually means something else in Rust APIs, so the API is being renamed prior to stabilization [1]. Thus, use the new name on new rustc versions. Link: https://www.github.com/rust-lang/rust/pull/145928 [1] Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Link: https://lore.kernel.org/r/20250827-file_as_c_str-v1-1-d3f5a3916a9c@google.com [ Kept `cfg` separation. Reworded slightly. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-08-28rust: transmute: add `from_bytes_copy` method to `FromBytes` traitAlexandre Courbot1-0/+18
`FromBytes::from_bytes` comes with a few practical limitations: - It requires the bytes slice to have the same alignment as the returned type, which might not be guaranteed in the case of a byte stream, - It returns a reference, requiring the returned type to implement `Clone` if one wants to keep the value for longer than the lifetime of the slice. To overcome these when needed, add a `from_bytes_copy` with a default implementation in the trait. `from_bytes_copy` returns an owned value that is populated using an unaligned read, removing the lifetime constraint and making it usable even on non-aligned byte slices. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Miguel Ojeda <ojeda@kernel.org> Reviewed-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Benno Lossin <lossin@kernel.org> Link: https://lore.kernel.org/r/20250826-nova_firmware-v2-1-93566252fe3a@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-08-28rust: transmute: Add methods for FromBytes traitChristian S. Lima2-1/+69
The two methods added take a slice of bytes and return those bytes in a specific type. These methods are useful when we need to transform the stream of bytes into specific type. Since the `is_aligned` method for pointer types has been stabilized in `1.79` version and is being used in this patch, I'm enabling the feature. In this case, using this method is useful to check the alignment and avoid a giant boilerplate, such as `(foo.as_ptr() as usize) % core::mem::align_of::<T>() == 0`. Also add `#[allow(clippy::incompatible_msrv)]` where needed until the MSRV is updated to `1.79`. Suggested-by: Benno Lossin <benno.lossin@proton.me> Link: https://github.com/Rust-for-Linux/linux/issues/1119 Reviewed-by: Alice Ryhl <aliceryhl@google.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Christian S. Lima <christiansantoslima21@gmail.com> Link: https://lore.kernel.org/r/20250824213134.27079-1-christiansantoslima21@gmail.com Acked-by: Miguel Ojeda <ojeda@kernel.org> [acourbot@nvidia.com: minor rewording of commit messages and doccomments] [acourbot@nvidia.com: revert slice implementation removal] [acourbot@nvidia.com: move incompatible_msrv clippy allow closer to site of need] [acourbot@nvidia.com: call the doctest method] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-08-27rust: mm: mark VmaNew as transparentBaptiste Lepers1-0/+1
Unsafe code in VmaNew's methods assumes that the type has the same layout as the inner `bindings::vm_area_struct`. This is not guaranteed by the default struct representation in Rust, but requires specifying the `transparent` representation. Link: https://lkml.kernel.org/r/20250812132712.61007-1-baptiste.lepers@gmail.com Fixes: dcb81aeab406 ("mm: rust: add VmaNew for f_ops->mmap()") Signed-off-by: Baptiste Lepers <baptiste.lepers@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Cc: Alex Gaynor <alex.gaynor@gmail.com> Cc: Andreas Hindborg <a.hindborg@kernel.org> Cc: Björn Roy Baron <bjorn3_gh@protonmail.com> Cc: Boqun Feng <boqun.feng@gmail.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Gary Guo <gary@garyguo.net> Cc: Jann Horn <jannh@google.com> Cc: Liam Howlett <liam.howlett@oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Cc: Miguel Ojeda <ojeda@kernel.org> Cc: Trevor Gross <tmgross@umich.edu> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-08-23Merge tag 'driver-core-6.17-rc3' of ↵Linus Torvalds4-36/+290
git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core Pull driver core fixes from Danilo Krummrich: - Fix swapped handling of lru_gen and lru_gen_full debugfs files in vmscan - Fix debugfs mount options (uid, gid, mode) being silently ignored - Fix leak of devres action in the unwind path of Devres::new() - Documentation: - Expand and fix documentation of (outdated) Device, DeviceContext and generic driver infrastructure - Fix C header link of faux device abstractions - Clarify expected interaction with the security team - Smooth text flow in the security bug reporting process documentation * tag 'driver-core-6.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core: Documentation: smooth the text flow in the security bug reporting process Documentation: clarify the expected collaboration with security bugs reporters debugfs: fix mount options not being applied rust: devres: fix leaking call to devm_add_action() rust: faux: fix C header link driver: rust: expand documentation for driver infrastructure device: rust: expand documentation for Device device: rust: expand documentation for DeviceContext mm/vmscan: fix inverted polarity in lru_gen_seq_show()
2025-08-22rust: transmute: add `as_bytes_mut` method to `AsBytes` traitAlexandre Courbot1-0/+15
Types that implement both `AsBytes` and `FromBytes` can be safely modified as a slice of bytes. Add a `as_bytes_mut` method for that purpose. [acourbot@nvidia.com: use fully qualified `core::mem::size_of_val` to build with Rust 1.78.] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Benno Lossin <lossin@kernel.org> Acked-by: Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/r/20250801-as_bytes-v5-2-975f87d5dc85@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-08-22rust: transmute: add `as_bytes` method for `AsBytes` traitAlexandre Courbot1-1/+11
Every type that implements `AsBytes` should be able to provide its byte representation. Introduce the `as_bytes` method that returns the implementer as a stream of bytes, and provide a default implementation that should be suitable for any type that satisfies `AsBytes`'s safety requirements. [acourbot@nvidia.com: use fully qualified `core::mem::size_of_val` to build with Rust 1.78.] Reviewed-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Benno Lossin <lossin@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/r/20250801-as_bytes-v5-1-975f87d5dc85@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-08-20Merge drm/drm-fixes into drm-misc-fixesMaxime Ripard1-3/+13
Update drm-misc-fixes to -rc2. Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-08-20Merge drm/drm-next into drm-misc-nextMaxime Ripard1-3/+13
Bring v6.17-rc2 in to unstuck for-linux-next. Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-08-20rust: drm: update ARef and AlwaysRefCounted imports from sync::arefShankari Anand3-3/+5
Update call sites in drm 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> Reviewed-by: Benno Lossin <lossin@kernel.org> Reviewed-by: Elle Rhumsaa <elle@weathered-steel.dev> Link: https://lore.kernel.org/r/20250815161706.1324860-1-shankari.ak0208@gmail.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-08-19Merge tag 'drm-misc-next-2025-08-14' of ↵Dave Airlie1-4/+7
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v6.18: UAPI Changes: - Add DRM_IOCTL_GEM_CHANGE_HANDLE for reassigning GEM handles - Document DRM_MODE_PAGE_FLIP_EVENT Cross-subsystem Changes: fbcon: - Add missing declarations in fbcon.h Core Changes: bridge: - Fix ref counting panel: - Replace and remove mipi_dsi_generic_write_{seq/_chatty}() sched: - Fixes Rust: - Drop Opaque<> from ioctl arguments Driver Changes: amdxdma: - Support buffers allocated by user space - Streamline PM interfaces - Fixes bridge: - cdns-dsi: Various improvements to mode setting - Support Solomon SSD2825 plus DT bindings - Support Waveshare DSI2DPI plus DT bindings gud: - Fixes ivpu: - Fixes nouveau: - Use GSP firmware by default - Fixes panel: - panel-edp: Support mt8189 Chromebooks; Support BOE NV140WUM-N64; Support SHP LQ134Z1; Fixes - panel-simple: Support Olimex LCD-OLinuXino-5CTS plus DT bindings - Support Samsung AMS561RA01 - Support Hydis HV101HD1 plus DT bindings panthor: - Print task/pid on errors - Fixes renesas: - convert to RUNTIME_PM_OPS repaper: - Use shadow-plane helpers rocket: - Add driver for Rockchip NPU plus DT bindings sharp-memory: - Use shadow-plane helpers simpledrm: - Use of_reserved_mem_region_to_resource() helper tidss: - Use crtc_ fields for programming display mode - Remove other drivers from aperture v3d: - Support querying nubmer of GPU resets for KHR_robustness vmwgfx: - Fixes Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250814072454.GA18104@linux.fritz.box
2025-08-17rust: alloc: fix `rusttest` by providing `Cmalloc::aligned_layout` tooMiguel Ojeda1-0/+11
Commit fde578c86281 ("rust: alloc: replace aligned_size() with Kmalloc::aligned_layout()") provides a public `aligned_layout` function in `Kamlloc`, but not in `Cmalloc`, and thus uses of it will trigger an error in `rusttest`. Such a user appeared in the following commit 22ab0641b939 ("rust: drm: ensure kmalloc() compatible Layout"): error[E0599]: no function or associated item named `aligned_layout` found for struct `alloc::allocator_test::Cmalloc` in the current scope --> rust/kernel/drm/device.rs:100:31 | 100 | let layout = Kmalloc::aligned_layout(Layout::new::<Self>()); | ^^^^^^^^^^^^^^ function or associated item not found in `Cmalloc` | ::: rust/kernel/alloc/allocator_test.rs:19:1 | 19 | pub struct Cmalloc; | ------------------ function or associated item `aligned_layout` not found for this struct Thus add an equivalent one for `Cmalloc`. Fixes: fde578c86281 ("rust: alloc: replace aligned_size() with Kmalloc::aligned_layout()") Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/r/20250816204215.2719559-1-ojeda@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-08-14rust: devres: fix leaking call to devm_add_action()Danilo Krummrich1-9/+18
When the data argument of Devres::new() is Err(), we leak the preceding call to devm_add_action(). In order to fix this, call devm_add_action() in a unit type initializer in try_pin_init!() after the initializers of all other fields. Fixes: f5d3ef25d238 ("rust: devres: get rid of Devres' inner Arc") Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <lossin@kernel.org> Link: https://lore.kernel.org/r/20250812130928.11075-1-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-08-13rust: faux: fix C header linkMiguel Ojeda1-1/+1
Starting with Rust 1.91.0 (expected 2025-10-30), `rustdoc` has improved some false negatives around intra-doc links [1], and it found a broken intra-doc link we currently have: error: unresolved link to `include/linux/device/faux.h` --> rust/kernel/faux.rs:7:17 | 7 | //! C header: [`include/linux/device/faux.h`] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ no item named `include/linux/device/faux.h` in scope | = help: to escape `[` and `]` characters, add '\' before them like `\[` or `\]` = note: `-D rustdoc::broken-intra-doc-links` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(rustdoc::broken_intra_doc_links)]` Our `srctree/` C header links are not intra-doc links, thus they need the link destination. Thus fix it. Cc: stable <stable@kernel.org> Link: https://github.com/rust-lang/rust/pull/132748 [1] Fixes: 78418f300d39 ("rust/kernel: Add faux device bindings") Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Reviewed-by: Benno Lossin <lossin@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250804171311.1186538-1-ojeda@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-12rust: kbuild: clean output before running `rustdoc`Miguel Ojeda1-3/+7
`rustdoc` can get confused when generating documentation into a folder that contains generated files from other `rustdoc` versions. For instance, running something like: rustup default 1.78.0 make LLVM=1 rustdoc rustup default 1.88.0 make LLVM=1 rustdoc may generate errors like: error: couldn't generate documentation: invalid template: last line expected to start with a comment | = note: failed to create or modify "./Documentation/output/rust/rustdoc/src-files.js" Thus just always clean the output folder before generating the documentation -- we are anyway regenerating it every time the `rustdoc` target gets called, at least for the time being. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Reported-by: Daniel Almeida <daniel.almeida@collabora.com> Closes: https://rust-for-linux.zulipchat.com/#narrow/channel/288089/topic/x/near/527201113 Reviewed-by: Tamir Duberstein <tamird@kernel.org> Link: https://lore.kernel.org/r/20250726133435.2460085-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-08-12rust: workaround `rustdoc` target modifiers bugMiguel Ojeda1-0/+6
Starting with Rust 1.88.0 (released 2025-06-26), `rustdoc` complains about a target modifier mismatch in configurations where `-Zfixed-x18` is passed: error: mixing `-Zfixed-x18` will cause an ABI mismatch in crate `rust_out` | = help: the `-Zfixed-x18` flag modifies the ABI so Rust crates compiled with different values of this flag cannot be used together safely = note: unset `-Zfixed-x18` in this crate is incompatible with `-Zfixed-x18=` in dependency `core` = help: set `-Zfixed-x18=` in this crate or unset `-Zfixed-x18` in `core` = help: if you are sure this will not cause problems, you may use `-Cunsafe-allow-abi-mismatch=fixed-x18` to silence this error The reason is that `rustdoc` was not passing the target modifiers when configuring the session options, and thus it would report a mismatch that did not exist as soon as a target modifier is used in a dependency. We did not notice it in the kernel until now because `-Zfixed-x18` has been a target modifier only since 1.88.0 (and it is the only one we use so far). The issue has been reported upstream [1] and a fix has been submitted [2], including a test similar to the kernel case. [ This is now fixed upstream (thanks Guillaume for the quick review), so it will be fixed in Rust 1.90.0 (expected 2025-09-18). - Miguel ] Meanwhile, conditionally pass `-Cunsafe-allow-abi-mismatch=fixed-x18` to workaround the issue on our side. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Reported-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Closes: https://lore.kernel.org/rust-for-linux/36cdc798-524f-4910-8b77-d7b9fac08d77@oss.qualcomm.com/ Link: https://github.com/rust-lang/rust/issues/144521 [1] Link: https://github.com/rust-lang/rust/pull/144523 [2] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250727092317.2930617-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-08-12driver: rust: expand documentation for driver infrastructureDanilo Krummrich1-2/+87
Add documentation about generic driver infrastructure, representing a guideline on how the generic driver infrastructure is intended to be used to implement bus specific driver APIs. This covers aspects such as the bus specific driver trait, adapter implementation, driver registration and custom device ID types. Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250722150110.23565-4-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-08-12device: rust: expand documentation for DeviceDanilo Krummrich1-13/+126
The documentation for the generic Device type is outdated and deserves much more detail. Hence, expand the documentation and cover topics such as device types, device contexts, as well as information on how to use the generic device infrastructure to implement bus and class specific device types. Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250722150110.23565-3-dakr@kernel.org [ Add empty line after code blocks, "in" -> "within", remove unnecessary pin annotations in class device example. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-08-12device: rust: expand documentation for DeviceContextDanilo Krummrich1-11/+58
Expand the documentation around DeviceContext states and types, in order to provide detailed information about their purpose and relationship with each other. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Link: https://lore.kernel.org/r/20250722150110.23565-2-dakr@kernel.org [ Fix two minor typos. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-08-11rust: drm: don't pass the address of drm::Device to drm_dev_put()Danilo Krummrich1-3/+18
In drm_dev_put() call in AlwaysRefCounted::dec_ref() we rely on struct drm_device to be the first field in drm::Device, whereas everywhere else we correctly obtain the address of the actual struct drm_device. Analogous to the from_drm_device() helper, provide the into_drm_device() helper in order to address this. Fixes: 1e4b8896c0f3 ("rust: drm: add device abstraction") Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250731154919.4132-5-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-08-11rust: drm: remove pin annotations from drm::DeviceDanilo Krummrich1-2/+0
The #[pin_data] and #[pin] annotations are not necessary for drm::Device, since we don't use any pin-init macros, but only __pinned_init() on the impl PinInit<T::Data, Error> argument of drm::Device::new(). Fixes: 1e4b8896c0f3 ("rust: drm: add device abstraction") Reviewed-by: Benno Lossin <lossin@kernel.org> Link: https://lore.kernel.org/r/20250731154919.4132-4-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-08-11rust: drm: ensure kmalloc() compatible LayoutDanilo Krummrich1-2/+7
drm::Device is allocated through __drm_dev_alloc() (which uses kmalloc()) and the driver private data, <T as drm::Driver>::Data, is initialized in-place. Due to the order of fields in drm::Device pub struct Device<T: drm::Driver> { dev: Opaque<bindings::drm_device>, data: T::Data, } even with an arbitrary large alignment requirement of T::Data it can't happen that the size of Device is smaller than its alignment requirement. However, let's not rely on this subtle circumstance and create a proper kmalloc() compatible Layout. Fixes: 1e4b8896c0f3 ("rust: drm: add device abstraction") Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250731154919.4132-3-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-08-11rust: alloc: replace aligned_size() with Kmalloc::aligned_layout()Danilo Krummrich1-12/+18
aligned_size() dates back to when Rust did support kmalloc() only, but is now used in ReallocFunc::call() and hence for all allocators. However, the additional padding applied by aligned_size() is only required by the kmalloc() allocator backend. Hence, replace aligned_size() with Kmalloc::aligned_layout() and use it for the affected allocators, i.e. kmalloc() and kvmalloc(), only. While at it, make Kmalloc::aligned_layout() public, such that Rust abstractions, which have to call subsystem specific kmalloc() based allocation primitives directly, can make use of it. Fixes: 8a799831fc63 ("rust: alloc: implement `ReallocFunc`") Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250731154919.4132-2-dakr@kernel.org [ Remove `const` from Kmalloc::aligned_layout(). - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>