Re: [PATCH 0/8] Device: generic accessors for drvdata + Driver::unbind()

["Alexandre Courbot" <acourbot@nvidia.com>]

On Tue Jul 1, 2025 at 7:40 PM JST, Danilo Krummrich wrote:
>> > This makes it inefficient (but not impossible) to access device
>> > resources, e.g. to write device registers, and impossible to call device
>> > methods, which are only accessible under the Core device context.
>> > 
>> > In order to solve this, add an additional callback for (1), which we
>> > call unbind().
>> > 
>> > The reason for calling it unbind() is that, unlike remove(), it is *only*
>> > meant to be used to perform teardown operations on the device (1), but
>> > *not* to release resources (2).
>> 
>> Ick.  I get the idea, but unbind() is going to get confusing fast.
>> Determining what is, and is not, a "resource" is going to be hard over
>> time.  In fact, how would you define it?  :)
>
> I think the definition is simple: All teardown operations a driver needs a
> &Device<Core> for go into unbind().
>
> Whereas drop() really only is the destructor of the driver's private data.
>
>> Is "teardown" only allowed to write to resources, but not free them?
>
> "Teardown" is everything that involves interaction with the device when the
> driver is unbound.
>
> However, we can't free things there, that happens in the automatically when the
> destructor of the driver's private data is called, i.e. in drop().

Can't we somehow make a (renamed) `unbind` receive full ownership of the
driver's private data, such that it will be freed (and its `drop`
implementation called) before `unbind` returns? Or do we necessarily
need to free that data later?