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

[Andi Shyti]

Hi Christian,

> > > > > > 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 took some time thinking of possible scenarios and use cases...

What I was thinking, indeed, was scenario 1-3 and I also think
that blocking is not the right thing. In any case the probability
that this might happen is too low, not just in early bring up but
also when modprobing where a little timer would do.

For both cases, 1-3 and 4-6, I believe that -EBUSY would be
better because the device is indeed busy in both cases.

Anyway it's a tiny detail we are talking about here :)

Reviewed-by: Andi Shyti <andi.shyti at linux.intel.com> 

Andi