版权声明：本文为博主原创文章，未经博主允许不得转载。

https://blog.csdn.net/huangweiqing80/article/details/83112671

一、Pci的地址域

PCI总线协议中定义了三个不同的地址空间：1、PCI配置空间；2、PCI memory空间；3、PCI的IO空间。如果对PCI没有形成一点感念的初学者，很难理解这几个空间的区别。

简单的说，PCI配置空间是PCI设备的内部属性，设备内部保存了256bytes的空间作为内部register定义该设备的属性。访问配置空间使用IO读写(X86架构中使用CF8h/CFCh端口)；而PCI设备的memory/IO空间则是映射到CPU地址域中，需要占用的memory/IO地址空间。访问这部分地址域只要使用简单直接的memory、IO访问方式就可以实现。

每个PCI设备的配置空间数据都不一样。基本上都是以固定的形式。每个外围设备在其 PCI 配置空间中都包含一组明确定义的配置寄存器。这些寄存器不仅用于标识设备，还用于提供设备配置信息。生成配置周期的方法取决于主机架构，x86 计算机中使用的是特殊的 I/O 端口(CF8h/CFCh端口)。在其他平台上，可以将 PCI 配置空间内存映射到对应于主机地址域中 PCI 主桥 (host bridge) 的某些地址位置,比如MIPS架构中。

二、PCI寻址

我们先来看一个例子，我的电脑装有1G的RAM，1G以后的物理内存地址空间都是外部设备IO在系统内存地址空间上的映射。/proc/iomem描述了系统中所有的设备I/O在内存地址空间上的映射。我们来看地址从1G开始的第一个设备在/proc/iomem中是如何描述的：

40000000-400003ff : 0000:00:1f.1

这是一个PCI设备，40000000-400003ff是它所映射的内存地址空间，占据了内存地址空间的1024 bytes的位置，而0000:00:1f.1则是一个PCI外设的地址,它以冒号和逗号分隔为4个部分，第一个16位表示域，第二个8位表示一个总线编号，第三个5位表示一个设备号，最后是3位，表示功能号。

因为PCI规范允许单个系统拥有高达256个总线，所以总线编号是8位。但对于大型系统而言，这是不够的，所以，引入了域的概念，每个PCI域可以拥有最多256个总线，每个总线上可支持32个设备，所以设备号是5位，而每个设备上最多可有8种功能，所以功能号是3位。由此，我们可以得出上述的PCI设备的地址是0号域0号总线上的31号设备上的1号功能。那上述的这个PCI设备到底是什么呢？下面是我的电脑上的lspci命令的输出：

    00:00.0 Host bridge: Intel Corporation 82845 845 (Brookdale) Chipset Host Bridge (rev 04)
    00:01.0 PCI bridge: Intel Corporation 82845 845 (Brookdale) Chipset AGP Bridge(rev 04)
    00:1d.0 USB Controller: Intel Corporation 82801CA/CAM USB (Hub #1) (rev 02)
    00:1d.1 USB Controller: Intel Corporation 82801CA/CAM USB (Hub #2) (rev 02)
    00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 42)
    00:1f.0 ISA bridge: Intel Corporation 82801CAM ISA Bridge (LPC) (rev 02)
    00:1f.1 IDE interface: Intel Corporation 82801CAM IDE U100 (rev 02)
    00:1f.3 SMBus: Intel Corporation 82801CA/CAM SMBus Controller (rev 02)
    00:1f.5 Multimedia audio controller:Intel Corporation 82801CA/CAM AC'97 Audio Controller (rev 02)
    00:1f.6 Modem: Intel Corporation 82801CA/CAM AC'97 Modem Controller (rev 02)
    01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 420 Go](rev a3)
    02:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller(rev 46)
    02:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+(rev 10)
    02:04.0 CardBus bridge: O2 Micro, Inc. OZ6933 Cardbus Controller (rev 01)
    02:04.1 CardBus bridge: O2 Micro, Inc. OZ6933 Cardbus Controller (rev 01)

lspci 没有标明域，但对于一台PC而言，一般只有一个域，即0号域。通过这个输出我们可以看到它是一个IDE interface。由上述的输出可以看到，我的电脑上共有3个PCI总线(0号，1号，2号）。在单个系统上，插入多个总线是通过桥（bridge)来完成的，桥是一种用来连接总线的特殊PCI外设。所以，PCI系统的整体布局组织为树型，我们可以通过上面的lspci输出，来画出我的电脑上的PCI系统的树型结构：

00:00.0(主桥）--00:01.0(PCI桥）-----01:00:0(nVidia显卡）
                  |
                  |---00:1d(USB控制器)--00:1d:0(USB1号控制器）
                  |                   |
                  |                   |--00:1d:1(USB2号控制器）                   |
                  |-00:1e:0(PCI桥)--02:00.0(IEEE1394)
                  |               |
                  |               |-02:01.0(8139网卡）
                  |               |
                  |               |-02:04(CardBus桥)-02:04.0(桥1）
                  |                                  |
                  |                                  |--02:04.1(桥2)
                  |
                  |-00:1f(多功能板卡)-00:1f:0(ISA桥）
                                       |
                                       |--00:1f:1(IDE接口)
                                       |
                                       |--00:1f:3(SMBus)
                                       |
                                       |--00:1f:5(多媒体声音控制器)
                                       |
                                       |--00:1f:6(调制解调器)

由上图可以得出，我的电脑上共有8个PCI设备，其中0号总线上(主桥)上连有4个，1号总线上连有1个，2号总线上连有3个。00:1f是一个连有5个功能的多功能板卡。

每一个PCI设备都有它映射的内存地址空间和它的I/O区域，这点是比较容易理解的。除此之外，PCI设备还有它的配置寄存器。有了配置寄存器，PCI的驱动程序就不需要探测就能访问设备。配置寄存器的布局是标准化的，配置空间的4个字节含有一个独一无二的功能ID，因此，驱动程序可通过查询外设的特定 ID来识别其设备。所以，PCI接口标准在ISA之上的主要创新在于配置地址空间。

三、linux中pci设备知识

Linux PCI设备驱动实际包括Linux PCI设备驱动和设备本身驱动两部分。PCI(Periheral Component Interconnect)有三种地址空间：PCI I/O空间、PCI内存地址空间和PCI配置空间。其中，PCI I/O空间和PCI内存地址空间由设备驱动程序使用，而PCI配置空间由Linux PCI初始化代码使用，用于配置PCI设备，比如中断号以及I/O或内存基地址。

3.1 内核工作

Linux内核主要就做了对PCI设备的

枚举和配置

；在Linux内核初始化时完成的。

对于PCI总线，有一个叫做PCI桥的设备用来将父总线与子总线连接。作为一种特殊的PCI设备，PCI桥主要包括以下三种：

1). Host/PCI桥: 用于连接CPU与PCI根总线，第1个根总线的编号为0。在PC中，内存控制器也通常被集成到Host/PCI桥设备芯片中，因此Host/PCI桥通常也被称为“北桥芯片组(North Bridge Chipset)”。

2). PCI/ISA桥: 用于连接旧的ISA总线。通常，PCI中类似i8359A中断控制器这样的设备也会被集成到PCI/ISA桥设备中。因此，PCI/ISA桥通常也被称为“南桥芯片组(South Bridge Chipset)”

3). PCI-to-PCI桥(以下称为PCI-PCI桥): 用于连接PCI主总线(Primary Bus)和次总线(Secondary Bus)。PCI-PCI桥所处的PCI总线称为主总线，即次总线的父总线；PCI-PCI桥所连接的PCI总线称为次总线，即主总线的子总线。

3.1.2 遍历

从Host/PCI桥开始进行探测和扫描，逐个“枚举”连接在第一条PCI总线上的所有设备并记录在案。如果其中的某个设备是PCI-PCI桥，则又进一步再探测和扫描连在这个桥上的次级PCI总线。就这样递归下去，直到穷尽系统中的所有PCI设备。其结果，是在内存中建立起一棵代表着这些PCI总线和设备的PCI树。

每个PCI设备（包括PCI桥设备）都由一个pci_dev结构体来表示，而每条PCI总线则由pci_bus结构来表示。

3.1.3 配置

PCI设备中一般都带有一些RAM和ROM 空间，通常的控制/状态寄存器和数据寄存器也往往以RAM区间的形式出现，而这些区间的地址在设备内部一般都是从0开始编址的，那么当总线上挂接了多个设备时，对这些空间的访问就会产生冲突。所以，这些地址都要先映射到系统总线上，再进一步映射到内核的虚拟地址空间。

配置就是通过对PCI配置空间的寄存器进行操作从而完成地址的映射。

1.1.4 数据结构

pci_driver数据结构定义在：include/linux/pci.h文件中。

struct pci_driver {
	struct list_head node;
	const char *name;
	const struct pci_device_id *id_table;	/* must be non-NULL for probe to be called */
	int  (*probe)  (struct pci_dev *dev, const struct pci_device_id *id);	/* New device inserted */
	void (*remove) (struct pci_dev *dev);	/* Device removed (NULL if not a hot-plug capable driver) */
	int  (*suspend) (struct pci_dev *dev, pm_message_t state);	/* Device suspended */
	int  (*suspend_late) (struct pci_dev *dev, pm_message_t state);
	int  (*resume_early) (struct pci_dev *dev);
	int  (*resume) (struct pci_dev *dev);	                /* Device woken up */
	void (*shutdown) (struct pci_dev *dev);
	struct pci_error_handlers *err_handler;
	struct device_driver	driver;
	struct pci_dynids dynids;
};

pci_dev也定义在include/linux/pci.h文件中。

详细描述了一个PCI设备几乎所有的硬件信息，包括厂商ID、设备ID、各种资源等.

/*
 * The pci_dev structure is used to describe PCI devices.
 */
struct pci_dev {
	struct list_head bus_list;	/* node in per-bus list */
	struct pci_bus	*bus;		/* bus this device is on */
	struct pci_bus	*subordinate;	/* bus this device bridges to */

	void		*sysdata;	/* hook for sys-specific extension */
	struct proc_dir_entry *procent;	/* device entry in /proc/bus/pci */
	struct pci_slot	*slot;		/* Physical slot this device is in */

	unsigned int	devfn;		/* encoded device & function index */
	unsigned short	vendor;
	unsigned short	device;
	unsigned short	subsystem_vendor;
	unsigned short	subsystem_device;
	unsigned int	class;		/* 3 bytes: (base,sub,prog-if) */
	u8		revision;	/* PCI revision, low byte of class word */
	u8		hdr_type;	/* PCI header type (`multi' flag masked out) */
	u8		pcie_cap;	/* PCI-E capability offset */
	u8		pcie_type:4;	/* PCI-E device/port type */
	u8		pcie_mpss:3;	/* PCI-E Max Payload Size Supported */
	u8		rom_base_reg;	/* which config register controls the ROM */
	u8		pin;  		/* which interrupt pin this device uses */

	struct pci_driver *driver;	/* which driver has allocated this device */
	u64		dma_mask;	/* Mask of the bits of bus address this
					   device implements.  Normally this is
					   0xffffffff.  You only need to change
					   this if your device has broken DMA
					   or supports 64-bit transfers.  */

	struct device_dma_parameters dma_parms;

	pci_power_t     current_state;  /* Current operating state. In ACPI-speak,
					   this is D0-D3, D0 being fully functional,
					   and D3 being off. */
	int		pm_cap;		/* PM capability offset in the
					   configuration space */
	unsigned int	pme_support:5;	/* Bitmask of states from which PME#
					   can be generated */
	unsigned int	pme_interrupt:1;
	unsigned int	pme_poll:1;	/* Poll device's PME status bit */
	unsigned int	d1_support:1;	/* Low power state D1 is supported */
	unsigned int	d2_support:1;	/* Low power state D2 is supported */
	unsigned int	no_d1d2:1;	/* Only allow D0 and D3 */
	unsigned int	mmio_always_on:1;	/* disallow turning off io/mem
						   decoding during bar sizing */
	unsigned int	wakeup_prepared:1;
	unsigned int	d3_delay;	/* D3->D0 transition time in ms */

#ifdef CONFIG_PCIEASPM
	struct pcie_link_state	*link_state;	/* ASPM link state. */
#endif

	pci_channel_state_t error_state;	/* current connectivity state */
	struct	device	dev;		/* Generic device interface */

	int		cfg_size;	/* Size of configuration space */

	/*
	 * Instead of touching interrupt line and base address registers
	 * directly, use the values stored here. They might be different!
	 */
	unsigned int	irq;
	struct resource resource[DEVICE_COUNT_RESOURCE]; /* I/O and memory regions + expansion ROMs */

	/* These fields are used by common fixups */
	unsigned int	transparent:1;	/* Transparent PCI bridge */
	unsigned int	multifunction:1;/* Part of multi-function device */
	/* keep track of device state */
	unsigned int	is_added:1;
	unsigned int	is_busmaster:1; /* device is busmaster */
	unsigned int	no_msi:1;	/* device may not use msi */
	unsigned int	block_cfg_access:1;	/* config space access is blocked */
	unsigned int	broken_parity_status:1;	/* Device generates false positive parity */
	unsigned int	irq_reroute_variant:2;	/* device needs IRQ rerouting variant */
	unsigned int 	msi_enabled:1;
	unsigned int	msix_enabled:1;
	unsigned int	ari_enabled:1;	/* ARI forwarding */
	unsigned int	is_managed:1;
	unsigned int	is_pcie:1;	/* Obsolete. Will be removed.
					   Use pci_is_pcie() instead */
	unsigned int    needs_freset:1; /* Dev requires fundamental reset */
	unsigned int	state_saved:1;
	unsigned int	is_physfn:1;
	unsigned int	is_virtfn:1;
	unsigned int	reset_fn:1;
	unsigned int    is_hotplug_bridge:1;
	unsigned int    __aer_firmware_first_valid:1;
	unsigned int	__aer_firmware_first:1;
	pci_dev_flags_t dev_flags;
	atomic_t	enable_cnt;	/* pci_enable_device has been called */

	u32		saved_config_space[16]; /* config space saved at suspend time */
	struct hlist_head saved_cap_space;
	struct bin_attribute *rom_attr; /* attribute descriptor for sysfs ROM entry */
	int rom_attr_enabled;		/* has display of the rom attribute been enabled? */
	struct bin_attribute *res_attr[DEVICE_COUNT_RESOURCE]; /* sysfs file for resources */
	struct bin_attribute *res_attr_wc[DEVICE_COUNT_RESOURCE]; /* sysfs file for WC mapping of resources */
#ifdef CONFIG_PCI_MSI
	struct list_head msi_list;
	struct kset *msi_kset;
#endif
	struct pci_vpd *vpd;
#ifdef CONFIG_PCI_ATS
	union {
		struct pci_sriov *sriov;	/* SR-IOV capability related */
		struct pci_dev *physfn;	/* the PF this VF is associated with */
	};
	struct pci_ats	*ats;	/* Address Translation Service */
#endif
};

static inline struct pci_dev *pci_physfn(struct pci_dev *dev)
{
#ifdef CONFIG_PCI_IOV
	if (dev->is_virtfn)
		dev = dev->physfn;
#endif

	return dev;
}

1.1.5 pci初始化流程顺序

pci这块代码在两个地方，一个是driver/pci,另一个是arch/x86/pci中。

pci系统的初始化工作有内核来完成，在drivers/pci/probe.c文件中，调用postcore_initcall(pcibus_class_init);函数，在sys/class/下创建一个pci_bus目录
drivers/pci/pci-driver.c文件，postcore_initcall(pci_driver_init); 注册pci总线，并在/sys/bus/下创建了一个pci目录
arch/x86/pci/init.c文件中arch_initcall(pci_arch_init);体系架构相关，对于64 bit x86来说使用CONFIG_PCI_DIRECT的方式进行访问PCI配置空间。在内核编译时候可以指定。
drivers/pci/pci-acpi.c文件中，调用arch_initcall(acpi_pci_init);
arch/x86/pci/legacy.c文件中，调用subsys_initcall(pci_subsys_init);
drivers/pci/slot.c文件中，subsys_initcall(pci_slot_init); 创建/sys/bus/slots文件。

四、pci架构概貌

在这里插入图片描述

上图展现了pci驱动架构中,pci_bus.pci_dev之间的关系.

如上图所示:所有的根总线都链接在pci_root_buses链表中. Pci_bus ->device链表链接着该总线下的所有设备.而pci_bus->children链表链接着它的下层总线.

对于pci_dev来说,pci_dev->bus指向它所属的pci_bus. Pci_dev->bus_list链接在它所属bus的device链表上.此外,所有pci设备都链接在pci_device链表中.

五、PCI设备与配置空间

在i386系统结构中，对内存的访问和对输入/输出寄存器的访问通过两套不同的指令完成，所有的存储器和IO两个不同的地址空间。一般而言，内存的物理地址以及输入/输出寄存器的地址是由硬件决定的，不过对于内存的物理地址还可以通过地址映射机制来一次转换（I/O也可以映射）。可是，怎样处理外设的存储空间呢？理想的办法是系统软件自动设置，思路是：

1、外设通过某种途径告诉系统，它有几个存储区间以及I/O地址空间，每个区间是多大，以及各自在本地的地址，显然这些地址都是局部的内部的，都从0开始算起。

2、系统软件在知道了一共有多少外设，各自又有什么样的存储区间以后，就可以为这些区间分配“物理地址”，并且建立起这些区间与总线之间的连接，以后就可以通过这些地址来访问。显然，这里所谓的“物理地址”与真正的物理地址还是有些区别的，它实际上也是一种逻辑地址，所以常称为“总线地址”，因为这是CPU在总线上所看到的地址。可想而知，外设上一定有着某种地址映射机制。所谓的“为外设分配地址”，就是为其分配总线地址，并建立起映射。

PCI设备上存在许多完成上述工作的寄存器（配置空间），

那么系统初始化的时候如何访问这些寄存器？

对于i386结构的处理器，PCI总线的设计者在I/O地址空间保留了8个字节用于这个目的，那就是

0xCF8~0xCFF

,这8个字节的地址空间构成了两个32位的寄存器，第一个是“地址寄存器”0xCF8,第二个是“数据寄存器”0xCFC,

要访问配置空间的寄存器时，CPU先向地址寄存器（0xCF8）写入目标地址（PCI设备配置空间寄存器地址），然后通过数据寄存器进行读写数据

。不过，写入地址寄存器的目标地址是一种包括总线号、设备号、功能号以及配置寄存器地址的综合地址。每个PCI设备最多有8个功能，所以设备号和功能号组合在一起又被称作“逻辑设备”号。

在这里插入图片描述

如上图所示，PCI标准规定每个设备的配置寄存器组最多可以有256字节的连续空间，其中开头的64字节的用途和格式是标准的，成为配置寄存器组的“头部”，这样的头部又有两种，

“0型”头部用于一般的PCI设备，“1型”头部用于PCI桥，无论是“0型”还是“1型”，其开头的16个字节的用途和格式是共同的。

六、PCI驱动之总线

在内核中与PCI相关的结构体大概有pci_driver 、pci_bus_type 、pci_dev 、pci_bus ，我们前边所说的所有的PCI总线都是指的 pci_bus 。

6.1 pci_bus

struct pci_bus {
	struct list_head node;		/* node in list of buses */
	struct pci_bus	*parent;	/* parent bus this bridge is on */
	struct list_head children;	/* list of child buses */
	struct list_head devices;	/* list of devices on this bus */
	struct pci_dev	*self;		/* bridge device as seen by parent */
	struct list_head slots;		/* list of slots on this bus */
	struct resource	*resource[PCI_BUS_NUM_RESOURCES];
					/* address space routed to this bus */
 
	struct pci_ops	*ops;		/* configuration access functions */
	void		*sysdata;	/* hook for sys-specific extension */
	struct proc_dir_entry *procdir;	/* directory entry in /proc/bus/pci */
 
	unsigned char	number;		/* bus number */
	unsigned char	primary;	/* number of primary bridge */
	unsigned char	secondary;	/* number of secondary bridge */
	unsigned char	subordinate;	/* max number of subordinate buses */
 
	char		name[48];
 
	unsigned short  bridge_ctl;	/* manage NO_ISA/FBB/et al behaviors */
	pci_bus_flags_t bus_flags;	/* Inherited by child busses */
	struct device		*bridge;
	struct device		dev;
	struct bin_attribute	*legacy_io; /* legacy I/O for this bus */
	struct bin_attribute	*legacy_mem; /* legacy mem */
	unsigned int		is_added:1;
};

几个重要的成员：

children: PCI桥可以使当前总线得到扩展，当前总线上有几个PCI桥，那么当前总线就会拥有几个子总线，子总线会连接到父总线的children链表中。

device: 连接在这条总线上的设备链表。

ops: 当前总线访问总线上设备配置空间的 read、write 方法。

在内核启动的过程中，首先会创建0级总线，然后枚举探测0级总线上的设备，如果是PCI桥，那么还要进入下一级子总线，最终所有的连接的PCI设备都将被探测到，详细的探测过程，我们在后边分析。

6.2 注册pci总线

struct bus_type pci_bus_type = {
	.name		= "pci",
	.match		= pci_bus_match,
	.uevent		= pci_uevent,
	.probe		= pci_device_probe,
	.remove		= pci_device_remove,
	.shutdown	= pci_device_shutdown,
	.dev_attrs	= pci_dev_attrs,
	.bus_attrs	= pci_bus_attrs,
	.pm		= PCI_PM_OPS_PTR,
};

static int __init pci_driver_init(void)
{
	return bus_register(&pci_bus_type);
}

postcore_initcall(pci_driver_init);

3.3 pci_bus_type

看到 bus_type 显然这是个设备总线驱动模型里的“总线”，与前边提到的 pci_bus ，完全是两码事，那么

pci_driver 和 pci_dev 就是注册到 pci_bus_type 的驱动和设备

。分析总线设备驱动模型的时候，总要分析一下它的 match 函数（匹配规则）。

static int pci_bus_match(struct device *dev, struct device_driver *drv)
{
	struct pci_dev *pci_dev = to_pci_dev(dev);
	struct pci_driver *pci_drv = to_pci_driver(drv);
	const struct pci_device_id *found_id;
 
	found_id = pci_match_device(pci_drv, pci_dev);
	if (found_id)
		return 1;
 
	return 0;
}

static const struct pci_device_id *pci_match_device(struct pci_driver *drv,
						    struct pci_dev *dev)
{
	struct pci_dynid *dynid;
 
	/* Look at the dynamic ids first, before the static ones */
	spin_lock(&drv->dynids.lock);
	list_for_each_entry(dynid, &drv->dynids.list, node) {
		if (pci_match_one_device(&dynid->id, dev)) {
			spin_unlock(&drv->dynids.lock);
			return &dynid->id;
		}
	}
	spin_unlock(&drv->dynids.lock);
 
	return pci_match_id(drv->id_table, dev);
}

static inline const struct pci_device_id *
pci_match_one_device(const struct pci_device_id *id, const struct pci_dev *dev)
{
	if ((id->vendor == PCI_ANY_ID || id->vendor == dev->vendor) &&
	    (id->device == PCI_ANY_ID || id->device == dev->device) &&
	    (id->subvendor == PCI_ANY_ID || id->subvendor == dev->subsystem_vendor) &&
	    (id->subdevice == PCI_ANY_ID || id->subdevice == dev->subsystem_device) &&
	    !((id->class ^ dev->class) & id->class_mask))
		return id;
	return NULL;
}

const struct pci_device_id *pci_match_id(const struct pci_device_id *ids,
					 struct pci_dev *dev)
{
	if (ids) {
		while (ids->vendor || ids->subvendor || ids->class_mask) {
			if (pci_match_one_device(ids, dev))
				return ids;
			ids++;
		}
	}
	return NULL;
}

通过分析代码，PCI设备与驱动的匹配方式有两种，一种是通过 pci_driver->dynids ,另一种是通过 pci_driver->idtable 。使用idtable 是总线设备驱动模型中常用的匹配方法，一般都是通过设备名来匹配，但是PCI比较特殊，它是通过设备的 vendor 、subvendor 、device 、subdevice 来匹配（这些都是在配置空间里可以读取到的）。

至于 pci_driver->dynids ，它是通过用户空间给驱动增加匹配条件的一种方法（还记得I2C可以在用户空间创建设备吗，一样的）。

error = pci_create_newid_file(drv);
static int
pci_create_newid_file(struct pci_driver *drv)
{
	int error = 0;
	if (drv->probe != NULL)
		error = driver_create_file(&drv->driver, &driver_attr_new_id);
	return error;
}

在 pci_register_driver 函数中会调用到一个 pci_create_newid_file 函数，它在 sysfs 文件系统中会创建一个 new_id 的属性文件，通过这个属性文件，我们就可以来为该驱动增加匹配条件。

内核帮助文档有说明：

New PCI IDs may be added to a device driver pci_ids table at runtime as shown below:
echo "vendor device subvendor subdevice class class_mask driver_data" > \

/sys/bus/pci/drivers/{driver}/new_id

对于这种方法不在详细分析。

分析完设备总线驱动模型，我想整个PCI驱动的框架就非常清楚了，内核启动时，通过pci_bus之间的关系枚举出所有的 PCI 设备，并为每一个 PCI 设备创建一个 pci_dev ，根据配置空间的信息填充 pci_dev 之后，注册到pci_bus_type 。而，我们写的 pci_driver 在 idtable 里指定它所支持的设备信息，同样也注册到 pci_bus_type中去，信息一致匹配成功则调用 driver->probe 函数，然后你可以注册字符设备、块设备等等。

本文参考了

https://blog.csdn.net/notbaron/article/details/79643799

https://blog.csdn.net/notbaron/article/details/80346988

https://blog.csdn.net/zyboy2000/article/details/51971453

http://blog.chinaunix.net/uid/25909619/list/1.html?cid=169563

https://so.csdn.net/so/search/s.do?p=1&q=pci&t=blog&domain=&o=&s=&u=fudan_abc&l=&f=&rbg=0

https://blog.csdn.net/lizuobin2/article/details/51828594

原文链接：https://blog.csdn.net/huangweiqing80/article/details/83112671