[PATCH] drm/sysfs: fix hotplug regression since lifetime changes

Daniel Vetter daniel at ffwll.ch
Thu Nov 21 02:20:02 PST 2013


On Thu, Nov 21, 2013 at 07:25:39PM +1000, Dave Airlie wrote:
> On Thu, Nov 21, 2013 at 7:22 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
> > On Thu, Nov 21, 2013 at 11:51:04AM +1000, Dave Airlie wrote:
> >> 5bdebb183c9702a8c57a01dff09337be3de337a6 changed the lifetimes, but it
> >> also meant we no longer set the device_type field properly, so the
> >> hotplug events in userspace weren't fully formed enough for drivers to care.
> >>
> >> Reported-by: Jesse Barnes <jbarnes at virtuosugeek.org>
> >> Signed-off-by: Dave Airlie <airlied at redhat.com>
> >> ---
> >>  drivers/gpu/drm/drm_sysfs.c | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> >> index 1a35ea5..c6a3902 100644
> >> --- a/drivers/gpu/drm/drm_sysfs.c
> >> +++ b/drivers/gpu/drm/drm_sysfs.c
> >> @@ -516,6 +516,7 @@ int drm_sysfs_device_add(struct drm_minor *minor)
> >>               DRM_ERROR("device create failed %ld\n", PTR_ERR(minor->kdev));
> >>               return PTR_ERR(minor->kdev);
> >>       }
> >> +     minor->kdev->type = &drm_sysfs_device_minor;
> >
> > Isn't this one of the sysfs races Greg is fighting against? At least from
> > a cursor read through the driver core it looks like we'd better set the
> > dev->type before we set it up with device_create().
> 
> Possibly but how can we do that? since minor->kdev is something we
> just created 2 lines earlier
> unless there is another create function I should be calling, I don't
> see a device_create_with_type.
> >
> > Cc'ing Greg for insight.
> >
> > Aside: I wonder whether we could get rid of our drm_minor type and use it
> > for something more useful like the render node vs legacy node split ...
> 
> Its ABI now. all the userspace drivers need it in the uevents for
> hotplug to keep working.

Yeah I know that the drm_minor is abi now on legacy node. More thought of
a drm_render type for the render nodes. Could help with finding them
through udev (e.g. for headless usage in transcode jobs or for opencl).

I think we should waste a few braincycles on this before making
rendernodes official.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


More information about the dri-devel mailing list