From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 41139FEE4F4 for ; Sat, 28 Feb 2026 18:40:33 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 86F3C10E05A; Sat, 28 Feb 2026 18:40:32 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="j/InzrVo"; dkim-atps=neutral Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by gabe.freedesktop.org (Postfix) with ESMTPS id 856F110E05A for ; Sat, 28 Feb 2026 18:40:31 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id A332F60008; Sat, 28 Feb 2026 18:40:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 51F95C19423; Sat, 28 Feb 2026 18:40:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772304030; bh=1MGoOeWO4a7jzpvdquCXe6JL9LK4o55NoxWsra1wzgs=; h=Date:Cc:To:From:Subject:References:In-Reply-To:From; b=j/InzrVodnQsLneccidK60stBfW++8hhtyv7LFiOjfZZ9tCIY56BLd/YAo1sX6ZFg zqrgiEZjHvKNc+JsvHiDprdj44UmhpbHicQ0n0/xe2tbwDuHca1uMyL/hKq7eXaj52 HV/H4PyPgAMege1M57xWBvGHUtGjzYn+IHv5uir1LCtwNsVxtOpOTUgXJHBUyLohpf b7kGQCYIVLnQgEegoI9Kbm4rK55hQ53PUoPSmWau+v6va61MAcYtjNxiUpECBT96m3 WY8VzpQdCmbY1JIieTkbsnyjfKVGMMr0QB+3xfNXlO6VvDiAvwIbKf/qNL8NjYW1LO 3GmoYwJLkxnHw== Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Sat, 28 Feb 2026 19:40:26 +0100 Message-Id: Cc: "Miguel Ojeda" , "Boqun Feng" , "Gary Guo" , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , "Benno Lossin" , "Andreas Hindborg" , "Alice Ryhl" , "Trevor Gross" , "David Airlie" , "Simona Vetter" , "Tejun Heo" , "Lai Jiangshan" , , , To: "Daniel Almeida" From: "Danilo Krummrich" Subject: Re: [PATCH v2 2/4] rust: drm: dispatch work items to the private data References: <20260204-aref-workitem-v2-0-bec25b012d2a@collabora.com> <20260204-aref-workitem-v2-2-bec25b012d2a@collabora.com> In-Reply-To: <20260204-aref-workitem-v2-2-bec25b012d2a@collabora.com> X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed Feb 4, 2026 at 9:40 PM CET, Daniel Almeida wrote: > 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, > } IIUC, this is how it's supposed to be used: #[pin_data] struct MyData { #[pin] work: Work>, value: u32, } =09 impl_has_work! { impl HasWork> for MyData { self.work } } =09 impl WorkItem for MyData { type Pointer =3D ARef>; =09 fn run(dev: ARef>) { dev_info!(dev, "value =3D {}\n", dev.value); } } The reason the WorkItem is implemented for MyData, rather than drm::Device (which would be a bit more straight forward) is the o= rphan 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, dev: drm::Device, } How is this supposed to be done when you want multiple different implementa= tions of WorkItem that have a drm::Device as payload? Fall back to various struct MyWork? Add in an "artificial" type state for M= yData with some phantom data, so you can implement HasWork for MyData, MyData, etc.?