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>
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>
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>
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: 3253aba340 ("rust: block: introduce `kernel::block::mq` module")
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
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
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
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>
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
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
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.
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>
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>
Merge OPP (operating performance points) updates for 6.18 from Viresh
Kumar:
"- Add support to find OPP for a set of keys (Krishna Chaitanya Chundru).
- Minor optimization to OPP Rust implementation (Onur Özkan)."
* tag 'opp-updates-6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm:
OPP: Add support to find OPP for a set of keys
rust: opp: use to_result for error handling
While rvkms is only going to be using a few of these, since Deltas are
basically the same as i64 it's easy enough to just implement all of the
basic arithmetic operations for Delta types.
Keep in mind there's one quirk here - the kernel has no support for
i64 % i64 on 32 bit platforms, the closest we have is i64 % i32 through
div_s64_rem(). So, instead of implementing ops::Rem or ops::RemAssign we
simply provide Delta::rem_nanos().
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Link: https://lore.kernel.org/r/20250820203704.731588-3-lyude@redhat.com
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
With Linux's hrtimer API, there's a number of methods that can only be
called in two situations:
* When we have exclusive access to the hrtimer and it is not currently
active
* When we're within the context of an hrtimer callback context
This commit handles the second situation and implements hrtimer_forward()
support in the context of a timer callback. We do this by introducing a
HrTimerCallbackContext type which is provided to users during the
RawHrTimerCallback::run() callback, and then add a forward() function to
the type.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Link: https://lore.kernel.org/r/20250821193259.964504-5-lyude@redhat.com
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Within the hrtimer API there are quite a number of functions that can only
be safely called from one of two contexts:
* When we have exclusive access to the hrtimer and the timer is not active.
* When we're within the hrtimer's callback context as it is being executed.
This commit adds bindings for hrtimer_forward() for the first such context,
along with HrTimer::raw_forward() for later use in implementing the
hrtimer_forward() in the latter context.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Link: https://lore.kernel.org/r/20250821193259.964504-4-lyude@redhat.com
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
