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

[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).

Regards,
Christian.

>
> Thanks,
> Andi