Re: [PATCH v5 5/7] revocable: Add fops replacement

[Danilo Krummrich <dakr@kernel.org>]

On 10/17/25 6:07 PM, Tzung-Bi Shih wrote:
> Imagining:
> - Driver X provides the res1.
> - Driver Y provides the res2.
> - Driver Z provides the chardev /dev/zzz.  The file operations use res1
>   and res2.
> - A userspace program opened /dev/zzz.
> 
> In the approach, what is .remove() of driver X supposed to do when driver X
> is unbinding (e.g. due to device unplug)?

There are use-cases for revocable, but this example is a bit too generic:

Drivers don't just share device resources with other random drivers, they
usually have a defined relationship through a bus.

For instance, if you have a driver on the platform bus and another driver
connected through the auxiliary bus, there is a defined lifetime: The auxiliary
device has to be unbound before its parent device.

This means that as long as you are in a scope where your auxiliary device is
bound, it is safe to use a device resource from that parent without further checks.

The goal should always be to proof to be in such a scope when accessing device
resources (in Rust we can let the compiler ensure this at compile time :).

However, there are rare (yet valid) cases where such a scope can't be
guaranteed. DRM has such cases, and, unfortunately, MISC device seems to be
another one.

I know the reasons why DRM has to have this design, I'm not sure about MISC
device though. Unless there's a good reason, I think MISC device should be
"fenced" instead.