On Wed, Aug 24, 2011 at 09:51:00PM +0000, KY Srinivasan wrote: > > It would allow you, in your probe function, to do something different > > depending on the guid that the probe function was matching on. So you > > would not have to check the guid again to do that, just use the data > > pointed in that void pointer and away you go. > > > > As an example, look at drivers/usb/class/cdc-acm.c, the acm_ids[] > > variable which uses the driver_info field to contain a quirk for the > > device. > > Ok; this makes sense. But I currently don't have any quirks to support! That was just an example. > The util driver is not even a driver in the true sense. I made it a driver and > added the probe function just to support auto-loading with the vmbus ID space > that I am trying to implement here - the probe function does nothing. As you can tell, I'm trying to say that is wrong :) the hv_util.c driver should have a pointer in each of the driver_info that describes what it is, and then in the probe function, you use that to hook up the correct things needed. None of this hard-coded mess like you currently have. Trust me, you want that pointer, put it in, and if you never use it, I'll buy you a beer. But if I send you a patch using it, well... > > > I looked at the usage of this in PCI and it appears to be for supporting > > > dynamic IDs for existing drivers. > > > > No, that's exactly wrong. dynamic ids play havoc with this pointer, > > making some drivers not be able to handle dynamic ids because they rely > > on it for some driver-specific information to be passed in it, which > > dynamic ids can not handle. > > > > Oh, have you remembered to turn off dynamic ids for these devices? Or > > do you support them properly? > > I don't support dynamic IDs. What would I need to do to turn it off. Ah, nevermind, that is something that busses add in their core if they want it. I added it for PCI and USB, maybe I should move that to the driver core so that others can get it automatically one of these days... thanks, greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel