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
