[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ADE657CA350FB648AAC2C43247A983F00207A707B3C8@AUSP01VMBX24.collaborationhost.net>
Date: Tue, 29 Jan 2013 17:56:46 -0600
From: H Hartley Sweeten <hartleys@...ionengravers.com>
To: Peter Hüwe <PeterHuewe@....de>,
Ian Abbott <abbotti@....co.uk>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
ian Abbott <ian.abbott@....co.uk>,
Dan Carpenter <dan.carpenter@...cle.com>,
"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists