[PATCH 2/5] drm/debugfs: disallow debugfs access when device isn't registered

[Christian König]

Am 29.08.23 um 14:31 schrieb Christian König:
> Am 29.08.23 um 13:38 schrieb Andi Shyti:
>>>>> During device bringup it might be that we can't access the debugfs 
>>>>> files.
>>>>> Return -ENODEV until the registration is completed on access.
>>>> just wondering, if the device is not registered, how do we get
>>>> there?
>>> The workflow is:
>>> 1. Creation (DRM)
>>> 2. Initialization (Driver)
>>> 3. Registration (DRM)
>>> ...
>>> 4. Unregistration (DRM)
>>> 5. Deinitialization (Driver)
>>> 6. Destruction (DRM)
>>>
>>> It is possible that debugfs files are created during driver 
>>> initialization,
>>> but Daniel insisted that they should not be accessible until the
>>> registration is done (which makes the other UAPI accessible as well).
>> makes sense, but then why not -EAGAIN, or -EBUSY?
>
> Good question.
>
> I think the main use case for this is between 4 and 6. E.g. a device 
> which is hot removed and now in the process of being torn down.
>
> In this situation we might still have references from userspace 
> (memory mapping etc...), so the drm file and with it the debugfs 
> directory is still there but the physical device is gone. For the 
> IOCTL UAPI we then also return -ENODEV as well, so this makes sense.
>
> The time between 1 and 3 is interesting as well, but here it's more 
> like we couldn't get the device initialized and are now stuck. This 
> happens sometimes during early hardware bringup and I still disagree 
> with Daniel that we should block that (well on the other hand it's 
> trivial for a developer to comment those checks out).

Could I get an rb for this series or at least this patch from you?

I would really like to push that now as long as neither Dave nor Daniel 
have any objections (last time I checked the Intel CI was happy as well, 
but we could re-submit that once more of course).

Thanks,
Christian.

>
> Regards,
> Christian.
>
>>
>> Thanks,
>> Andi
>