From f1f2a22b8683d7ac38821d4508d4549a2f0c0a0a Mon Sep 17 00:00:00 2001 From: Shankari Anand Date: Fri, 15 Aug 2025 21:47:06 +0530 Subject: rust: drm: update ARef and AlwaysRefCounted imports from sync::aref 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 Link: https://github.com/Rust-for-Linux/linux/issues/1173 Signed-off-by: Shankari Anand Reviewed-by: Benno Lossin Reviewed-by: Elle Rhumsaa Link: https://lore.kernel.org/r/20250815161706.1324860-1-shankari.ak0208@gmail.com Signed-off-by: Danilo Krummrich --- rust/kernel/drm/driver.rs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'rust/kernel/drm/driver.rs') diff --git a/rust/kernel/drm/driver.rs b/rust/kernel/drm/driver.rs index fe7e8d06961a..8fefae41bcc6 100644 --- a/rust/kernel/drm/driver.rs +++ b/rust/kernel/drm/driver.rs @@ -8,7 +8,7 @@ use crate::{ bindings, device, devres, drm, error::{to_result, Result}, prelude::*, - types::ARef, + sync::aref::ARef, }; use macros::vtable; -- cgit v1.2.3 From c2783c7cfefd55b1a5be781679cbee5191c0fd87 Mon Sep 17 00:00:00 2001 From: Miguel Ojeda Date: Wed, 30 Jul 2025 15:07:15 +0200 Subject: rust: drm: fix `srctree/` links 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 Reviewed-by: Daniel Almeida Signed-off-by: Miguel Ojeda --- rust/kernel/drm/driver.rs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'rust/kernel/drm/driver.rs') diff --git a/rust/kernel/drm/driver.rs b/rust/kernel/drm/driver.rs index fe7e8d06961a..d2dad77274c4 100644 --- a/rust/kernel/drm/driver.rs +++ b/rust/kernel/drm/driver.rs @@ -2,7 +2,7 @@ //! DRM driver core. //! -//! C header: [`include/linux/drm/drm_drv.h`](srctree/include/linux/drm/drm_drv.h) +//! C header: [`include/drm/drm_drv.h`](srctree/include/drm/drm_drv.h) use crate::{ bindings, device, devres, drm, -- cgit v1.2.3 From 6ea42e9146f7ab8e59ffea8aa3300ad6710399dd Mon Sep 17 00:00:00 2001 From: Lyude Paul Date: Mon, 8 Sep 2025 14:46:36 -0400 Subject: rust: drm: gem: Simplify use of generics 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 (has the callbacks) * DriverObject (has the drm::Driver type) * Crate implements: * IntoGEMObject for Object 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 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 Reviewed-by: Daniel Almeida Acked-by: Danilo Krummrich Reviewed-by: Alice Ryhl Link: https://lore.kernel.org/r/20250908185239.135849-2-lyude@redhat.com Signed-off-by: Alice Ryhl --- rust/kernel/drm/driver.rs | 3 +++ 1 file changed, 3 insertions(+) (limited to 'rust/kernel/drm/driver.rs') diff --git a/rust/kernel/drm/driver.rs b/rust/kernel/drm/driver.rs index fe7e8d06961a..dae0f4d1bbe3 100644 --- a/rust/kernel/drm/driver.rs +++ b/rust/kernel/drm/driver.rs @@ -86,6 +86,9 @@ pub struct AllocOps { /// Trait for memory manager implementations. Implemented internally. pub trait AllocImpl: super::private::Sealed + drm::gem::IntoGEMObject { + /// The [`Driver`] implementation for this [`AllocImpl`]. + type Driver: drm::Driver; + /// The C callback operations for this memory manager. const ALLOC_OPS: AllocOps; } -- cgit v1.2.3