[PATCH 09/49] staging: comedi: adv_pci1710: use the pci id_table 'driver_data'

Ian Abbott abbotti at mev.co.uk
Wed Mar 6 11:25:44 UTC 2013


On 2013-03-06 07:24, Dan Carpenter wrote:
> On Tue, Mar 05, 2013 at 09:59:29AM -0700, H Hartley Sweeten wrote:
>> Create an enum to the boardinfo and pass that enum in the pci_driver
>> id_table as the driver_data.
>>
>> Change the macro used to fill in the device table from PCI_DEVICE() to
>> PCI_VDEVICE(). This allows passing the enum as the next field.
>>
>> This allows removing the 'device_id' data from the boardinfo as well
>> the search function that was used to locate the boardinfo for the
>> PCI device.
>>
>> The pci1710 and pci1710hg boards have the same vendor/device id so
>> it is impossible to determine which board is actually detected. The
>> boardinfo for the pci1710hg is identical to the pci1710 other than
>> the analog input range information. Remove the pci1710hg information
>> and #if out the range tables for that device with the define
>> USE_PCI1710HG_RANGE. Modify the pci1710 boardinfo accordingly to
>> use the same define to determine which range table to use. Until a
>> better solution is worked out, this will allow the driver to be
>> compiled to support the pci1710 (default) or pci1710hg.
>
> This patch doesn't introduce any bugs that weren't there in the
> original and actually it makes it slightly less bad.  So that's
> fine.
>
> Maybe we could take a module parameter?

Device attributes would be better so they can be set per device instead 
of per module.  They would be useful for some other drivers whose 
supported devices have various optional settings that can't be read or 
written programmatically.

> We couldn't read this information from the eprom?

Looking at Advantech's own driver source in package 
advdaq-1.10.0001-1.tar.bz2 available from 
<http://support.advantech.com.tw/support/DownloadSRDetail_New.aspx?SR_ID=1-41GHVV&Doc_Source=Download>, 
each variant of the PCI-1710 (and there are several) has a unique PCI 
subdevice ID, so this can be used to distinguish the boards.

The following columns consist of vendor ID, device ID, subvendor ID, 
subdevice ID, and model name.

These can all be mapped to PCI-1710:

0x13fe, 0x1710, 0x10b5, 0x9050, PCI-1710S
0x13fe, 0x1710, 0x13fe, 0x0000, PCI-1710
0x13fe, 0x1710, 0x13fe, 0xb100, PCI-1710B
0x13fe, 0x1710, 0x13fe, 0xb200, PCI-1710B2
0x13fe, 0x1710, 0x13fe, 0xc100, PCI-1710C
0x13fe, 0x1710, 0x13fe, 0xc200, PCI-1710C2
0x13fe, 0x1710, 0x1000, 0xd100, PCI-1710U

These can all be mapped to PCI-1710HG:

0x13fe, 0x1710, 0x13fe, 0x0002, PCI-1710HG
0x13fe, 0x1710, 0x13fe, 0xb102, PCI-1710HGB
0x13fe, 0x1710, 0x13fe, 0xb202, PCI-1710HGB2
0x13fe, 0x1710, 0x13fe, 0xc102, PCI-1710HGC
0x13fe, 0x1710, 0x13fe, 0xc202, PCI-1710HGC2
0x13fe, 0x1710, 0x1000, 0xd102, PCI-1710HGU

There are also "L" variants of the PCI-1710 and PCI-1710HG (and others) 
that are cut-down versions without analog outputs.  Those could easily 
be added to the driver, but let's concentrate on the supported cards for 
now!

Each of the above sets of IDs can use the same board enum value in their 
.driver_data member to refer to the same member of the board array, 
although the PCI_VDEVICE() shorthand cannot be used for these boards.

In the above lists, 0x13fe is PCI_VENDOR_ID_ADVANTECH.  (0x10b5 is 
PCI_VENDOR_ID_PLX, probably because the cards use a PLX PCI-9050 or PLX 
PCI-9052 PCI interface chip.  0x1000 was probably picked at random 
although it happens to match PCI_VENDOR_ID_NCR.  These don't matter much 
as they are only used as subvendor IDs.)

-- 
-=( Ian Abbott @ MEV Ltd.    E-mail: <abbotti at mev.co.uk>        )=-
-=( Tel: +44 (0)161 477 1898   FAX: +44 (0)161 718 3587         )=-



More information about the devel mailing list