Re: [PATCH REF 24/24] gpu: drm: tyr: use HRT lifetime for IoMem

[Danilo Krummrich]

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::drvdata_borrow()?

No, this method is unsafe and intended for busses only, drivers should never use
it directly.

> Or is the expectation that drm::Driver should also have a lifetime-parameterized
> 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 device
    resources through the separate registration data bound to the registration's
    lifetime without Devres indirection.

This becomes possible as I also have patches that protect DRM IOCTLs through the
drm::UnbindGuard (which is just drm_dev_enter() and drm_dev_exit()). Together
with drm_dev_unplug() being called when the drm::Registration is dropped all
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 the
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 areas,
> (firmware, MMU/address-space management, and IRQ handling)  and it does register
> accesses directly. See what we're trying to do:
> https://lore.kernel.org/rust-for-linux/20260424-b4-fw-boot-v4-v4-0-a5d91050789d@xxxxxxxxxxxxx/

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 refactor
> 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 work.

No worries, that'd be the exact opposite of what we want to achieve. :)