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
