From nobody Sat Feb 7 06:14:12 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 1A5C4436353; Wed, 4 Feb 2026 20:41:05 +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=1770237665; cv=none; b=JfTxsWB3AArElWIBtSO/ew0bOY9zGbbQmyr1gnepcyDHq5j9o37MezToLGpmUFo/Am7OYg8zqBgHjemGpR5+Kba2oIosK98su1MGKrNTQAJY5tLU0GRa/lq1PHnrANRDSTaNg7I/IBTvZ4zRbMQoWlr6erz0DRPVPLg5Z2nUQ68= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770237665; c=relaxed/simple; bh=qp1iKf391KY2mUCxLej6xprZ+WzxUPUnRVNWXA+uTRU=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=RFqm3wJmykRyMGitylODQKNPNxDkS+TCxESXv9L6/a7az8+PZSaksWfh8QJrjmG2pZD2i9aDeWLnSByJugYIaKCI1BC9BYA5xH32gMUyAv8005QvKTsVHLYY+19ClOAXOZmWhXh8fLgQxBvH7eF2t1HmARNbGixkM96malpAwWQ= 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=PphQE3pl; 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="PphQE3pl" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1770237663; bh=qp1iKf391KY2mUCxLej6xprZ+WzxUPUnRVNWXA+uTRU=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=PphQE3pltqlvoHgT9xUP/+r7GsGFIrvNNTSfwVG38YRPU/0tG3/Q8cIRHQpZZ4ovJ X6H3SFxcRaucCovzcSLaxgl+Kpv7ukr5bCi7q7MUwolBAVTdNyZn7ANtgK9H78Ax0f HVtgh6DMWSAIteSGhCuSF+blqmdMkShDl/R1pdcKIJwuZjVyVkIj07t/9CWr51U0QW xtDbCePDRmv2CqLWnlZVVcvWZLzujvhhhVszgZxZBEhYaQfSNTPExaCFReDtok9iCZ XFs/5EZxtrfCqcB1p6Ii3TxnZfM902JBGfWSJp2xKx5955weKcogfVXfpiyN1cnxPm RGz0lFEOQ259Q== 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 2181F17E1144; Wed, 4 Feb 2026 21:41:01 +0100 (CET) From: Daniel Almeida Date: Wed, 04 Feb 2026 17:40:39 -0300 Subject: [PATCH v2 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: <20260204-aref-workitem-v2-1-bec25b012d2a@collabora.com> References: <20260204-aref-workitem-v2-0-bec25b012d2a@collabora.com> In-Reply-To: <20260204-aref-workitem-v2-0-bec25b012d2a@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 , Tejun Heo , Lai Jiangshan 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 --- 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 Sat Feb 7 06:14:12 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 2E74942B75C; Wed, 4 Feb 2026 20:41: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=1770237668; cv=none; b=qu+BrlQgegcJssqRYuJe6XlQpSsx8RYRynVnVzVxHaOqylnArl2gJ8fwwm2bW5XpjL3t3TFbRTS/0d/OlPTtW7tPP8FNdD70a7Bz8drsxgx16J4cjhavDx6w03Tf0/LPox4p1gChVdlK0YkM8w8bIm/tcML8RJ+ZdrCgOy860pI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770237668; c=relaxed/simple; bh=ApvBkXicI2zoEGRrzQsJJHposj44s/SN+iBr72P8xoc=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=WCsewoYi+XSEmeieNI1ZVpbYOHWiHk2re1WvE2i1mBGdet6CiUI35O8DDg/yFFAnDAL9Y048N+AdhDMMHVCKsErocW8SzE/q7rsmQKZfQgxcEF8wQtnUb9VrV0QPAIM0na2yv2XIrTfgFIO+8zLt7KfGkbGhOb2oAFW8hCTbmU8= 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=fy1kUwfX; 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="fy1kUwfX" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1770237666; bh=ApvBkXicI2zoEGRrzQsJJHposj44s/SN+iBr72P8xoc=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=fy1kUwfXucF9asetdEhTZdZiF7CYpfsGAos4AIHK+G4XWTVyxvI1RlatDuaEtyx5l XdbHJJ8hhsajCp00kKsST0btcX8N90RZHSHzQfjhDPhEv46KkRkLpNE1nmYqlKoihA xHwlic7Z8M7wVtH90KqG3HdskrMEUF5BSvisFHW0RrXQFu9iOzQYV1GfR0mt5TIWZg ratMe9jk7X03LQEa7bQtbm9L9zACzQIpmOvrNbfkCZxDBmZHDjTdSW401cyLA2X0eL L0dVy8F/ekIyMhna6ajaLblaBsBxSxdlj68OmIIr/CcB4uU9kpkN7PR6Q2H/+RlBFQ Ph8xmOarCdXVA== 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 085CC17E1582; Wed, 4 Feb 2026 21:41:03 +0100 (CET) From: Daniel Almeida Date: Wed, 04 Feb 2026 17:40:40 -0300 Subject: [PATCH v2 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: <20260204-aref-workitem-v2-2-bec25b012d2a@collabora.com> References: <20260204-aref-workitem-v2-0-bec25b012d2a@collabora.com> In-Reply-To: <20260204-aref-workitem-v2-0-bec25b012d2a@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 , Tejun Heo , Lai Jiangshan 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 --- 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 Sat Feb 7 06:14:12 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 3EBD4436343; Wed, 4 Feb 2026 20:41:10 +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=1770237671; cv=none; b=uG4ygKbtyitqRci7J8k5tU2M58lu2zAxhCaopLniWFA1GFSmw1qjnLIg84UZn2g+gmf6oNtEApwHSg5k2L5PMv8+ESv0i5EVZ8iAitK0RXIC244wvHN/bs3AAYZnUN0d69cHKptzDvp7Qt7dYSuPX+eYXEEFwUNA27fLUYmZuPg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770237671; c=relaxed/simple; bh=o7a0hN8233hHD9BCGtRr6Gh5sxlycp6ly9Wn2+YrBFA=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=iH34g1DzVbzsbVkYbZW6r7BdlFsf8vlYHG0hpd22fh/VBrhs7mRnbibLhXGQ8TA4o6jjQcnRjank+IwID/BI/ARVkzxCTkmnfLi5g/4wYmr33raU9nFvxXGebNjs892ZA7Ja4hiB7ph2ercSjP+my7WQcrkF9v307Zzh59KJF0Q= 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=SyS1dukD; 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="SyS1dukD" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1770237669; bh=o7a0hN8233hHD9BCGtRr6Gh5sxlycp6ly9Wn2+YrBFA=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=SyS1dukDcR/c7zbhQ7vznUHuIeMeHu0yfGFL4BSrGd2Q3hNrfKx+mAtsRqMxCS6XR cr+6gdoqPOofn8e75V+HG6SM2uJ6e/N8GEF+EielAP8IzzaE6kz9EPnbstIsldr6wB acVSqw9JUsgknWUP8N6j5toRNqtoYNq8t3rfF/FzEzkDFOkc2jExVGaKmQCtl3VKy4 LbKqJB5dgN4Xjmw5zYP4V1HRXCpDwTY8iohOajQWPVJQvYPUNMr51pMU9l3qRH9dBQ 13665TqyAhg84FtxktlvgapuE4GfmmlnW1s0euPxBOyBYIRjgDOXuQFMuG2ucugJc4 pOXk3l6BA9ORw== 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 E3B1317E13D3; Wed, 4 Feb 2026 21:41:06 +0100 (CET) From: Daniel Almeida Date: Wed, 04 Feb 2026 17:40:41 -0300 Subject: [PATCH v2 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: <20260204-aref-workitem-v2-3-bec25b012d2a@collabora.com> References: <20260204-aref-workitem-v2-0-bec25b012d2a@collabora.com> In-Reply-To: <20260204-aref-workitem-v2-0-bec25b012d2a@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 , Tejun Heo , Lai Jiangshan 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 --- 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 Sat Feb 7 06:14:12 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 0873742B75C; Wed, 4 Feb 2026 20:41:13 +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=1770237674; cv=none; b=M0OCqQD6/l9sEt7jdrbTnKW0JM1+xBgnJVuXor84fMwQV8BkgYU+dnP1+kPB+FaC5nKBcj5ejKUTLW9vOHa7mgP5Hc/BlfbRdLzWk+LPKN6BizQWX5Y6+XG4TSKpkZlmGGROitSfSs0xmBLt96W3efTqGzCswp4meOuoq0Q2cbE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770237674; 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=GIoS2CJM+DggVZjCH6zP7aeKJX8SV2TkGjkN2x5u7cumVtsV9KeI/jESBGUYfL5jjq45g4JtO1TtqyKyzKSU9y3/4/lj6teXm2RcD50tEQBcGaKfR6s27XTnjxi4BThxIx6fAFK6m6pg7tag3DjK+IpFCMwwC0UOdXN4mJzI9nQ= 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=OjS9kYmB; 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="OjS9kYmB" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1770237672; bh=dd+gf/jKyogh1Q1ivowg9YoTCKDzuqKUdBLw/sUwIr4=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=OjS9kYmBRpyT8TTi5bVVs9RXwUpuCU+j1eih+1QuHUJOJkwYQOib0vJCgOY9+bFV0 SGLXVt+YsE/teFXEUv01QA7tgROg/TKPtqr+wLFt8QNJ6LwrQG5kN/E9FhHq9JadhX id8nSX9/aBFvPAICrYIiO5q8+0I3CakyAbZCYpUevIOoSA3eXL5Qjie79jsNQG5Nyo KjIhHt3RK2Ln5MWtsqifo/lROeZKpDp7ZXqq6xRdcYep4meNQwff3gCHgO0xGkQ8YG ySH5m1GWf3Zpb0q8DhwuEm2cji4sDomK1sWyq210WmWhhp4B7WMd9etRh++2oSMnxv FoS7AHR9qrBmw== 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 CAB3C17E14F5; Wed, 4 Feb 2026 21:41:09 +0100 (CET) From: Daniel Almeida Date: Wed, 04 Feb 2026 17:40:42 -0300 Subject: [PATCH v2 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: <20260204-aref-workitem-v2-4-bec25b012d2a@collabora.com> References: <20260204-aref-workitem-v2-0-bec25b012d2a@collabora.com> In-Reply-To: <20260204-aref-workitem-v2-0-bec25b012d2a@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 , Tejun Heo , Lai Jiangshan 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 --- 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