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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
