aboutsummaryrefslogtreecommitdiffstats
path: root/rust (follow)
AgeCommit message (Collapse)AuthorFilesLines
2025-09-13rust: support large alignments in allocationsVitaly Wool3-27/+18
Add support for large (> PAGE_SIZE) alignments in Rust allocators. All the preparations on the C side are already done, we just need to add bindings for <alloc>_node_align() functions and start using those. Link: https://lkml.kernel.org/r/20250806125552.1727073-1-vitaly.wool@konsulko.se Signed-off-by: Vitaly Wool <vitaly.wool@konsulko.se> Acked-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Alice Ryhl <aliceryhl@google.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Jann Horn <jannh@google.com> Cc: Kent Overstreet <kent.overstreet@linux.dev> Cc: Liam Howlett <liam.howlett@oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Cc: Uladzislau Rezki (Sony) <urezki@gmail.com> Cc: Vlastimil Babka <vbabka@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-09-13rust: add support for NUMA ids in allocationsVitaly Wool7-29/+90
Add a new type to support specifying NUMA identifiers in Rust allocators and extend the allocators to have NUMA id as a parameter. Thus, modify ReallocFunc to use the new extended realloc primitives from the C side of the kernel (i.e. k[v]realloc_node_align/vrealloc_node_align) and add the new function alloc_node to the Allocator trait while keeping the existing one (alloc) for backward compatibility. This will allow to specify node to use for allocation of e. g. {KV}Box, as well as for future NUMA aware users of the API. [ojeda@kernel.org: fix missing import needed for `rusttest`] Link: https://lkml.kernel.org/r/20250816210214.2729269-1-ojeda@kernel.org Link: https://lkml.kernel.org/r/20250806125522.1726992-1-vitaly.wool@konsulko.se Signed-off-by: Vitaly Wool <vitaly.wool@konsulko.se> Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Acked-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Alice Ryhl <aliceryhl@google.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Jann Horn <jannh@google.com> Cc: Kent Overstreet <kent.overstreet@linux.dev> Cc: Liam Howlett <liam.howlett@oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Cc: Uladzislau Rezki (Sony) <urezki@gmail.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
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-11Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski1-5/+10
Cross-merge networking fixes after downstream PR (net-6.17-rc6). Conflicts: net/netfilter/nft_set_pipapo.c net/netfilter/nft_set_pipapo_avx2.c c4eaca2e1052 ("netfilter: nft_set_pipapo: don't check genbit from packetpath lookups") 84c1da7b38d9 ("netfilter: nft_set_pipapo: use avx2 algorithm for insertions too") Only trivial adjacent changes (in a doc and a Makefile). Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-12dma-mapping: introduce new DMA attribute to indicate MMIO memoryLeon Romanovsky1-0/+3
This patch introduces the DMA_ATTR_MMIO attribute to mark DMA buffers that reside in memory-mapped I/O (MMIO) regions, such as device BARs exposed through the host bridge, which are accessible for peer-to-peer (P2P) DMA. This attribute is especially useful for exporting device memory to other devices for DMA without CPU involvement, and avoids unnecessary or potentially detrimental CPU cache maintenance calls. DMA_ATTR_MMIO is supposed to provide dma_map_resource() functionality without need to call to special function and perform branching when processing generic containers like bio_vec by the callers. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/6f058ec395c5348014860dbc2eed348c17975843.1757423202.git.leonro@nvidia.com
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-10rust: regulator: add devm_enable and devm_enable_optionalDaniel Almeida2-1/+69
A lot of drivers only care about enabling the regulator for as long as the underlying Device is bound. This can be easily observed due to the extensive use of `devm_regulator_get_enable` and `devm_regulator_get_enable_optional` throughout the kernel. Therefore, make this helper available in Rust. Also add an example noting how it should be the default API unless the driver needs more fine-grained control over the regulator. Suggested-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com> Link: https://patch.msgid.link/20250910-regulator-remove-dynamic-v3-2-07af4dfa97cc@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-09-10rust: regulator: remove Regulator<Dynamic>Daniel Almeida1-87/+1
After some experimenting and further discussion, it is starting to look like Regulator<Dynamic> might be a footgun. It turns out that one can get the same behavior by correctly using just Regulator<Enabled> and Regulator<Disabled>, so there is no need to directly expose the manual refcounting ability of Regulator<Dynamic> to clients. Remove it while we do not have any other users. Suggested-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com> Link: https://patch.msgid.link/20250910-regulator-remove-dynamic-v3-1-07af4dfa97cc@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-09-10rust: debugfs: Add support for scoped directoriesMatthew Maurer2-15/+320
Introduces the concept of a `ScopedDir`, which allows for the creation of debugfs directories and files that are tied to the lifetime of a particular data structure. This ensures that debugfs entries do not outlive the data they refer to. The new `Dir::scope` method creates a new directory that is owned by a `Scope` handle. All files and subdirectories created within this scope are automatically cleaned up when the `Scope` is dropped. Signed-off-by: Matthew Maurer <mmaurer@google.com> Tested-by: Dirk Behme <dirk.behme@de.bosch.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250904-debugfs-rust-v11-6-7d12a165685a@google.com [ Fix up Result<(), Error> -> Result; fix spurious backtick in doc-comment. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-09-10rust: debugfs: Add support for callback-based filesMatthew Maurer3-0/+219
Extends the `debugfs` API to support creating files with content generated and updated by callbacks. This is done via the `read_callback_file`, `write_callback_file`, and `read_write_callback_file` methods. These methods allow for more flexible file definition, either because the type already has a `Writer` or `Reader` method that doesn't do what you'd like, or because you cannot implement it (e.g. because it's a type defined in another crate or a primitive type). Signed-off-by: Matthew Maurer <mmaurer@google.com> Tested-by: Dirk Behme <dirk.behme@de.bosch.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250904-debugfs-rust-v11-4-7d12a165685a@google.com [ Fix up Result<(), Error> -> Result. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-09-10rust: debugfs: Add support for writable filesMatthew Maurer3-3/+216
Extends the `debugfs` API to support creating writable files. This is done via the `Dir::write_only_file` and `Dir::read_write_file` methods, which take a data object that implements the `Reader` trait. Signed-off-by: Matthew Maurer <mmaurer@google.com> Tested-by: Dirk Behme <dirk.behme@de.bosch.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250904-debugfs-rust-v11-3-7d12a165685a@google.com [ Fix up Result<()> -> Result. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-09-10rust: debugfs: Add support for read-only filesMatthew Maurer4-1/+350
Extends the `debugfs` API to support creating read-only files. This is done via the `Dir::read_only_file` method, which takes a data object that implements the `Writer` trait. The file's content is generated by the `Writer` implementation, and the file is automatically removed when the returned `File` handle is dropped. Signed-off-by: Matthew Maurer <mmaurer@google.com> Tested-by: Dirk Behme <dirk.behme@de.bosch.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250904-debugfs-rust-v11-2-7d12a165685a@google.com [ Fixup build failure when CONFIG_DEBUGFS=n. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-09-10rust: debugfs: Add initial support for directoriesMatthew Maurer4-0/+145
Adds a `debugfs::Dir` type that can be used to create and remove DebugFS directories. The `Dir` handle automatically cleans up the directory on `Drop`. Signed-off-by: Matthew Maurer <mmaurer@google.com> Tested-by: Dirk Behme <dirk.behme@de.bosch.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250904-debugfs-rust-v11-1-7d12a165685a@google.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
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-10rust: error: improve `to_result` documentationMiguel Ojeda1-2/+37
Core functions like `to_result` should have good documentation. Thus improve it, including adding an example of how to perform early returns with it. Reviewed-by: Benno Lossin <lossin@kernel.org> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-09-10rust: error: improve `Error::from_errno` documentationMiguel Ojeda1-2/+17
This constructor is public since commit 5ed147473458 ("rust: error: make conversion functions public"), and we will refer to it from the documentation of `to_result` in a later commit. Thus improve its documentation, including adding examples. Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Benno Lossin <lossin@kernel.org> Signed-off-by: Miguel Ojeda <ojeda@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-08rust: cpufreq: replace `MaybeUninit::zeroed().assume_init()` with ↵Benno Lossin1-3/+1
`pin_init::zeroed()` All types in `bindings` implement `Zeroable` if they can, so use `pin_init::zeroed` instead of relying on `unsafe` code. If this ends up not compiling in the future, something in bindgen or on the C side changed and is most likely incorrect. Signed-off-by: Benno Lossin <lossin@kernel.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-09-08rust: derive `Zeroable` for all structs & unions generated by bindgen where ↵Benno Lossin3-0/+14
possible Using the `--with-derive-custom-{struct,union}` option of bindgen, add `#[derive(MaybeZeroable)]` to every struct & union. This makes those types implement `Zeroable` if all their fields implement it. Sadly bindgen doesn't add custom derives to the `__BindgenBitfieldUnit` struct. So manually implement `Zeroable` for that. Signed-off-by: Benno Lossin <lossin@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> [ Formatted comment. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-09-08rust: add `pin-init` as a dependency to `bindings` and `uapi`Benno Lossin1-6/+8
This allows `bindings` and `uapi` to implement `Zeroable` and use other items from pin-init. Co-developed-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Link: https://rust-for-linux.zulipchat.com/#narrow/channel/291565-Help/topic/Zeroable.20trait.20for.20C.20structs/near/510264158 Signed-off-by: Benno Lossin <lossin@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-09-08rust: task: update ARef and AlwaysRefCounted imports from sync::arefShankari Anand1-3/+4
Update call sites in `task.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> Reviewed-by: Benno Lossin <lossin@kernel.org> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-09-08rust: prelude: re-export `core::mem::{align,size}_of{,_val}`Miguel Ojeda1-1/+4
Rust 1.80.0 added: align_of align_of_val size_of size_of_val from `core::mem` to the prelude [1]. For similar reasons, and to minimize potential confusion when code may work in later versions but not in our current minimum, add it to our prelude too. Link: https://github.com/rust-lang/rust/pull/123168 [1] Link: https://lore.kernel.org/rust-for-linux/CANiq72kOLYR2A95o0ji2mDmEqOKh9e9_60zZKmgF=vZmsW6DRg@mail.gmail.com/ [2] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Benno Lossin <lossin@kernel.org> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-09-08rust: error: add C header linksOnur Özkan1-1/+3
The error codes come from several headers. Thus, add the other header links. Signed-off-by: Onur Özkan <work@onurozkan.dev> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> [ Sorted headers. Added line breaks. Reworded commit message. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-09-08rust: warn if `srctree/` links do not existMiguel Ojeda1-0/+6
`srctree/` links may point to nonexistent files, e.g. due to renames that missed to update the files or simply because of typos. Since they can be easily checked for validity, do so and print a warning in the file does not exist. This found the following cases already in-tree: warning: srctree/ link to include/linux/blk_mq.h does not exist warning: srctree/ link to include/linux/drm/drm_gem.h does not exist warning: srctree/ link to include/linux/drm/drm_drv.h does not exist warning: srctree/ link to include/linux/drm/drm_ioctl.h does not exist warning: srctree/ link to include/linux/drm/drm_file.h does not exist warning: srctree/ link to include/linux/drm/drm_device.h does not exist Inspired-by: Onur Özkan <work@onurozkan.dev> Link: https://lore.kernel.org/rust-for-linux/CANiq72=xCYA7z7_rxpzzKkkhJs6m7L_xEaLMuArVn3ZAcyeHdA@mail.gmail.com/ Reviewed-by: Onur Özkan <work@onurozkan.dev> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Tested-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-09-08rust: drm: fix `srctree/` linksMiguel Ojeda5-5/+5
These `srctree/` links pointed inside `linux/`, but they are directly under `drm/`. Thus fix them. This cleans a future warning that will check our `srctree/` links. Cc: stable@vger.kernel.org Fixes: a98a73be9ee9 ("rust: drm: file: Add File abstraction") Fixes: c284d3e42338 ("rust: drm: gem: Add GEM object abstraction") Fixes: 07c9016085f9 ("rust: drm: add driver abstractions") Fixes: 1e4b8896c0f3 ("rust: drm: add device abstraction") Fixes: 9a69570682b1 ("rust: drm: ioctl: Add DRM ioctl abstraction") Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-09-08rust: block: fix `srctree/` linksMiguel Ojeda1-1/+1
This `srctree/` link pointed to a file with an underscore, but the header used a dash instead. Thus fix it. This cleans a future warning that will check our `srctree/` links. Cc: stable@vger.kernel.org Fixes: 3253aba3408a ("rust: block: introduce `kernel::block::mq` module") Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-09-08rust: sync: Update ARef and AlwaysRefCounted imports from sync::arefShankari Anand1-1/+1
Update the in-file reference of sync/aref.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> Reviewed-by: Benno Lossin <lossin@kernel.org> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-09-08Merge tag 'alloc-next-v6.18-2025-09-04' of ↵Miguel Ojeda13-157/+129
https://github.com/Rust-for-Linux/linux into rust-next Pull alloc and DMA updates from Danilo Krummrich: Allocator: - Provide information about the minimum alignment guarantees of 'Kmalloc', 'Vmalloc' and 'KVmalloc'. - Take minimum alignment guarantees of allocators for 'ForeignOwnable' into account. - Remove the 'allocator_test' incl. 'Cmalloc'. Box: - Implement 'Box::pin_slice()', which constructs a pinned slice of elements. Vec: - Simplify KUnit test module name to 'rust_kvec'. - Add doc-test for 'Vec::as_slice()'. - Constify various methods. DMA: - Update 'ARef' and 'AlwaysRefCounted' imports. MISC: - Remove support for unused host '#[test]'s. - Constify 'ArrayLayout::new_unchecked()'. * tag 'alloc-next-v6.18-2025-09-04' of https://github.com/Rust-for-Linux/linux: rust: alloc: remove `allocator_test` rust: kernel: remove support for unused host `#[test]`s rust: alloc: implement Box::pin_slice() rust: alloc: add ARCH_KMALLOC_MINALIGN to bindgen blocklist rust: dma: Update ARef and AlwaysRefCounted imports from sync::aref rust: alloc: take the allocator into account for FOREIGN_ALIGN rust: alloc: specify the minimum alignment of each allocator rust: make `kvec::Vec` functions `const fn` rust: make `ArrayLayout::new_unchecked` a `const fn` rust: alloc: kvec: simplify KUnit test module name to "rust_kvec" rust: alloc: kvec: add doc example for as_slice method
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-06Merge patch series "Rust support for `struct iov_iter`"Greg Kroah-Hartman5-1/+448
Alice Ryhl <aliceryhl@google.com> says: This series adds support for the `struct iov_iter` type. This type represents an IO buffer for reading or writing, and can be configured for either direction of communication. In Rust, we define separate types for reading and writing. This will ensure that you cannot mix them up and e.g. call copy_from_iter in a read_iter syscall. To use the new abstractions, miscdevices are given new methods read_iter and write_iter that can be used to implement the read/write syscalls on a miscdevice. The miscdevice sample is updated to provide read/write operations. Intended for Greg's miscdevice tree. Link: https://lore.kernel.org/r/20250822-iov-iter-v5-0-6ce4819c2977@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-06rust: miscdevice: Provide additional abstractions for iov_iter and kiocb ↵Alice Ryhl1-1/+62
structures These will be used for the read_iter() and write_iter() callbacks, which are now the preferred back-ends for when a user operates on a char device with read() and write() respectively. Co-developed-by: Lee Jones <lee@kernel.org> Signed-off-by: Lee Jones <lee@kernel.org> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250822-iov-iter-v5-4-6ce4819c2977@google.com
2025-09-06rust: fs: add Kiocb structAlice Ryhl2-0/+71
This adds a very simple Kiocb struct that lets you access the inner file's private data and the file position. For now, nothing else is supported. Cc: Christian Brauner <brauner@kernel.org> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250822-iov-iter-v5-3-6ce4819c2977@google.com
2025-09-06rust: iov: add iov_iter abstractions for ITER_DESTAlice Ryhl1-0/+143
This adds abstractions for the iov_iter type in the case where data_source is ITER_DEST. This will make Rust implementations of fops->read_iter possible. This series only has support for using existing IO vectors created by C code. Additional abstractions will be needed to support the creation of IO vectors in Rust code. These abstractions make the assumption that `struct iov_iter` does not have internal self-references, which implies that it is valid to move it between different local variables. This patch adds an IovIterDest struct that is very similar to the IovIterSource from the previous patch. However, as the methods on the two structs have very little overlap (just getting the length and advance/revert), I do not think it is worth it to try and deduplicate this logic. Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250822-iov-iter-v5-2-6ce4819c2977@google.com
2025-09-06rust: iov: add iov_iter abstractions for ITER_SOURCEAlice Ryhl2-0/+172
This adds abstractions for the iov_iter type in the case where data_source is ITER_SOURCE. This will make Rust implementations of fops->write_iter possible. This series only has support for using existing IO vectors created by C code. Additional abstractions will be needed to support the creation of IO vectors in Rust code. These abstractions make the assumption that `struct iov_iter` does not have internal self-references, which implies that it is valid to move it between different local variables. Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250822-iov-iter-v5-1-6ce4819c2977@google.com
2025-09-05regulator: pf530x: NXP PF530x regulator driverMark Brown8-58/+357
Merge series from Woodrow Douglass <wdouglass@carnegierobotics.com>: I wrote this driver to read settings and state from the nxp pf530x regulator. Please consider it for inclusion, any criticism is welcome.
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>
generated by cgit v1.2.3 (git 2.39.1) at 2025-12-12 04:05:50 +0000