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@xxxxxxxxx> )=-
-=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
