From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 B6CAA30B521; Tue, 5 May 2026 23:12:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778022732; cv=none; b=sbvbl01GeWIo+OzS0fpwIXU2mOJPQ+Rq4A5NltOe5ET/cZAfvccJ+M0BUcCVysCnkBPZa1AD3rVMjHTtqhOdU2Y+CC39a0NE9/D/Chwo3U0cFTrcs03gY947sBw5nndp9kTo1KbJKttPdl63nsLtEw3P5SrqyTKkOuGr5tbH4Jo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778022732; c=relaxed/simple; bh=KphMG9jiVB2OJLAMUTdfTkFkyrHOjO80/tesl+RVVT4=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:To:From:Subject: References:In-Reply-To; b=bS8n1hb04G6W9VEqvfoL/Z8ltgsNKypqS3HtbbbuVQaYybnpTS2jDmy0hG96dZpXLwsAJDhWTfsMkvuc1kBnh5KukRY1+ZYdBlWoYN0S6v51UZjLrnGld/ymblwTy8WgpCU/M0Y2N8QDCZX+DKOvfV0XRpSZxyCmNWE5AO5yUv0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nLeKvUQ4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nLeKvUQ4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BEA06C2BCB4; Tue, 5 May 2026 23:12:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778022732; bh=KphMG9jiVB2OJLAMUTdfTkFkyrHOjO80/tesl+RVVT4=; h=Date:Cc:To:From:Subject:References:In-Reply-To:From; b=nLeKvUQ4j8NIWpLtl1VhRpd7s/lcvYTFSFEoiUp9vRAz62tcyYHXsUPNFhXmV8TDe G7q956NMUdSYHXKkOdo7is74GUwJULIsEK+a275FEgVuiTLveWpR+rkehdw8gnQCkA fdv/djTHNVNdosNV21qzbhndSyB70D+tz8zTT/pBV5zxlP0v+2Oy8DEiMMlMfrROKZ euUccuMQeFMdz5SfhBooRT+NpOTI5VCf0IgX/95pYP6Niz6/2x/GK0pgJ8uKzEsJlo 8u0Ic+b5QLdBuIkGDKm1GJqzejs8qnbsZZdSel9xT3nYWTsum3Xmk2jWyIWL+nm0BW gJlAK9RKF9MMQ== Precedence: bulk X-Mailing-List: driver-core@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 06 May 2026 01:12:05 +0200 Message-Id: Cc: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , To: "Deborah Brouwer" From: "Danilo Krummrich" Subject: Re: [PATCH REF 24/24] gpu: drm: tyr: use HRT lifetime for IoMem References: <20260427221155.2144848-1-dakr@kernel.org> <20260427221155.2144848-25-dakr@kernel.org> In-Reply-To: On Wed May 6, 2026 at 12:56 AM CEST, Deborah Brouwer wrote: > Is the intended model that DRM drivers keep lifetime-bound resources such= as > IoMem<'bound> only in platform drvdata and access them via Device::drvdat= a_borrow()? No, this method is unsafe and intended for busses only, drivers should neve= r use it directly. > Or is the expectation that drm::Driver should also have a lifetime-parame= terized > Data associated type? Exactly, the plan is to have lifetime-parameterized private data on the drm::Registration, which is available in IOCTLs. The cover letter mentions = that briefly: A follow-up series extends this to class device registrations, starting= with DRM, so that class device callbacks (IOCTLs, etc.) can safely access de= vice resources through the separate registration data bound to the registrat= ion's lifetime without Devres indirection. This becomes possible as I also have patches that protect DRM IOCTLs throug= h the drm::UnbindGuard (which is just drm_dev_enter() and drm_dev_exit()). Togeth= er with drm_dev_unplug() being called when the drm::Registration is dropped al= l IOCTLs are guaranteed to provide a bound scope of the underlying bus device= and hence the device resources in the DRM registration data availble through th= e IOCTLs. I have all those patches ready and I plan to send them this week. > The reason I ask is that Tyr currently stores an MMIO handle in several a= reas, > (firmware, MMU/address-space management, and IRQ handling) and it does r= egister > accesses directly. See what we're trying to do: > https://lore.kernel.org/rust-for-linux/20260424-b4-fw-boot-v4-v4-0-a5d910= 50789d@collabora.com/ Note that you are not blocked by this, you can always move IoMem<'_> into a Devres through IoMem::into_devres() and use it without lifetime bounds. But= of course the goal is to make this unnecessary. > Moving IoMem<'bound> only into platform drvdata would require a big refac= tor > to thread &IoMem<'_> through those paths or fetch it from drvdata at each= hardware > access site. So, I wanted to clarify the plan first before I start this w= ork. No worries, that'd be the exact opposite of what we want to achieve. :)