Re: [PATCH v2 2/4] rust: drm: dispatch work items to the private data

[Danilo Krummrich]

On Wed Feb 4, 2026 at 9:40 PM CET, Daniel Almeida wrote:
> This implementation dispatches any work enqueued on ARef<drm::Device<T>> to
> its driver-provided handler. It does so by building upon the newly-added
> ARef<T> 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<drm::Device<T>>
> 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<DriverData>,
> }

IIUC, this is how it's supposed to be used:

	#[pin_data]
	struct MyData {
	    #[pin]
	    work: Work<drm::Device<MyDriver>>,
	    value: u32,
	}
	
	impl_has_work! {
	    impl HasWork<drm::Device<MyDriver>> for MyData { self.work }
	}
	
	impl WorkItem for MyData {
	    type Pointer = ARef<drm::Device<MyDriver>>;
	
	    fn run(dev: ARef<drm::Device<MyDriver>>) {
	        dev_info!(dev, "value = {}\n", dev.value);
	    }
	}

The reason the WorkItem is implemented for MyData, rather than
drm::Device<MyDriver> (which would be a bit more straight forward) is the orphan
rule, I assume.

Now, the whole purpose of this is that a driver can implement WorkItem for
MyData without needing an additional struct (and allocation), such as:

	#[pin_data]
	struct MyWork {
	    #[pin]
	    work: Work<Self>,
	    dev: drm::Device<MyDriver>,
	}

How is this supposed to be done when you want multiple different implementations
of WorkItem that have a drm::Device<MyDriver> as payload?

Fall back to various struct MyWork? Add in an "artificial" type state for MyData
with some phantom data, so you can implement HasWork for MyData<Work0>,
MyData<Work1>, etc.?