On Wed, Apr 23, 2014 at 09:17:16AM +0200, Thierry Reding wrote: > On Tue, Apr 22, 2014 at 05:48:07PM +0200, Daniel Vetter wrote: > > On Tue, Apr 22, 2014 at 05:09:32PM +0200, Thierry Reding wrote: > > > From: Thierry Reding <treding@xxxxxxxxxx> > > > > > > Add a helper function that allows drivers to statically set the unique > > > name of the device. This will allow platform and USB drivers to get rid > > > of their DRM bus implementations and directly use drm_dev_alloc() and > > > drm_dev_register(). > > > > > > Signed-off-by: Thierry Reding <treding@xxxxxxxxxx> > > > --- > > > drivers/gpu/drm/drm_ioctl.c | 37 +++++++++++++++++++++++++++++++------ > > > drivers/gpu/drm/drm_stub.c | 1 + > > > include/drm/drmP.h | 3 +++ > > > 3 files changed, 35 insertions(+), 6 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c > > > index 2dd3a6d8382b..371db3bef60c 100644 > > > --- a/drivers/gpu/drm/drm_ioctl.c > > > +++ b/drivers/gpu/drm/drm_ioctl.c > > > @@ -42,6 +42,20 @@ > > > #include <asm/mtrr.h> > > > #endif > > > > > > +int drm_set_unique(struct drm_device *dev, const char *fmt, ...) > > > > Can you please add a bit of kerneldoc for this? drm_ioctl.c isn't yet > > pulled into the drm reference docbook, but better to have it there > > already. > > On second thought, wouldn't this be better located in drm_stub.c? It > isn't really related to the IOCTL code except that one of the IOCTLs now > uses the information set by this function. Logically I think it belongs > with the likes of drm_dev_alloc() and drm_dev_register(). Yeah makes sense. Tbh the entire split-up of these core drm functions is still a bit messy, so I don't mind if it's a bit inconsistent really. We can do the suffling when someone bothers with the kerneldoc for all of them and pulls it into the drm docbook. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
