Messages in this thread | | | From | H Hartley Sweeten <> | Date | Tue, 29 Jan 2013 17:56:46 -0600 | Subject | RE: [Q]staging/comedi: Considation of *_find_boardinfo possible? |
| |
On Tuesday, January 29, 2013 4:42 PM, Peter Hüwe wrote: > Hi, > > while analyzing the comedi drivers, I noticed that quite a lot of them use a > more or less similar find_boardinfo function.
<snip>
> The names and the exact implementation differ slightly, but in most cases it > boils down to: > unsigned int i; > > for (i = 0; i < ARRAY_SIZE(__BOARD_ARRAY__); i++) > if (pcidev->device == __BOARD_ARRAY__[i].device_id) > return &__BOARD_ARRAY__[i]; > return NULL; > > unfortunately the __BOARD_ARRAY__ is always of a different type (but all > contain the device_id field) and size. > > > ---> is there a way to consolidate these functions into one function (which > can operate on the different types) ? It's almost a bit like 'templates'. > Maybe with some gcc extensions or kernel magic functions ? > > I already thought about passing a void pointer to the __BOARD_ARRAY__ and the > size of one element of the __BOARD_ARRAY__ and doing pointer calculations - > but I guess there must be a better way. > > Or is the only option to write a macro ?
As you noticed, the problem is the driver specific definition of the struct used to hold the boardinfo.
In drivers.c, the comedi_recognize() function actually access the boardinfo in order to support the COMEDI_DEVCONFIG ioctl. There is a comment above it giving a description of how it works.
There might be a way to do this in a generic way. The problem is that the drivers use different names for "common" information and the data is packed in the structs differently so accessing it generically is a bit difficult, if not impossible.
I have been trying to remove as much of this boardinfo stuff from the drivers as possible. For now I think the current implementation is fairly clean.
For the PnP bus drivers that use the auto_attach mechanism I have some ideas to get rid of the find_boardinfo functions but I need to work out the kinks first.
Please wait on "fixing" any of this until a good solution is worked out.
Thanks, Hartley
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |