On Fri, May 30, 2014 at 6:49 AM, Daniel Vetter <daniel@xxxxxxxx> wrote: > On Fri, May 30, 2014 at 12:46 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: >> On Fri, May 30, 2014 at 12:37 AM, Rob Clark <robdclark@xxxxxxxxx> 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@xxxxxxxxx> >> >> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
