From nobody Sun Feb 8 08:48:55 2026 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 51C5B2FE56E; Fri, 16 Jan 2026 00:36:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768523768; cv=none; b=ImR5wplTWVLRkgW4SNZr2Q1KRBw3hy+Hcmes+7jV9CKagPfIGlbb42BdcKdMQIK1nc0ygjCcGajEoQ3N8F59Sf45omIol/4HZXTI4JflB7N+p6BIW+bYQuWnS7Cdav3DC1v9rTS5auBdjWR09CALCnBPOxMctLV08MucoRsIuqw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768523768; c=relaxed/simple; bh=qp1iKf391KY2mUCxLej6xprZ+WzxUPUnRVNWXA+uTRU=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=XxMfYqjTnYxZy77rNmPy5ZyuNMeEOfo9cq8Hwa2PDn0ZaML+rnt+hnJQm2i1Io1awJvbveEYzHYxwI7Nr3jeqy1OiXPLdrSAsY/ln/FB0QAgmaZdMxt9Ao41wnrHd8LTZ92j/3ik8ADNIiYIg0++DWEDA+xkGutbQGFOAsqfa5k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=MBKi8xsv; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="MBKi8xsv" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1768523765; bh=qp1iKf391KY2mUCxLej6xprZ+WzxUPUnRVNWXA+uTRU=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=MBKi8xsvdpU9+w2SG5bM3zGHSCHmxFoUg/VvByV+Dhpoc05/OhjoNn8MFPzZ+Q9hm Xgf5gMgSWJc7RLTTFRp4EHfRou29mGl0FZMA8b5JwZY09aeDNzwxL0KExWAIWl5+/s dvwe0rk4v7o3S6u7vkPRL2AfuOmtjaGqYqHAsLjkDYFBc/vkA/Kga87AOieuhDXw3E dr3JwlfBV9D5Cqi9BgsiTNhxOoLONYtYGIlpjzDGMz9r0itAEWePYZuYgHwa9SHaJk b/Q6AXgzWUaRnfSgCGvLG3k/RdYWJ4dbXTn7FW1QIbxfIQal2NZF/1YGRLRkCXj/Fn fwoPkZcFQwcYw== Received: from [192.168.0.79] (unknown [IPv6:2804:14d:72b4:81ae:67c:16ff:fe57:b5a3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: dwlsalmeida) by bali.collaboradmins.com (Postfix) with ESMTPSA id 6426317E13E0; Fri, 16 Jan 2026 01:36:03 +0100 (CET) From: Daniel Almeida Date: Thu, 15 Jan 2026 21:35:57 -0300 Subject: [PATCH 1/4] rust: workqueue: add support for ARef Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260115-aref-workitem-v1-1-9883e00f0509@collabora.com> References: <20260115-aref-workitem-v1-0-9883e00f0509@collabora.com> In-Reply-To: <20260115-aref-workitem-v1-0-9883e00f0509@collabora.com> To: Miguel Ojeda , Boqun Feng , Gary Guo , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Danilo Krummrich , David Airlie , Simona Vetter Cc: rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Daniel Almeida X-Mailer: b4 0.14.3 Add support for the ARef smart pointer. This allows an instance of ARef to handle deferred work directly, which can be convenient or even necessary at times, depending on the specifics of the driver or subsystem. The implementation is similar to that of Arc, and a subsequent patch will implement support for drm::Device as the first user. This is notably important for work items that need access to the drm device, as it was not possible to enqueue work on a ARef> previously without failing the orphan rule. Signed-off-by: Daniel Almeida Reviewed-by: Alice Ryhl --- rust/kernel/workqueue.rs | 85 ++++++++++++++++++++++++++++++++++++++++++++= ---- 1 file changed, 79 insertions(+), 6 deletions(-) diff --git a/rust/kernel/workqueue.rs b/rust/kernel/workqueue.rs index 706e833e9702..6ae7f3fb3496 100644 --- a/rust/kernel/workqueue.rs +++ b/rust/kernel/workqueue.rs @@ -192,9 +192,9 @@ sync::Arc, sync::LockClassKey, time::Jiffies, - types::Opaque, + types::{ARef, AlwaysRefCounted, Opaque}, }; -use core::marker::PhantomData; +use core::{marker::PhantomData, ptr::NonNull}; =20 /// Creates a [`Work`] initialiser with the given name and a newly-created= lock class. #[macro_export] @@ -425,10 +425,11 @@ pub unsafe trait RawDelayedWorkItem: R= awWorkItem {} =20 /// Defines the method that should be called directly when a work item is = executed. /// -/// This trait is implemented by `Pin>` and [`Arc`], and is mai= nly intended to be -/// implemented for smart pointer types. For your own structs, you would i= mplement [`WorkItem`] -/// instead. The [`run`] method on this trait will usually just perform th= e appropriate -/// `container_of` translation and then call into the [`run`][WorkItem::ru= n] method from the +/// This trait is implemented by `Pin>`, [`Arc`] and [`ARef`= ], and +/// is mainly intended to be implemented for smart pointer types. For your= own +/// structs, you would implement [`WorkItem`] instead. The [`run`] method = on +/// this trait will usually just perform the appropriate `container_of` +/// translation and then call into the [`run`][WorkItem::run] method from = the /// [`WorkItem`] trait. /// /// This trait is used when the `work_struct` field is defined using the [= `Work`] helper. @@ -934,6 +935,78 @@ unsafe impl RawDelayedWorkItem f= or Pin> { } =20 +// SAFETY: Like the `Arc` implementation, the `__enqueue` implementatio= n for +// `ARef` obtains a `work_struct` from the `Work` field using +// `T::raw_get_work`, so the same safety reasoning applies: +// +// - `__enqueue` gets the `work_struct` from the `Work` field, using `T:= :raw_get_work`. +// - The only safe way to create a `Work` object is through `Work::new`. +// - `Work::new` makes sure that `T::Pointer::run` is passed to `init_wo= rk_with_key`. +// - Finally `Work` and `RawWorkItem` guarantee that the correct `Work` = field +// will be used because of the ID const generic bound. This makes sure= that `T::raw_get_work` +// uses the correct offset for the `Work` field, and `Work::new` picks= the correct +// implementation of `WorkItemPointer` for `ARef`. +unsafe impl WorkItemPointer for ARef +where + T: AlwaysRefCounted, + T: WorkItem, + T: HasWork, +{ + unsafe extern "C" fn run(ptr: *mut bindings::work_struct) { + // The `__enqueue` method always uses a `work_struct` stored in a = `Work`. + let ptr =3D ptr.cast::>(); + + // SAFETY: This computes the pointer that `__enqueue` got from + // `ARef::into_raw`. + let ptr =3D unsafe { T::work_container_of(ptr) }; + + // SAFETY: The safety contract of `work_container_of` ensures that= it + // returns a valid non-null pointer. + let ptr =3D unsafe { NonNull::new_unchecked(ptr) }; + + // SAFETY: This pointer comes from `ARef::into_raw` and we've been= given + // back ownership. + let aref =3D unsafe { ARef::from_raw(ptr) }; + + T::run(aref) + } +} + +// SAFETY: The `work_struct` raw pointer is guaranteed to be valid for the= duration of the call to +// the closure because we get it from an `ARef`, which means that the ref = count will be at least 1, +// and we don't drop the `ARef` ourselves. If `queue_work_on` returns true= , it is further guaranteed +// to be valid until a call to the function pointer in `work_struct` becau= se we leak the memory it +// points to, and only reclaim it if the closure returns false, or in `Wor= kItemPointer::run`, which +// is what the function pointer in the `work_struct` must be pointing to, = according to the safety +// requirements of `WorkItemPointer`. +unsafe impl RawWorkItem for ARef +where + T: AlwaysRefCounted, + T: WorkItem, + T: HasWork, +{ + type EnqueueOutput =3D Result<(), Self>; + + unsafe fn __enqueue(self, queue_work_on: F) -> Self::EnqueueOutput + where + F: FnOnce(*mut bindings::work_struct) -> bool, + { + let ptr =3D ARef::into_raw(self); + + // SAFETY: Pointers from ARef::into_raw are valid and non-null. + let work_ptr =3D unsafe { T::raw_get_work(ptr.as_ptr()) }; + // SAFETY: `raw_get_work` returns a pointer to a valid value. + let work_ptr =3D unsafe { Work::raw_get(work_ptr) }; + + if queue_work_on(work_ptr) { + Ok(()) + } else { + // SAFETY: The work queue has not taken ownership of the point= er. + Err(unsafe { ARef::from_raw(ptr) }) + } + } +} + /// Returns the system work queue (`system_wq`). /// /// It is the one used by `schedule[_delayed]_work[_on]()`. Multi-CPU mult= i-threaded. There are --=20 2.52.0 From nobody Sun Feb 8 08:48:55 2026 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E91D82FE058; Fri, 16 Jan 2026 00:36:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768523771; cv=none; b=cGPrBWobK0HuCOJAkm+p+9XjBeCccfQ4AqyhX1U5i8fNQbe55dMz82CPtXSDLI5kS/rBWNqHgs97lMbDxTTNbgE4HcdlImWWowmHCAQaQG36N7knE+yQU5j9QpU3tR7VUb6IcneTRXK5JNkjT2LwY/JiTIw5I0lMp6zdxtTdAoA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768523771; c=relaxed/simple; bh=ApvBkXicI2zoEGRrzQsJJHposj44s/SN+iBr72P8xoc=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=Xwx2y09nT3wMlteCOxgNo1OGZnSHAM8OG5yA1QQUkIlv4WHqe6Xlf6vLCbJ7tlAXyligErazLwJWZTKWcLcoCHzm4ijg3Gu8jCYhlfhe9RqDxCjllFahxNXsDUxfyYib4LUbISWXjlT2txtECeC7AicuWFSLkhPK8+SfJL92sR8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=EQuGI/ut; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="EQuGI/ut" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1768523768; bh=ApvBkXicI2zoEGRrzQsJJHposj44s/SN+iBr72P8xoc=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=EQuGI/ut6g1g/mtviAmk/tsAa7gaVSY1TIEb8dfsV0wGul+/P78+9eZ5NHunD8/Yb VhM8nAAA7gDquW7Z5b+rx11ZNpIP+0W4HetRyvHn8oJ7pz/m8oaiOLtSN57i9h0fhr 79CXrwapT6UBEvsfyrJ20mlv53CG0nd6orgqRGLtciEbv58SCGxBZPfh0b0c2j3nej 0jtDLou17zFecne/59jWtUzBP8mbWurFbChvG1jlcu3wq8IYahu1lOMmo2oEzSpliz IzsfG5AJ+tUGqRksGBMb3307XVzcM1fFJlt/VEeKiheGJnk1BbqgOFDUMEG8dR+jCk XrVZqVGMJRMNw== Received: from [192.168.0.79] (unknown [IPv6:2804:14d:72b4:81ae:67c:16ff:fe57:b5a3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: dwlsalmeida) by bali.collaboradmins.com (Postfix) with ESMTPSA id 18E2A17E1406; Fri, 16 Jan 2026 01:36:05 +0100 (CET) From: Daniel Almeida Date: Thu, 15 Jan 2026 21:35:58 -0300 Subject: [PATCH 2/4] rust: drm: dispatch work items to the private data Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260115-aref-workitem-v1-2-9883e00f0509@collabora.com> References: <20260115-aref-workitem-v1-0-9883e00f0509@collabora.com> In-Reply-To: <20260115-aref-workitem-v1-0-9883e00f0509@collabora.com> To: Miguel Ojeda , Boqun Feng , Gary Guo , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Danilo Krummrich , David Airlie , Simona Vetter Cc: rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Daniel Almeida X-Mailer: b4 0.14.3 This implementation dispatches any work enqueued on ARef> to its driver-provided handler. It does so by building upon the newly-added ARef support in workqueue.rs in order to call into the driver implementations for work_container_of and raw_get_work. This is notably important for work items that need access to the drm device, as it was not possible to enqueue work on a ARef> previously without failing the orphan rule. The current implementation needs T::Data to live inline with drm::Device in order for work_container_of to function. This restriction is already captured by the trait bounds. Drivers that need to share their ownership of T::Data may trivially get around this: // Lives inline in drm::Device struct DataWrapper { work: ..., // Heap-allocated, shared ownership. data: Arc, } Signed-off-by: Daniel Almeida Reviewed-by: Alice Ryhl --- rust/kernel/drm/device.rs | 54 +++++++++++++++++++++++++++++++++++++++++++= ---- 1 file changed, 50 insertions(+), 4 deletions(-) diff --git a/rust/kernel/drm/device.rs b/rust/kernel/drm/device.rs index 3ce8f62a0056..c760a743e1df 100644 --- a/rust/kernel/drm/device.rs +++ b/rust/kernel/drm/device.rs @@ -6,13 +6,13 @@ =20 use crate::{ alloc::allocator::Kmalloc, - bindings, device, drm, - drm::driver::AllocImpl, - error::from_err_ptr, - error::Result, + bindings, device, + drm::{self, driver::AllocImpl}, + error::{from_err_ptr, Result}, prelude::*, sync::aref::{ARef, AlwaysRefCounted}, types::Opaque, + workqueue::{HasWork, Work, WorkItem}, }; use core::{alloc::Layout, mem, ops::Deref, ptr, ptr::NonNull}; =20 @@ -227,3 +227,49 @@ unsafe impl Send for Device {} // SAFETY: A `drm::Device` can be shared among threads because all immutab= le methods are protected // by the synchronization in `struct drm_device`. unsafe impl Sync for Device {} + +impl WorkItem for Device +where + T: drm::Driver, + T::Data: WorkItem>>, + T::Data: HasWork, ID>, +{ + type Pointer =3D ARef>; + + fn run(ptr: ARef>) { + T::Data::run(ptr); + } +} + +// SAFETY: +// +// - `raw_get_work` and `work_container_of` return valid pointers by relyi= ng on +// `T::Data::raw_get_work` and `container_of`. In particular, `T::Data` is +// stored inline in `drm::Device`, so the `container_of` call is valid. +// +// - The two methods are true inverses of each other: given `ptr: *mut +// Device`, `raw_get_work` will return a `*mut Work, ID>` thr= ough +// `T::Data::raw_get_work` and given a `ptr: *mut Work, ID>`, +// `work_container_of` will return a `*mut Device` through `container_o= f`. +unsafe impl HasWork, ID> for Device +where + T: drm::Driver, + T::Data: HasWork, ID>, +{ + unsafe fn raw_get_work(ptr: *mut Self) -> *mut Work, ID> { + // SAFETY: The caller promises that `ptr` points to a valid `Devic= e`. + let data_ptr =3D unsafe { &raw mut (*ptr).data }; + + // SAFETY: `data_ptr` is a valid pointer to `T::Data`. + unsafe { T::Data::raw_get_work(data_ptr) } + } + + unsafe fn work_container_of(ptr: *mut Work, ID>) -> *mut Sel= f { + // SAFETY: The caller promises that `ptr` points at a `Work` field= in + // `T::Data`. + let data_ptr =3D unsafe { T::Data::work_container_of(ptr) }; + + // SAFETY: `T::Data` is stored as the `data` field in `Device`. + unsafe { crate::container_of!(data_ptr, Self, data) } + } +} --=20 2.52.0 From nobody Sun Feb 8 08:48:55 2026 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8BC032FD66D; Fri, 16 Jan 2026 00:36:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768523777; cv=none; b=XMpWciyoKVUiHZW3jLIa2OHUGE4pi8SPX42X4CneroQ2E8NSKpClRe3WWMUtcgfw44oPKdm2kHO52AXMJpgApFINTV3sf13md0Y8zq3m4iNVpyxaeiXcRP14XVozLkKlY7L3asq7d+XLVtBMD5w7b/swCiSqn8ZhH7J/3OncIKk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768523777; c=relaxed/simple; bh=o7a0hN8233hHD9BCGtRr6Gh5sxlycp6ly9Wn2+YrBFA=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=hCXpw3Yb15ux/VjxMHU2/u4PUOMq4EwP0x+v9Uhg0IP22OK9hc3kCFqeZSQOmCwhP1HVZ+eF5c/Nvx+p5gWfokb8RcJSz3oBdrnYUC/J43N05vIBGBQMkdVfLxTV2ytWuShpYo5WVlfGQeGVNsIXvO8DV5SkiQQl6z3LWxA/ghw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=o1S/K9ME; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="o1S/K9ME" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1768523771; bh=o7a0hN8233hHD9BCGtRr6Gh5sxlycp6ly9Wn2+YrBFA=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=o1S/K9MEy5kdjtOUR5xIdio2/QW9LDIAHwbzPYasAuMD+EFzo2RyXSg+KGSVHP2hl gVVodzkI6qP1JHOGeNGkr0w0SWCHGWa3cwcNEyjfOJQytpdO60XmlIJJIohE9GRIZZ pS7AMuj7giqph3CYXo5mtJ9kxahWi3x5CDC0+E7IrqE6XFDqWwmU4rl/QTKZBTq3iI sGHhn/Ar4DkKoofCFEGgMHfnLhuhDqI1FTx1MCo9/JPqJ24C8byquJb6auCYJRaV+N oVKxqFTWW4ECbuyUre+qnGsMMMzY2XoKyQ2iTpgwYDORCZqIoQnNGrbvSmAa4onUAr CrQERMo1O7wiA== Received: from [192.168.0.79] (unknown [IPv6:2804:14d:72b4:81ae:67c:16ff:fe57:b5a3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: dwlsalmeida) by bali.collaboradmins.com (Postfix) with ESMTPSA id B69AC17E1380; Fri, 16 Jan 2026 01:36:08 +0100 (CET) From: Daniel Almeida Date: Thu, 15 Jan 2026 21:35:59 -0300 Subject: [PATCH 3/4] rust: workqueue: add delayed work support for ARef Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260115-aref-workitem-v1-3-9883e00f0509@collabora.com> References: <20260115-aref-workitem-v1-0-9883e00f0509@collabora.com> In-Reply-To: <20260115-aref-workitem-v1-0-9883e00f0509@collabora.com> To: Miguel Ojeda , Boqun Feng , Gary Guo , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Danilo Krummrich , David Airlie , Simona Vetter Cc: rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Daniel Almeida X-Mailer: b4 0.14.3 The preceding patches added support for ARef work items. By the same token, add support for delayed work items too. The rationale is the same: it may be convenient or even necessary at times to implement HasDelayedWork directly on ARef. A follow up patch will also implement support for drm::Device as the first user. Signed-off-by: Daniel Almeida Reviewed-by: Alice Ryhl --- rust/kernel/workqueue.rs | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/rust/kernel/workqueue.rs b/rust/kernel/workqueue.rs index 6ae7f3fb3496..4ee4ff567197 100644 --- a/rust/kernel/workqueue.rs +++ b/rust/kernel/workqueue.rs @@ -1007,6 +1007,17 @@ unsafe fn __enqueue(self, queue_work_on: F) -> Se= lf::EnqueueOutput } } =20 +// SAFETY: By the safety requirements of `HasDelayedWork`, the `work_struc= t` returned by methods in +// `HasWork` provides a `work_struct` that is the `work` field of a `delay= ed_work`, and the rest of +// the `delayed_work` has the same access rules as its `work` field. +unsafe impl RawDelayedWorkItem for ARef +where + T: WorkItem, + T: HasDelayedWork, + T: AlwaysRefCounted, +{ +} + /// Returns the system work queue (`system_wq`). /// /// It is the one used by `schedule[_delayed]_work[_on]()`. Multi-CPU mult= i-threaded. There are --=20 2.52.0 From nobody Sun Feb 8 08:48:55 2026 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3EAC32FD69E; Fri, 16 Jan 2026 00:36:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768523776; cv=none; b=NTMzUT1E9WjMzhcuFXZIwkt2AIOnETY5e1BNRRr0ANcEaG30cHY38cdEGkEiXdMdBQcpRyMvASZjAJlIqFKDKmkXW3z0oLWGrWmMEx0rkMbJDkq9ufiWbYP0E5PnSMB76stvowjvH8FW1NpkLF9pObaOc7wcuGuJBweFjtDtgiA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768523776; c=relaxed/simple; bh=dd+gf/jKyogh1Q1ivowg9YoTCKDzuqKUdBLw/sUwIr4=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=nn5LJZJkgc8/1UiloL/RMNQ7LjeAl0V1y2DM+CiCyETMT+/m/i4MwxYz6+t6c45Qx3FWFDzGpKJcILPH5q1mEMwkFf3nIIu9ucaXhC+den6NXOqh4BeT9h3cNxI9U45OC9RzrG5km6r1xPUOyB1jYMopZLy9ldmjhtWhfhuY4Xg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=MCFiBk19; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="MCFiBk19" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1768523773; bh=dd+gf/jKyogh1Q1ivowg9YoTCKDzuqKUdBLw/sUwIr4=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=MCFiBk19KSyzj3GNb4YQJWZ+yHiLyG5SCkvs8n4GwaC519KqFbMWcPQ4LlJ3aW8RA Vyjtg1PDih0R4um/Cn46Lxxedl/TETvzArrwf5qkmvb8dasAGZ6y+vkRRJLJE4au99 6HMC7Xr75RfS08YIFTE8ZRVIJyiqnViBexaZZyR610IXJq3xkU61jBuvC3uyMnrnK1 +2gkg6Bht0x20HmH0v9P/XPZL4YLuxhqKF1q2cQlMaatQNUQ+Z8k8Y2w7SDkFTq/sp zpEzQFKvx08vIzj+Dfz7lVk3xzdwBRNaZ4oygUuPwGfK3tpte17IUPHuvNKPMbT3Lp 1Vq/bPpNCDQHQ== Received: from [192.168.0.79] (unknown [IPv6:2804:14d:72b4:81ae:67c:16ff:fe57:b5a3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: dwlsalmeida) by bali.collaboradmins.com (Postfix) with ESMTPSA id 63D8C17E138B; Fri, 16 Jan 2026 01:36:11 +0100 (CET) From: Daniel Almeida Date: Thu, 15 Jan 2026 21:36:00 -0300 Subject: [PATCH 4/4] rust: drm: dispatch delayed work items to the private data Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260115-aref-workitem-v1-4-9883e00f0509@collabora.com> References: <20260115-aref-workitem-v1-0-9883e00f0509@collabora.com> In-Reply-To: <20260115-aref-workitem-v1-0-9883e00f0509@collabora.com> To: Miguel Ojeda , Boqun Feng , Gary Guo , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Danilo Krummrich , David Airlie , Simona Vetter Cc: rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Daniel Almeida X-Mailer: b4 0.14.3 Much like the patch that dispatched (regular) work items, we also need to dispatch delayed work items in order not to trigger the orphan rule. This allows a drm::Device to dispatch the delayed work to T::Data. Signed-off-by: Daniel Almeida Reviewed-by: Alice Ryhl --- rust/kernel/drm/device.rs | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/rust/kernel/drm/device.rs b/rust/kernel/drm/device.rs index c760a743e1df..ad0447e8763f 100644 --- a/rust/kernel/drm/device.rs +++ b/rust/kernel/drm/device.rs @@ -12,7 +12,7 @@ prelude::*, sync::aref::{ARef, AlwaysRefCounted}, types::Opaque, - workqueue::{HasWork, Work, WorkItem}, + workqueue::{HasDelayedWork, HasWork, Work, WorkItem}, }; use core::{alloc::Layout, mem, ops::Deref, ptr, ptr::NonNull}; =20 @@ -273,3 +273,15 @@ unsafe fn work_container_of(ptr: *mut Work, = ID>) -> *mut Self { unsafe { crate::container_of!(data_ptr, Self, data) } } } + +// SAFETY: Our `HasWork` implementation returns a `work_struct` tha= t is +// stored in the `work` field of a `delayed_work` with the same access rul= es as +// the `work_struct` owing to the bound on `T::Data: HasDelayedWork, +// ID>`, which requires that `T::Data::raw_get_work` return a `work_struct= ` that +// is inside a `delayed_work`. +unsafe impl HasDelayedWork, ID> for Device +where + T: drm::Driver, + T::Data: HasDelayedWork, ID>, +{ +} --=20 2.52.0