Re: [questions] dmesg: Non-NULL drvdata on register

[Janne Grunau <j@jannau.net>]

On Mon, May 04, 2009 at 03:03:40PM +0200, Hans Verkuil wrote:
> 
> > Not so many time ago i noticed such line in dmesg:
> >
> > radio-mr800 2-1:1.0: Non-NULL drvdata on register
> >
> > Quick review showed that it appears in usb_amradio_probe fucntions. Then
> > i found such code in v4l2_device_register() function (v4l2-device.c
> > file):
> >
> > /* Set name to driver name + device name if it is empty. */
> >         if (!v4l2_dev->name[0])
> >                 snprintf(v4l2_dev->name, sizeof(v4l2_dev->name), "%s %
> > s",
> >                         dev->driver->name, dev_name(dev));
> >         if (dev_get_drvdata(dev))
> >                 v4l2_warn(v4l2_dev, "Non-NULL drvdata on register\n");
> >         dev_set_drvdata(dev, v4l2_dev);
> >         return 0;
> >
> > The questions is - should i deal with this warning in dmesg? Probably
> > the order of callbacks in radio-mr800 probe function is incorrect.
> 
> I (or you :-) should look into this: I think the usb subsystem is calling
> dev_set_drvdata as well, so we could have a clash here.

I don't think so. But probably all USB drivers call usb_set_intfdata
(just a wrapper around dev_set_drvdata). Most (media) drivers use it to
get driver struct back on a disconnect.

My change to use usb interface's struct device for v4l2_device_register
caused an oops on disconnect for em28xx based devices. Other drivers
(hdpvr, au0828) fortunately call usb_set_intfdata after calling
v4l2_device_register.

I'm not sure how to resolve this. USB drivers need for the disconnect a
way of of getting their private driver struct. We could add a data field
to v4l2_device. A couple of drivers seems to be already based on the
assumption that dev_get_drvdata(parent.dev) returns a v4l2_device.

Janne