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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
