[PATCH] drm: Register the debugfs interfaces after loading the driver

Chris Wilson chris at chris-wilson.co.uk
Fri May 27 07:44:52 UTC 2016


On Fri, May 27, 2016 at 08:47:48AM +0200, Daniel Vetter wrote:
> On Thu, May 26, 2016 at 02:06:13PM +0100, Chris Wilson wrote:
> > On Thu, May 26, 2016 at 01:35:18PM +0100, Chris Wilson wrote:
> > > In order to give the driver the chance to initialise the data structures
> > > that will be exposed through debugfs, perform driver->load() before
> > > registering the debugfs entries. (Otherwise it may be possible for
> > > userspace to cause an oops through the debugfs interfaces.) As the
> > > driver load is now before debugfs registration, make the registration
> > > non-fatal (as it simply prevents us exposing an optional debug facility
> > > and not hard ABI).
> > 
> > The alternative here would be for i915.ko to stop registering a
> > driver->debugfs_init and do it as part of its registration phase (like
> > sysfs).
> 
> I think the right fix would be to demidlayer i915 and stop using the
> ->load callback. Then we do have the right ordering, since debugfs setup
> is done as part of the register phase.

We would need to take control from drm_get_pci_dev() if we want to
publish the device nodes during our registration phase (which we do).
One way would be to opencode drm_get_pci_dev() and do the driver setup
entirely ourselves from i915_pci_probe() then register.

Seems reasonable, biggest challenge will be to make sure we aren't
dependent on the minors before registration (but that shouldn't be too
much of a challenge, at worst it means we have bad ordering to fixup).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the dri-devel mailing list