structure of PCI ID not clear

jamesbon · 11-02-2010, 04:53 AM

Hi,
I am learning Kernel Programming these days I came across a structure

Code:

static DEFINE_PCI_DEVICE_TABLE(rtl8139_pci_tbl) = {
       {0x10ec, 0x8139, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
       {0x10ec, 0x8138, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
       {0x1113, 0x1211, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
       {0x1500, 0x1360, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
       {0x4033, 0x1360, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
       {0x1186, 0x1300, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
       {0x1186, 0x1340, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },

Here are two links
http://lxr.linux.no/#linux+v2.6.36/i...nux/pci.h#L567
http://lxr.linux.no/#linux+v2.6.36/i...icetable.h#L17

but I could not understand this type of structure definition.

How does one point the following entry
{0x10ec, 0x8139, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },

1) What is first field 0x10ec mapped to is it vendor ?
2) What is second field 0x8139 mapped to is it device id ?
3) Does PCI_ANY_ID both represent subvendor,subdevice
4) What are these two 0,0 are they class,mask
5) What is RTL8139 is it driver_data

6) I am also not clear with the way the macro was defined.
In the definition of following macro
#define DEFINE_PCI_DEVICE_TABLE(_table) const struct pci_device_id _table[] __devinitconst

_table is it an array of structure of type pci_device_id ?

7) What is __devinitconst?

neonsignal · 11-02-2010, 06:21 AM

The pci.txt file in the documentation describes the fields in the structure (the table is an array of these pci_device_id structures as you surmised). Not all of the fields have to be provided (hence the PCI_ANY_ID and the zeroes).

Code:

The ID table is an array of struct pci_device_id entries ending with an
all-zero entry; use of the macro DEFINE_PCI_DEVICE_TABLE is the preferred
method of declaring the table.  Each entry consists of:

       vendor,device   Vendor and device ID to match (or PCI_ANY_ID)

       subvendor,      Subsystem vendor and device ID to match (or PCI_ANY_ID)
       subdevice,

       class           Device class, subclass, and "interface" to match.
                       See Appendix D of the PCI Local Bus Spec or
                       include/linux/pci_ids.h for a full list of classes.
                       Most drivers do not need to specify class/class_mask
                       as vendor/device is normally sufficient.

       class_mask      limit which sub-fields of the class field are compared.
                       See drivers/scsi/sym53c8xx_2/ for example of usage.

       driver_data     Data private to the driver.
                       Most drivers don't need to use driver_data field.
                       Best practice is to use driver_data as an index
                       into a static list of equivalent device types,
                       instead of using it as a pointer.

The __devinitconst is just a modifier to force the table to be located in a read-only init data section.

jamesbon · 11-02-2010, 07:16 AM

I had a look on that page
What I am not clear with is the structure definition.
I have defined structures as

Quote:

struct node {
int data;
struct node *next;
}

But I am not able to understand how all the elements are in

Quote:

{}

braces.

Quote:

{0x126c, 0x1211, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },

and why does one need to have a definition of PCI_ID_TABLE
from where a new developer would get these values 0x126c, 0x1211
I have no idea when to put 0x126c or 0x1211.
How do you decide this?

neonsignal · 11-02-2010, 07:49 AM

Quote:

Originally Posted by jamesbon

But I am not able to understand how all the elements are in braces.

It is not just the definition of the table (which is done by the macro), but the initialization of the values in the table. Each list of values enclosed by braces is initializing one structure in the array of structures. After expanding the macro it looks like this (leaving out some of the detail):

Code:

struct pci_device_id rtl8139_pci_tbl[] =
{
   {values for the first device structure...},
   {values for the second device structure...},
   ...
};

Note that the pci_device_id structure itself was already predefined in another header, and is being used here to define the type of the array entries.

Quote:

from where a new developer would get these values 0x126c, 0x1211

These values are specific to a particular piece of hardware. The vendor id is assigned by the PCI SIG, and if you are working with existing hardware, there is an ad-hoc database of ids. For example, 0x1113 is the Accton vendor ID, and 0x1211 is the Accton device ID for the EN5030 ethernet controller.

The list of entries in the table will cover all the different devices for which the driver is relevant. Since different manufacturers use the same chipset, it is often possible to use the same driver for more than one PCI card. However, the cards will have different vendor and device ids, so each one will have a separate entry in the table. The table can then be used by the kernel to check for a matching driver.

jamesbon · 11-02-2010, 08:45 PM

Quote:

Originally Posted by neonsignal

The table can then be used by the kernel to check for a matching driver.

Ok and how will the presence of a device with vendorid,deviceid combination detected by kernel?
As far as I understand once the probe function(Not too sure) detects or kernel detects then the driver would be looked up
and control would be handed over to driver.
If this is correct then how does probe works? Or how a particular device's presence on PCI bus detected.

neonsignal · 11-02-2010, 09:23 PM

Quote:

Originally Posted by jamesbon

Ok and how will the presence of a device with vendorid,deviceid combination detected by kernel?

The code in probe.c will detect the device. This is matched up with the driver (assuming it was registered) in search.c.