> -----Original Message----- > From: Greg KH [mailto:greg@xxxxxxxxx] > Sent: Wednesday, August 24, 2011 4:12 PM > To: KY Srinivasan > Cc: gregkh@xxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > devel@xxxxxxxxxxxxxxxxxxxxxx; virtualization@xxxxxxxxxxxxxx; Haiyang Zhang > Subject: Re: [PATCH 003/117] Staging: hv: Add struct hv_vmbus_device_id to > mod_devicetable.h > > On Wed, Aug 24, 2011 at 04:46:11PM +0000, KY Srinivasan wrote: > > > > > > > -----Original Message----- > > > From: Greg KH [mailto:greg@xxxxxxxxx] > > > Sent: Tuesday, August 23, 2011 10:59 PM > > > To: KY Srinivasan > > > Cc: gregkh@xxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > > > devel@xxxxxxxxxxxxxxxxxxxxxx; virtualization@xxxxxxxxxxxxxx; Haiyang Zhang > > > Subject: Re: [PATCH 003/117] Staging: hv: Add struct hv_vmbus_device_id to > > > mod_devicetable.h > > > > > > On Wed, Aug 24, 2011 at 12:44:38AM +0000, KY Srinivasan wrote: > > > > > > > > > > > > > -----Original Message----- > > > > > From: Greg KH [mailto:greg@xxxxxxxxx] > > > > > Sent: Tuesday, August 23, 2011 6:42 PM > > > > > To: KY Srinivasan > > > > > Cc: gregkh@xxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > > > > > devel@xxxxxxxxxxxxxxxxxxxxxx; virtualization@xxxxxxxxxxxxxx; Haiyang Zhang > > > > > Subject: Re: [PATCH 003/117] Staging: hv: Add struct hv_vmbus_device_id > to > > > > > mod_devicetable.h > > > > > > > > > > On Fri, Jul 15, 2011 at 10:45:51AM -0700, K. Y. Srinivasan wrote: > > > > > > In preparation for implementing vmbus aliases for auto-loading > > > > > > Hyper-V drivers, define vmbus specific device ID. > > > > > > > > > > > > Signed-off-by: K. Y. Srinivasan <kys@xxxxxxxxxxxxx> > > > > > > Signed-off-by: Haiyang Zhang <haiyangz@xxxxxxxxxxxxx> > > > > > > --- > > > > > > include/linux/mod_devicetable.h | 7 +++++++ > > > > > > 1 files changed, 7 insertions(+), 0 deletions(-) > > > > > > > > > > > > diff --git a/include/linux/mod_devicetable.h > > > > > b/include/linux/mod_devicetable.h > > > > > > index ae28e93..5a12377 100644 > > > > > > --- a/include/linux/mod_devicetable.h > > > > > > +++ b/include/linux/mod_devicetable.h > > > > > > @@ -405,6 +405,13 @@ struct virtio_device_id { > > > > > > }; > > > > > > #define VIRTIO_DEV_ANY_ID 0xffffffff > > > > > > > > > > > > +/* > > > > > > + * For Hyper-V devices we use the device guid as the id. > > > > > > + */ > > > > > > +struct hv_vmbus_device_id { > > > > > > + __u8 guid[16]; > > > > > > +}; > > > > > > > > > > Why do you not need a driver_data pointer here? Are you sure you aren't > > > > > ever going to need it in the future? Hint, I think you will... > > > > > > > > I am not sure I am following you here; the guid is the device ID and it is > > > > guaranteed to remain the same. What is the driver _data pointer here > > > > you are referring to here. While some device id have the _data pointer, > > > > there are others that don't - for instance struct virtio_device_id. In > > > > our case, I am not sure how I would use this private pointer. > > > > > > You use it like all other drivers use it, only if needed. > > > > Fair enough; the point is I am not sure how I would use it. > > > > > > > > Hint, I think you need to use it in your hv_utils driver, it would > > > reduce the size of your code and simplify your logic. > > > > Could you expand on this. Currently the util driver handles a bunch > > services that have their own guids - and these have been included > > in the idtable. How would having the pointer simplify this code. > > 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! 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. So, if it is ok with you, I will not add driver_data pointer since I will not be using it. > > > 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. Regards, K. Y _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
