Re: [PATCH v3 00/17] drm/panthor: Fix the unplug logic

["Danilo Krummrich" <dakr@kernel.org>]

On Thu Aug 13, 2026 at 1:23 PM CEST, Boris Brezillon wrote:
> Just a note I forgot to add to my cover letter. I've already spent way
> more time than I wanted on this, not just because Sashiko keeps finding
> new issues at each of my attempt, but also because the whole idea of
> pretending a device on a platform bus is unplugged and can't harm us is
> doomed. This is not an hot-pluggable bus, and the device is still there,
> so, unless we can be absolutely sure it's inactive (which a RESET can
> provide, but RESETs are fallible) we just have two options:

I probably need a bit more context about which exact problem(s) you are trying
to solve.

> 1. prevent the device from going away until we managed to properly
>    shutdown the GPU

I'm not exactly sure what you mean with "device going away". If you mean
"prevent the device from being unbound from the driver" this is essentially what
you do by waiting for the completion of some HW teardown operation in remove().

In general, the implementation of remove() should ensure that on the one hand
the device it torn down (or reset), so it does not mess with system resources
anymore (e.g. attempt to do any DMA transfers) and behaves correctly on a
subsequent probe of this or another driver.

And on the other hand, the driver must release all device assoicated resources,
such as DMA mappings, IRQs, I/O memory mappings, etc. and it should also ensure
that no more driver code is reachable from any asynchronous paths, such as
workqueues, IOCTLs, timers, etc.

The latter obviously also depends on the subsystem and whether the lifetime of
userspace structurs and their associated driver private data is cleanly
decoupled (e.g. struct drm_file and ->driver_priv).

Since you also mention hot-unplug; those rules are universial regardless of
whether remove is triggered by a hot-unplug event or because the driver is
unbound for a different reason. The DRM API is a bit misleading about this,
because with drm_dev_unregister() there is no way to prevent DRM IOCTLs from
running after remove(), which wrongly suggests that this is not a potential
issue.

Not summarizing this because I think you are not aware already, but it may
provide a good entry point for you to point out where exactly things are getting
tricky.

> 2. make sure all resources the HW might have its hands on at the time
>    the failure of RESET in the unplug path happened are leaked

I'm not sure what you mean by this. But it suggests that the problem you try to
deal with is a misbehaving device that fails to reset?

Also, what do you mean with leaking the device resources?