[PATCH] drm: move debugfs init after dev->load()

[Rob Clark]

On Fri, May 30, 2014 at 6:49 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Fri, May 30, 2014 at 12:46 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
>> On Fri, May 30, 2014 at 12:37 AM, Rob Clark <robdclark at gmail.com> wrote:
>>> Avoids ugly hacks in drivers debugfs code, if it depends on
>>> dev->dev_private having already been initialized.
>>>
>>> Signed-off-by: Rob Clark <robdclark at gmail.com>
>>
>> So what I had in mind:
>> - stop using drm_platform_init, instead roll your own copy of
>> drm_get_platform_dev
>> - don't driver->bus, instead use Thierry's set_busid interface
>>
>> Then as a second step you can stop calling your ->load callback and
>> instead insert stuff between drm_dev_alloc and drm_dev_register. We
>> have pretty much the same problem with sysfs as with debugfs, so your
>> patch here doesn't really solve all that much - ->load should be
>> called mostly before drm_dev_register sets up all the userspace
>> interfaces.
>>
>> Long term I want to phase-out ->load except for legacy non-kms drivers.
>
> Also this is debugfs. If someone races debugfs access with driver load
> it will blow up pretty much everywhere in drm drivers (because of the
> wrong init order). Imo there's absolutely no need for duct-tape like
> this, nor for band-aids in drivers. At least in i915 we have 0
> dev_priv != NULL checks.

It is because some of the debugfs files need to "register" w/ rest of
driver.. ie, 'priv->perf = perf' type stuff.  Which doesn't work so
well in debugfs_init if priv is still null.  Changing the order lets
this work.  I can hack around this by deferring some initialization
until first open.  But that seemed ugly.

I was kinda hoping to be able to merge this to get rid of those hacks,
in a slightly less intrusive way that what you propose.  But if that
breaks tegradrm, then I'll just hack around this in my debugfs code
for now.

BR,
-R

> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch