[PATCH 00/12] staging: comedi: cleanup the pci vendor ids

[Ian Abbott]

On 2012-10-25 03:42, Greg KH wrote:
> On Wed, Oct 24, 2012 at 06:10:31PM -0700, H Hartley Sweeten wrote:
>> Move all the pci vendor id defines from the drivers to comedidev.h.
>> Use the kernel provided vendor ids in pci_ids.h where appropriate.
>>
>> The jr3_pci and s626 drivers still have a private PCI_VENDOR_ID_*
>> define.
>>
>> The jr3_pci vendor id is not found at www.pcidatabase.com.

<http://www.pcisig.com/membership/vid_search/> should be more 
authoritative for vendor IDs.  It shows vendor ID 0x1762 as belonging to 
"JR3 Inc.".  Looks legit!

>>
>> The s626 vendor id shows up as belonging to NXP Semiconductor but
>> I have not verified that this is the actual chip on that board.

Pictures of the S626 show some sort of Philips chip on there as the PCI 
interface:

<http://www.sensoray.com/assets/images/626photo.JPG>

NXP was spun off from Philips semiconductor division.  I'm guessing the 
S626 is using the PCI interface chip's default vendor and device IDs as 
the subvendor ID is totally different.  (Strictly speaking, subvendor 
IDs should also be allocated by PCI-SIG but practically it often isn't.)

>>
>> The skel driver also still has a private PCI_VENDOR_ID_* but it is
>> completely bogus.

I wonder if PCI-SIG have an "example" vendor ID that could be used, 
similar to 555 area-code telephone numbers in North America?

One suspicious one I know about is the PCI_VENDOR_ID_ICP (0x104c) used 
by the "icp_multi" driver.  That driver supports a single board (Inova 
ICP-MULTI) with vendor ID 0x104c and device ID 0x8000 (as used in 
"icp_multi").  This driver doesn't actually define a PCI table 
currently, but if it did it would clash with the one in 
"drivers/firewire/nosy.c".

I found an old driver for ICP-MULTI that includes subvendor and 
subdevice IDs, as can be seen here:

<https://aslforge.ethz.ch/scm/viewvc.php/drivers/inova/icpmulti/icp_mio/h/mio_pci.h?view=markup&revision=22&root=robox-linux&pathrev=22>

#ifndef ICP_MIO_VENDORID
   #define ICP_MIO_VENDORID            0x104c
#endif /* ICP_MIO_VENDORID */

#ifndef ICP_MIO_DEVICEID
   #define ICP_MIO_DEVICEID            0x8000
#endif /* ICP_MIO_DEVICEID */

#ifndef ICP_MIO_SUBSYSID
   #define ICP_MIO_SUBSYSID            0x14A6
#endif /* ICP_MIO_SUNSYSID */

#ifndef ICP_MIO_SUBDEVID
   #define ICP_MIO_SUBDEVID            0x00A1
#endif /* ICP_MIO_SUBDEVID */

0x14a6 is actually assigned to Inova Computers Gmbh who designed the 
ICP-MULTI board.

What I think is happening there is that vendor 0x104c device 0x8000 is 
probably a PCI interface chip made by Texas Instruments, possibly with 
no facility to change the default vendor ID and device ID, but with 
facilities to change the subvendor ID and subdevice ID.

The "icp_multi" driver is a mess anyway, but when we fix it we need to 
make sure to match the subvendor and subdevice IDs.  It would probably 
still clash with "drivers/firewire/nosy.c" as that one is not currently 
matching subvendor and subdevice IDs, but I guess that is fixable.

>
> Nice job with these cleanups.  Eventually we should pus the comedidev.h
> values into pci_ids.h as they are in multiple drivers, so that should be
> ok.

Though hopefully the identifiers won't be so abbreviated (in a few 
cases, e.g. "CB" and "DT") and will match the names of the _real_ 
assignees of the vendor IDs (e.g. Texas Instruments instead of ICP).

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