linux PCI设备驱动

一、PCI简介
PCI是一种外设总线规范。我们先来看一下什么是总线：总线是一种传输信号的路径或信道。典型情况是，总线是连接于一个或多个导体的电气连线，总线上连接的所有设备可在同一时间收到所有的传输内容。总线由电气接口和编程接口组成。本文讨论Linux 下的设备驱动，所以，重点关注编程接口。
PCI是Peripheral Component Interconnect（外围设备互联）的简称，是普遍使用在桌面及更大型的计算机上的外设总线。PCI架构被设计为ISA标准的替代品，它有三个主要目标：获得在计算机和外设之间传输数据时更好的性能；尽可能的平台无关；简化往系统中添加和删除外设的工作。

二、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之上的主要创新在于配置地址空间。

前文已讲过，PCI驱动程序不需要探测就能访问设备，而这得益于配置地址空间。在系统引导阶段，PCI硬件设备保持未激活状态，但每个PCI主板均配备有能够处理PCI的固件，固件通过读写PCI控制器中的寄存器，提供了对设备配置地址空间的访问。
配置地址空间的前64字节是标准化的，它提供了厂商号，设备号，版本号等信息，唯一标识一个PCI设备。同时，它也提供了最多可多达6个的I/O地址区域，每个区域可以是内存也可以是I/O地址。这几个I/O地址区域是驱动程序找到设备映射到内存和I/O空间的具体位置的唯一途径。有了这两点，PCI驱动程序就完成了相当于探测的功能。关于这64个字节的配置空间的详细情况，可参阅《Linux设备驱动程序第三版》P306，不再详述。
下面，我们来看一下8139too网卡设备的配置空间的详细情况。在2.6内核的系统中，可以在目录/sys/bus/pci/drivers/下看到很多以PCI设备名命名的目录，但不是说这些设备都存在于你的系统中。我们进入8139too目录，其中有一个以它的设备地址0000:02:01.0命名的目录。在这个目录下可以找到该网卡设备相关的很多信息。其中resource记录了它的6个I/O地址区域。内容如下：
0x0000000000003400 0x00000000000034ff 0x0000000000000101
0x00000000e0000800 0x00000000e00008ff 0x0000000000000200
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
由该文件可以看出，8139too设备使用了两个I/O地址区域，第一个是它映射的I/O端口范围，第二个是它映射的内存地址空间。关于这两个值可以在/proc/iomem和/proc/ioport中得到验证。

为了能看到实际的运行效果，我们选择8139too网卡作为示例,从该网卡的linux驱动程序中裁剪相关代码。
一个PCI设备的驱动程序必须要向内核中的PCI核心描述自己。同时，它也必须告诉PCI核心自己能够驱动哪些设备。下面，就介绍两个相关的重要数据结构。
struct pci_device_id {undefined
__u32 vendor, device; /* Vendor and device ID or PCI_ANY_ID*/
__u32 subvendor, subdevice; /* Subsystem ID’s or PCI_ANY_ID /
__u32 class, class_mask; / (class,subclass,prog-if) triplet /
kernel_ulong_t driver_data; / Data private to the driver */
};

struct pci_driver {undefined
    struct list_head node;
    char *name;
    struct module *owner;
    const struct pci_device_id *id_table; //驱动所能操纵的设备id列表。
    int (*probe)(struct pci_dev *dev, const struct pci_device_id *id); //插入新设备
    void (*remove)(struct pci_dev *dev);   //移除设备。
    int (*suspend)(struct pci_dev *dev, pm_message_t state);
    int (*resume)(struct pci_dev *dev);
    int (*enable_wake) (struct pci_dev *dev, pci_power_t state, int enable);
    void (*shutdown) (struct pci_dev *dev);
    struct device_driver    driver;
    struct pci_dynids dynids;
};
pci_device_id唯一标识一个PCI设备。它的几个成员依次分别表示：厂商号，设备号，子厂商号，子设备号，类别，类别掩码（类可分为基类，子类），私有数据。每一个PCI设备的驱动程序都有一个pci_device_id的数组，用于告诉PCI核心自己能够驱动哪些设备。8139too的驱动程序定义它的pci_device_id数组如下：
    static struct pci_device_id rtl8139_pci_tbl[];
该数组被初始化为8139系列的一组网卡，当PCI核心得到这个数组后，会拿数组中的每一项跟从PCI配置空间中读取到的数据进行比对，从而为该驱动程序找到正确的设备。而pci_driver代表一个pci驱动程序。成员id_talbe即是指向pci_device_id数组的指针。name是驱动程序的名字，probe完成探测工作，即拿pci_device_id数组与内核中的数据进行比对。remove完成驱动程序的移除工作。关键的成员就这几个。
驱动程序通过pci_module_init向内核注册自己（我们有时会看到pci_register_driver函数，其实它们是同一个，在内核代码中会看到，只是一个简单的#define）：
        pci_module_init(&pci_driver);
调用函数后，如果pci_device_id数组中标识的设备存在于系统中，并且该设备恰好还没有驱动程序，则该驱动程序会被安装。下面我们来看从8139too驱动代码中裁剪的pci设备初始化代码：

pci_driver.h:

/* pci_driver.h

• helinqiang@hotmail.com
• 2006-3-5
  */
  #ifndef PCI_DRIVER_H
  #define PCI_DRIVER_H

#include <linux/mod_devicetable.h> //for struct pci_device_id
#include <linux/module.h> //for MODULE_DEVICE_TABLE
#include <linux/pci.h> //for struct pci_driver

#define DRV_NAME “8139too”
#define DRV_VERSION “0.9.27”
#define RTL8139_DRIVER_NAME DRV_NAME " Fast Ethernet driver " DRV_VERSION

typedef enum{undefined
RTL8139 = 0,
RTL8129,
}board_t;

static struct pci_device_id rtl8139_pci_tbl[] = {undefined
{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 },
{0x13d1, 0xab06, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x1259, 0xa117, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x1259, 0xa11e, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x14ea, 0xab06, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x14ea, 0xab07, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x11db, 0x1234, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x1432, 0x9130, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x02ac, 0x1012, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x018a, 0x0106, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x126c, 0x1211, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x1743, 0x8139, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x021b, 0x8139, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },

#ifdef CONFIG_SH_SECUREEDGE5410
/* Bogus 8139 silicon reports 8129 without external PROM 😦 /
{0x10ec, 0x8129, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
#endif
#ifdef CONFIG_8139TOO_8129
{0x10ec, 0x8129, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8129 },
#endif
/ some crazy cards report invalid vendor ids like
* 0x0001 here. The other ids are valid and constant,
* so we simply don’t match on the main vendor id.
*/
{PCI_ANY_ID, 0x8139, 0x10ec, 0x8139, 0, 0, RTL8139 },
{PCI_ANY_ID, 0x8139, 0x1186, 0x1300, 0, 0, RTL8139 },
{PCI_ANY_ID, 0x8139, 0x13d1, 0xab06, 0, 0, RTL8139 },
{0,}
};
MODULE_DEVICE_TABLE(pci, rtl8139_pci_tbl);
static int __devinit rtl8139_init_one(struct pci_dev *pdev, const struct pci_device_id *id);
static void __devexit rtl8139_remove_one(struct pci_dev *pdev);

static struct pci_driver rtl8139_pci_driver = {undefined
.name = DRV_NAME,
.id_table = rtl8139_pci_tbl,
.probe = rtl8139_init_one,
.remove = __devexit_p(rtl8139_remove_one),
};

#endif //PCI_DRIVER_H

pci_driver.c:
/* pci_driver.c

• helinqiang@hotmail.com
• 2006-3-5
  */

#include “pci_driver.h”

#include <linux/init.h>

MODULE_AUTHOR(“Linqiang He, Hangzhou China”);
MODULE_LICENSE(“Dual BSD/GPL”);

static int __init rtl8139_init_module(void)
{undefined
/* when we’re a module, we always print a version message,
* even if no 8139 board is found.
*/
#ifdef MODULE
printk (KERN_INFO RTL8139_DRIVER_NAME “/n”);
#endif

return pci_module_init(&rtl8139_pci_driver);

}

static void __exit rtl8139_cleanup_module (void)
{undefined
pci_unregister_driver(&rtl8139_pci_driver);
}

module_init(rtl8139_init_module);
module_exit(rtl8139_cleanup_module);

int __devinit rtl8139_init_one(struct pci_dev *pdev, const struct pci_device_id *id)
{undefined
//这里可插入各种调试代码，下文会有专门描述。
return 0;
}

void __devexit rtl8139_remove_one (struct pci_dev *pdev)
{undefined
}

注册驱动程序成功后，rtl8139_init_one会被调用，在这个函数中，我们可以通过插入一些打印输出语句看到PCI的配置地址空间和I/O地址区域的一些情况。
首先，插入以下语句：
        u16 vendor, device;
        pci_read_config_word(pdev, 0, &vendor);
        pci_read_config_word(pdev, 2, &device);
        printk(KERN_INFO "%x, %x/n", vendor, device);
这段代码读取了网卡设备的配置地址空间的前四位，它正好是设备的厂商号和设备号。下面是输出：
        Mar  9 21:44:39 localhost kernel: 10ec, 8139
10ec和8139就是我的网卡的厂商号和设备号了。
再插入下列代码：
        u32 addr1,addr2,addr3, addr4,addr5,addr6;
        pci_read_config_dword(pdev, 16, &addr1);
        pci_read_config_dword(pdev, 20, &addr2);
        pci_read_config_dword(pdev, 24, &addr3);
        pci_read_config_dword(pdev, 28, &addr4);
        pci_read_config_dword(pdev, 32, &addr5);
        pci_read_config_dword(pdev, 36, &addr6);
        printk(KERN_INFO "%x,%x,%x,%x,%x,%x/n",addr1, addr2, addr3, addr4,addr5,addr6);
这段代码读取网卡设备的6个I/O地址区域的址始位置。下面是输出：
Mar  9 21:55:06 localhost kernel: 3401,e0000800,0,0,0,0
可见，该设备只使用了前两个I/O地址区域，分别标识它的I/O端口区域和内存地址空间。
另外，在这里，还可直接打印出网卡的MAC地址。不再详述。

接着上文给出的源代码，我们可以在rtl8139_init_one中插入一些不同的调试代码，观察设备驱动模块在内核中的一些动作。
8139too网卡设备的设备内存的头6个字节存放的是该网卡的48位的MAC地址，我们可以通过访问设备内存得到这个MAC地址。下面通过在 rtl8139_init_one在插入代码，以四种不同方式访问设备内存。第一种是通过访问I/O内存实现，后三种则是通过访问I/O端口的形式实现。
第一种：
unsigned long mmio_start, addr1, addr2;
void __iomem *ioaddr;
mmio_start = pci_resource_start( pdev, 1);
ioaddr = pci_iomap(pdev, 1, 0);
addr1 = ioread32( ioaddr );
addr2 = ioread32( ioaddr + 4 );
printk(KERN_INFO “mmio start: %lX/n”, mmio_start);
printk(KERN_INFO “ioaddr: %p/n”, ioaddr);
printk(KERN_INFO “%02lX.%02lX.%02lX.%02lX.%02lX.%02lX/n”,
(addr1) & 0xFF,
(addr1 >> 8) & 0xFF,
(addr1 >> 16 ) & 0xFF,
(addr1 >> 24 ) & 0xFF,
(addr2) & 0xFF,
(addr2 >> 8) & 0xFF );
运行结果：
Mar 10 22:34:56 localhost kernel: mmio start: E0000800
Mar 10 22:34:56 localhost kernel: ioaddr: f8aa6800
Mar 10 22:34:56 localhost kernel: 00.02.3F.AC.41.9D

第二种：
unsigned long pio_start, pio_len, addr1, addr2;
void __iomem *ioaddr;
pio_start = pci_resource_start( pdev, 0);
pio_len = pci_resource_len (pdev, 0);
ioaddr = ioport_map(pio_start, pio_len);
addr1 = ioread32( ioaddr );
addr2 = ioread32( ioaddr + 4 );
printk(KERN_INFO “pio start: %lX/n”, pio_start);
printk(KERN_INFO “ioaddr: %p/n”, ioaddr);
printk(KERN_INFO “%02lX.%02lX.%02lX.%02lX.%02lX.%02lX/n”,
(addr1) & 0xFF,
(addr1 >> 8) & 0xFF,
(addr1 >> 16 ) & 0xFF,
(addr1 >> 24 ) & 0xFF,
(addr2) & 0xFF,
(addr2 >> 8) & 0xFF );
运行结果：
Mar 10 22:30:52 localhost kernel: pio start: 3400
Mar 10 22:30:52 localhost kernel: ioaddr: 00013400
Mar 10 22:30:52 localhost kernel: 00.02.3F.AC.41.9D

第三种：
unsigned long pio_start, addr1, addr2;
pio_start = pci_resource_start( pdev, 0 );
addr1 = inl( pio_start );
addr2 = inl( pio_start + 4 );
printk(KERN_INFO “port io start: %lX/n”, pio_start);
printk(KERN_INFO “%02lX.%02lX.%02lX.%02lX.%02lX.%02lX/n”,
(addr1) & 0xFF,
(addr1 >> 8) & 0xFF,
(addr1 >> 16) & 0xFF,
(addr1 >> 24) & 0xFF,
(addr2) & 0xFF,
(addr2 >> 8) & 0xFF );
运行结果：
Mar 10 22:36:18 localhost kernel: port io start: 3400
Mar 10 22:36:18 localhost kernel: 00.02.3F.AC.41.9D

第四种：
unsigned long pio_start;
u8 addr1, addr2, addr3, addr4, addr5, addr6;
pio_start = pci_resource_start( pdev, 0 );
addr1 = inb( pio_start );
addr2 = inb( pio_start + 1 );
addr3 = inb( pio_start + 2 );
addr4 = inb( pio_start + 3 );
addr5 = inb( pio_start + 4 );
addr6 = inb( pio_start + 5 );
printk(KERN_INFO “port io start: %lX/n”, pio_start);
printk(KERN_INFO “%02X.%02X.%02X.%02X.%02X.%02X/n”,
addr1, addr2, addr3, addr4, addr5, addr6 );
运行结果：
Mar 10 22:37:19 localhost kernel: port io start: 3400
Mar 10 22:37:19 localhost kernel: 00.02.3F.AC.41.9D
每种外设都通过读写寄存器进行控制。大部分外设都有几个寄存器，不管是在内存地址空间还是在I/O地址空间，这些寄存器的访问地址都是连续的。x86的处理器为I/O端口的读和写提供了独立的线路，并且使用特殊的CPU指令访问端口。但即使这样，也不是所有的设备都会把寄存器映射到I/O端口中。ISA设备普遍使用I/O端口，而大多数PCI设备则把寄存器映射到某个内存地址区段。
I/O端口是驱动程序与许多设备之间的通信方式，Linux的内核为我们提供了I/O端口分配的操作接口，但对PCI设备来讲，它的配置地址空间已经为其指定了I/O端口范围，不需要额外的分配操作。Linux内核
提供了如下一些访问I/O端口的内联函数：
unsigned inb(unsigned port);
void outb(unsigned char byte, unsigned port);
unsigned inw(unsigned port);
void outw(unsigned short word, unsigned port);
unsigned inl(unsigned port);
void outl(unsigned longword, unsigned port);
下面我们重点来看一下2.6内核引入的ioport_map函数：
void *ioport_map( unsigned long port, unsigned int count );
通过这个函数，可以把port开始的count个连续端口重映射为一段“内存空间”。然后就可以在其返回的地址上象访问I/O内存一样访问这几个I/O端口。当不需要这种映射时，需要调用下面的函数来撤消：
void iport_unmap(void *addr);
浏览2.6内核的源代码，我们不难发现，这种所谓的映射其实是“假”的。下面是这两个函数的实现，及一些相关数据：
#define PIO_OFFSET 0x10000UL
#define PIO_MASK 0x0ffffUL
#define PIO_RESERVED 0x40000UL

void __iomem *ioport_map(unsigned long port, unsigned int nr)
{undefined
    if (port > PIO_MASK)
        return NULL;
    return (void __iomem *) (unsigned long) (port + PIO_OFFSET);
}

void ioport_unmap(void __iomem *addr)
{undefined
    /* Nothing to do */
}
它只是简单地把I/O端口号加上PIO_OFFSET(64K)，作为一个“假”的内存地址返回，而unmap则什么也不做。之所以这样做，是基于这样一个事实：真正的I/O内存地址经过映射成为虚拟地址后，由于是在内核空间，其值肯定大于3G。而port+PIO_OFFSET不会大于128K。所以，内核不会把这两种地址搞混。可以分别进行处理，下面看看ioread8函数的实现：
unsigned int fastcall ioread8(void __iomem *addr)
{undefined
    IO_COND(addr, return inb(port), return readb(addr));
}

#define VERIFY_PIO(port) BUG_ON((port & ~PIO_MASK) != PIO_OFFSET)
#define IO_COND(addr, is_pio, is_mmio) do {         /
    unsigned long port = (unsigned long __force)addr;   /
    if (port < PIO_RESERVED) {              /
        VERIFY_PIO(port);               /
        port &= PIO_MASK;               /
        is_pio;                     /
    } else {                        /
        is_mmio;                    /
    }                           /
} while (0)
展开：
unsigned int fastcall ioread8(void __iomem *addr)
{undefined
    unsigned long port = (unsigned long __force)addr;
    if( port < 0x40000UL ) {undefined
        BUG_ON( (port & ~PIO_MASK) != PIO_OFFSET );
        port &= PIO_MASK;
        return inb(port);
    }else{undefined
        return readb(addr);
    }
}
所以，除了提供一个统一的接口，它并没有在本质上改变什么。
除了I/O端口之外，和设备通信的另一种主要机制是通过使用映射到内存的寄存器或设备内存。这两种都称为I/O内存，因为寄存器和内存的差别对软件是透明的。
对于分配好的I/O内存，一般不鼓励直接使用指向I/O内存的指针进行访问，最好通过页表，用包装函数访问。要通过页表访问，那么需要对分配好的I/O内存进行映射，确保该I/O内存对内核而言是可访问的。完成I/O内存映射的函数是ioremap：
#include <asm/io.h>
void *ioremap(unsigned long phys_addr, unsigned long size);
它把一个总线内存地址映射到CPU空间。
关于这些接口的实际使用，可参考前一篇。

分配与释放，注册与注销
在内核空间运行的模块，在分配了系统资源后，必须在不再使用前，进行释放，向内核返回所分配的资源。同时，很多模块在实际使用前，必须向内核注册自己，同样，在生命期结束时，必须向内核注销自己。
分配与释放，注册与注销。在内核模块中，经常是成对出现的。在我们前文描述的8139too网卡驱动初始化程序中，就存在很多这样的操作。下面我们一一列出，并作简单分析：

pci_register_driver与pci_unregister_driver
它们是分别在PCI设备驱动模块的初始化函数和清除函数中被调用的函数，都以一个struct pci_driver结构体作为参数。下面是这个结构的定义：
struct pci_driver {
struct list_head node;
char *name;
struct module *owner;
const struct pci_device_id *id_table;
int (*probe)(struct pci_dev *dev, const struct pci_device_id *id);
void (*remove)(struct pci_dev *dev);
int (*suspend)(struct pci_dev *dev, pm_message_t state);
int (*resume)(struct pci_dev dev); / Device woken up */
int (*enable_wake)(struct pci_dev *dev,pci_power_t state,int enable);
void (*shutdown) (struct pci_dev *dev);
struct device_driver driver;
struct pci_dynids dynids;
};
它有一个成员struct device_driver，是一个更为一般化的设备驱动对象，在pci_register_driver函数中，会把pci_driver的很多成员赋给该结构中的相应成员。同时，建立动态PCI的id表（为热插拔设备用）。最后，向总线注册该设备。而在pci_unregister_driver中做的事情就是从总线中注销该设备，同时释放动态的PCI id表。

alloc_etherdev和free_netdev
前文已经描述过，alloc_etherdev是alloc_netdev的封装函数。它们都以struct net_device结构体作为参数，alloc_netdev所做事情就是在内核空间为该结构体kmalloc内存，最后调用它的初始化函数。而 free_netdev则主要是kfree内存。

pci_enable_device和pci_disable_device
在一个pci设备可以被使用之前，必须调用pci_enable_device进行激活，该函数会调用底层代码激活PCI设备上的I/O和内存，使之可用。而pci_disable_device所做的事情刚好相反，告诉系统该PCI设备不再使用，
同时，禁用相关的一些资源。

pci_request_regions和pci_release_regions
这两个函数背后，实际调用的是request_region和release_region,或者request_mem_region和 release_mem_region进行I/O端口的分配与释放，或者I/O内存的分配与释放。

还有关于pci_iomap与pci_iounmap，前文已有介绍。