0001 .. SPDX-License-Identifier: GPL-2.0
0002 .. include:: ../disclaimer-zh_CN.rst
0003
0004 :Original: Documentation/PCI/pci.rst
0005
0006 :翻译:
0007
0008 司延腾 Yanteng Si <siyanteng@loongson.cn>
0009
0010 :校译:
0011
0012
0013
0014 .. _cn_PCI_pci.rst:
0015
0016 ===================
0017 如何写Linux PCI驱动
0018 ===================
0019
0020 :作者: - Martin Mares <mj@ucw.cz>
0021 - Grant Grundler <grundler@parisc-linux.org>
0022
0023 PCI的世界是巨大的，而且充满了（大多数是不愉快的）惊喜。由于每个CPU架构实现了不同
0024 的芯片组，并且PCI设备有不同的要求（呃，“特性”），结果是Linux内核中的PCI支持并不
0025 像人们希望的那样简单。这篇短文试图向所有潜在的驱动程序作者介绍PCI设备驱动程序的
0026 Linux APIs。
0027
0028 更完整的资源是Jonathan Corbet、Alessandro Rubini和Greg Kroah-Hartman的
0029 《Linux设备驱动程序》第三版。LDD3可以免费获得（在知识共享许可下），网址是：
0030 https://lwn.net/Kernel/LDD3/。
0031
0032
0033
0034 然而，请记住，所有的文档都会受到“维护不及时”的影响。如果事情没有按照这里描述的那
0035 样进行，请参考源代码。
0036
0037 请将有关Linux PCI API的问题/评论/补丁发送到“Linux PCI”
0038 <linux-pci@atrey.karlin.mff.cuni.cz> 邮件列表。
0039
0040
0041 PCI驱动的结构体
0042 ===============
0043 PCI驱动通过pci_register_driver()在系统中“发现”PCI设备。实际上，它是反过来的。
0044 当PCI通用代码发现一个新设备时，具有匹配“描述”的驱动程序将被通知。下面是这方面的细
0045 节。
0046
0047 pci_register_driver()将大部分探测设备的工作留给了PCI层，并支持设备的在线插入/移
0048 除[从而在一个驱动中支持可热插拔的PCI、CardBus和Express-Card]。 pci_register_driver()
0049 调用需要传入一个函数指针表，从而决定了驱动的高层结构体。
0050
0051 一旦驱动探测到一个PCI设备并取得了所有权，驱动通常需要执行以下初始化：
0052
0053 - 启用设备
0054 - 请求MMIO/IOP资源
0055 - 设置DMA掩码大小（对于流式和一致的DMA）
0056 - 分配和初始化共享控制数据（pci_allocate_coherent()）
0057 - 访问设备配置空间(如果需要)
0058 - 注册IRQ处理程序(request_irq())
0059 - 初始化非PCI（即芯片的LAN/SCSI/等部分）
0060 - 启用DMA/处理引擎
0061
0062 当使用完设备后，也许需要卸载模块，驱动需要采取以下步骤:
0063
0064 - 禁用设备产生的IRQ
0065 - 释放IRQ（free_irq()）
0066 - 停止所有DMA活动
0067 - 释放DMA缓冲区（包括一致性和数据流式）
0068 - 从其他子系统（例如scsi或netdev）上取消注册
0069 - 释放MMIO/IOP资源
0070 - 禁用设备
0071
0072 这些主题中的大部分都在下面的章节中有所涉及。其余的内容请参考LDD3或<linux/pci.h> 。
0073
0074 如果没有配置PCI子系统（没有设置 ``CONFIG_PCI`` ），下面描述的大多数PCI函数被定
0075 义为内联函数，要么完全为空，要么只是返回一个适当的错误代码，以避免在驱动程序中出现
0076 大量的 ``ifdef`` 。
0077
0078
0079 调用pci_register_driver()
0080 =========================
0081
0082 PCI设备驱动程序在初始化过程中调用 ``pci_register_driver()`` ，并提供一个指向
0083 描述驱动程序的结构体的指针（ ``struct pci_driver`` ）：
0084
0085 该API在以下内核代码中:
0086
0087 include/linux/pci.h
0088 pci_driver
0089
0090 ID表是一个由 ``struct pci_device_id`` 结构体成员组成的数组，以一个全零的成员
0091 结束。一般来说，带有静态常数的定义是首选。
0092
0093 该API在以下内核代码中:
0094
0095 include/linux/mod_devicetable.h
0096 pci_device_id
0097
0098 大多数驱动程序只需要 ``PCI_DEVICE()`` 或 ``PCI_DEVICE_CLASS()`` 来设置一个
0099 pci_device_id表。
0100
0101 新的 ``PCI ID`` 可以在运行时被添加到设备驱动的 ``pci_ids`` 表中，如下所示::
0102
0103 echo "vendor device subvendor subdevice class class_mask driver_data" > \
0104 /sys/bus/pci/drivers/{driver}/new_id
0105
0106 所有字段都以十六进制值传递（没有前置0x）。供应商和设备字段是强制性的，其他字段是可
0107 选的。用户只需要传递必要的可选字段：
0108
0109 - subvendor和subdevice字段默认为PCI_ANY_ID (FFFFFFF)。
0110 - class和classmask字段默认为0
0111 - driver_data默认为0UL。
0112 - override_only字段默认为0。
0113
0114 请注意， ``driver_data`` 必须与驱动程序中定义的任何一个 ``pci_device_id`` 条
0115 目所使用的值相匹配。如果所有的 ``pci_device_id`` 成员都有一个非零的driver_data
0116 值，这使得driver_data字段是强制性的。
0117
0118 一旦添加，驱动程序探测程序将被调用，以探测其（新更新的） ``pci_ids`` 列表中列出的
0119 任何无人认领的PCI设备。
0120
0121 当驱动退出时，它只是调用 ``pci_unregister_driver()`` ，PCI层会自动调用驱动处理
0122 的所有设备的移除钩子。
0123
0124
0125 驱动程序功能/数据的“属性”
0126 -------------------------
0127
0128 请在适当的地方标记初始化和清理函数（相应的宏在<linux/init.h>中定义）：
0129
0130 ====== ==============================================
0131 __init 初始化代码。在驱动程序初始化后被抛弃。
0132 __exit 退出代码。对于非模块化的驱动程序来说是忽略的。
0133 ====== ==============================================
0134
0135 关于何时/何地使用上述属性的提示：
0136
0137 - module_init()/module_exit()函数（以及所有仅由这些函数调用的初始化函数）应该被标记
0138
0139 - 为__init/__exit。
0140
0141 - 不要标记pci_driver结构体。
0142
0143 - 如果你不确定应该使用哪种标记，请不要标记一个函数。不标记函数比标记错误的函数更好。
0144
0145
0146 如何手动搜索PCI设备
0147 ===================
0148
0149 PCI驱动最好有一个非常好的理由不使用 ``pci_register_driver()`` 接口来搜索PCI设备。
0150 PCI设备被多个驱动程序控制的主要原因是一个PCI设备实现了几个不同的HW服务。例如，组合的
0151 串行/并行端口/软盘控制器。
0152
0153 可以使用以下结构体进行手动搜索：
0154
0155 通过供应商和设备ID进行搜索::
0156
0157 struct pci_dev *dev = NULL;
0158 while (dev = pci_get_device(VENDOR_ID, DEVICE_ID, dev))
0159 configure_device(dev);
0160
0161 按类别ID搜索（以类似的方式迭代）::
0162
0163 pci_get_class(CLASS_ID, dev)
0164
0165 通过供应商/设备和子系统供应商/设备ID进行搜索::
0166
0167 pci_get_subsys(VENDOR_ID,DEVICE_ID, SUBSYS_VENDOR_ID, SUBSYS_DEVICE_ID, dev).
0168
0169 你可以使用常数 ``PCI_ANY_ID`` 作为 ``VENDOR_ID`` 或 ``DEVICE_ID`` 的通
0170 配符替代。例如，这允许搜索来自一个特定供应商的任何设备。
0171
0172 这些函数是热拔插安全的。它们会增加它们所返回的 ``pci_dev`` 的参考计数。你最终
0173 必须通过调用 ``pci_dev_put()`` 来减少这些设备上的参考计数（可能在模块卸载时）。
0174
0175
0176 设备初始化步骤
0177 ==============
0178
0179 正如介绍中所指出的，大多数PCI驱动需要以下步骤进行设备初始化：
0180
0181 - 启用设备
0182 - 请求MMIO/IOP资源
0183 - 设置DMA掩码大小（对于流式和一致的DMA）
0184 - 分配和初始化共享控制数据（pci_allocate_coherent()）
0185 - 访问设备配置空间(如果需要)
0186 - 注册IRQ处理程序（request_irq()）
0187 - 初始化non-PCI（即芯片的LAN/SCSI/等部分）
0188 - 启用DMA/处理引擎
0189
0190 驱动程序可以在任何时候访问PCI配置空间寄存器。（嗯，几乎如此。当运行BIST时，配置
0191 空间可以消失......但这只会导致PCI总线主控中止，读取配置将返回垃圾值）。）
0192
0193
0194 启用PCI设备
0195 -----------
0196 在接触任何设备寄存器之前，驱动程序需要通过调用 ``pci_enable_device()`` 启用
0197 PCI设备。这将:
0198
0199 - 唤醒处于暂停状态的设备。
0200 - 分配设备的I/O和内存区域（如果BIOS没有这样做）。
0201 - 分配一个IRQ（如果BIOS没有）。
0202
0203 .. note::
0204 pci_enable_device() 可能失败，检查返回值。
0205
0206 .. warning::
0207 OS BUG：在启用这些资源之前，我们没有检查资源分配情况。如果我们在调用
0208 之前调用pci_request_resources()，这个顺序会更合理。目前，当两个设备被分配
0209 了相同的范围时，设备驱动无法检测到这个错误。这不是一个常见的问题，不太可能很快
0210 得到修复。
0211
0212 这个问题之前已经讨论过了，但从2.6.19开始没有改变：
0213 https://lore.kernel.org/r/20060302180025.GC28895@flint.arm.linux.org.uk/
0214
0215
0216 pci_set_master()将通过设置PCI_COMMAND寄存器中的总线主控位来启用DMA。
0217 ``pci_clear_master()`` 将通过清除总线主控位来禁用DMA，它还修复了延迟计时器的
0218 值，如果它被BIOS设置成假的。
0219
0220 如果PCI设备可以使用 ``PCI Memory-Write-Invalidate`` 事务，请调用 ``pci_set_mwi()`` 。
0221 这将启用 ``Mem-Wr-Inval`` 的 ``PCI_COMMAND`` 位，也确保缓存行大小寄存器被正确设置。检
0222 查 ``pci_set_mwi()`` 的返回值，因为不是所有的架构或芯片组都支持 ``Memory-Write-Invalidate`` 。
0223 另外，如果 ``Mem-Wr-Inval`` 是好的，但不是必须的，可以调用 ``pci_try_set_mwi()`` ，让
0224 系统尽最大努力来启用 ``Mem-Wr-Inval`` 。
0225
0226
0227 请求MMIO/IOP资源
0228 ----------------
0229 内存（MMIO）和I/O端口地址不应该直接从PCI设备配置空间中读取。使用 ``pci_dev`` 结构体
0230 中的值，因为PCI “总线地址”可能已经被arch/chip-set特定的内核支持重新映射为“主机物理”
0231 地址。
0232
0233 参见io_mapping函数，了解如何访问设备寄存器或设备内存。
0234
0235 设备驱动需要调用 ``pci_request_region()`` 来确认没有其他设备已经在使用相同的地址
0236 资源。反之，驱动应该在调用 ``pci_disable_device()`` 之后调用 ``pci_release_region()`` 。
0237 这个想法是为了防止两个设备在同一地址范围内发生冲突。
0238
0239 .. tip::
0240 见上面的操作系统BUG注释。目前(2.6.19)，驱动程序只能在调用pci_enable_device()
0241 后确定MMIO和IO端口资源的可用性。
0242
0243 ``pci_request_region()`` 的通用风格是 ``request_mem_region()`` （用于MMIO
0244 范围）和 ``request_region()`` （用于IO端口范围）。对于那些不被 "正常 "PCI BAR描
0245 述的地址资源，使用这些方法。
0246
0247 也请看下面的 ``pci_request_selected_regions()`` 。
0248
0249
0250 设置DMA掩码大小
0251 ---------------
0252 .. note::
0253 如果下面有什么不明白的地方，请参考使用通用设备的动态DMA映射。本节只是提醒大家，
0254 驱动程序需要说明设备的DMA功能，并不是DMA接口的权威来源。
0255
0256 虽然所有的驱动程序都应该明确指出PCI总线主控的DMA功能（如32位或64位），但对于流式
0257 数据来说，具有超过32位总线主站功能的设备需要驱动程序通过调用带有适当参数的
0258 ``dma_set_mask()`` 来“注册”这种功能。一般来说，在系统RAM高于4G物理地址的情
0259 况下，这允许更有效的DMA。
0260
0261 所有PCI-X和PCIe兼容设备的驱动程序必须调用 ``dma_set_mask()`` ，因为它们
0262 是64位DMA设备。
0263
0264 同样，如果设备可以通过调用 ``dma_set_coherent_mask()`` 直接寻址到
0265 4G物理地址以上的系统RAM中的“一致性内存”，那么驱动程序也必须“注册”这种功能。同
0266 样，这包括所有PCI-X和PCIe兼容设备的驱动程序。许多64位“PCI”设备（在PCI-X之前）
0267 和一些PCI-X设备对有效载荷（“流式”）数据具有64位DMA功能，但对控制（“一致性”）数
0268 据则没有。
0269
0270
0271 设置共享控制数据
0272 ----------------
0273 一旦DMA掩码设置完毕，驱动程序就可以分配“一致的”（又称共享的）内存。参见使用通
0274 用设备的动态DMA映射，了解DMA API的完整描述。本节只是提醒大家，需要在设备上启
0275 用DMA之前完成。
0276
0277
0278 初始化设备寄存器
0279 ----------------
0280 一些驱动程序需要对特定的“功能”字段进行编程，或对其他“供应商专用”寄存器进行初始
0281 化或重置。例如，清除挂起的中断。
0282
0283
0284 注册IRQ处理函数
0285 ---------------
0286 虽然调用 ``request_irq()`` 是这里描述的最后一步，但这往往只是初始化设备的另
0287 一个中间步骤。这一步通常可以推迟到设备被打开使用时进行。
0288
0289 所有IRQ线的中断处理程序都应该用 ``IRQF_SHARED`` 注册，并使用devid将IRQ映射
0290 到设备（记住，所有的PCI IRQ线都可以共享）。
0291
0292 ``request_irq()`` 将把一个中断处理程序和设备句柄与一个中断号联系起来。历史上，
0293 中断号码代表从PCI设备到中断控制器的IRQ线。在MSI和MSI-X中（更多内容见下文），中
0294 断号是CPU的一个“向量”。
0295
0296 ``request_irq()`` 也启用中断。在注册中断处理程序之前，请确保设备是静止的，并且
0297 没有任何中断等待。
0298
0299 MSI和MSI-X是PCI功能。两者都是“消息信号中断”，通过向本地APIC的DMA写入来向CPU发
0300 送中断。MSI和MSI-X的根本区别在于如何分配多个“向量”。MSI需要连续的向量块，而
0301 MSI-X可以分配几个单独的向量。
0302
0303 在调用 ``request_irq()`` 之前，可以通过调用 ``pci_alloc_irq_vectors()``
0304 的PCI_IRQ_MSI和/或PCI_IRQ_MSIX标志来启用MSI功能。这将导致PCI支持将CPU向量数
0305 据编程到PCI设备功能寄存器中。许多架构、芯片组或BIOS不支持MSI或MSI-X，调用
0306 ``pci_alloc_irq_vectors`` 时只使用PCI_IRQ_MSI和PCI_IRQ_MSIX标志会失败，
0307 所以尽量也要指定 ``PCI_IRQ_LEGACY`` 。
0308
0309 对MSI/MSI-X和传统INTx有不同中断处理程序的驱动程序应该在调用
0310 ``pci_alloc_irq_vectors`` 后根据 ``pci_dev``结构体中的 ``msi_enabled``
0311 和 ``msix_enabled`` 标志选择正确的处理程序。
0312
0313 使用MSI有（至少）两个真正好的理由：
0314
0315 1) 根据定义，MSI是一个排他性的中断向量。这意味着中断处理程序不需要验证其设备是
0316 否引起了中断。
0317
0318 2) MSI避免了DMA/IRQ竞争条件。到主机内存的DMA被保证在MSI交付时对主机CPU是可
0319 见的。这对数据一致性和避
0320
0321 3) 免控制数据过期都很重要。这个保证允许驱动程序省略MMIO读取，以刷新DMA流。
0322
0323 参见drivers/infiniband/hw/mthca/或drivers/net/tg3.c了解MSI/MSI-X的使
0324 用实例。
0325
0326
0327 PCI设备关闭
0328 ===========
0329
0330 当一个PCI设备驱动程序被卸载时，需要执行以下大部分步骤:
0331
0332 - 禁用设备产生的IRQ
0333 - 释放IRQ（free_irq()）
0334 - 停止所有DMA活动
0335 - 释放DMA缓冲区（包括流式和一致的）
0336 - 从其他子系统（例如scsi或netdev）上取消注册
0337 - 禁用设备对MMIO/IO端口地址的响应
0338 - 释放MMIO/IO端口资源
0339
0340
0341 停止设备上的IRQ
0342 ---------------
0343 如何做到这一点是针对芯片/设备的。如果不这样做，如果（也只有在）IRQ与另一个设备
0344 共享，就会出现“尖叫中断”的可能性。
0345
0346 当共享的IRQ处理程序被“解钩”时，使用同一IRQ线的其余设备仍然需要启用该IRQ。因此，
0347 如果“脱钩”的设备断言IRQ线，假设它是其余设备中的一个断言IRQ线，系统将作出反应。
0348 由于其他设备都不会处理这个IRQ，系统将“挂起”，直到它决定这个IRQ不会被处理并屏蔽
0349 这个IRQ（100,000次之后）。一旦共享的IRQ被屏蔽，其余设备将停止正常工作。这不是
0350 一个好事情。
0351
0352 这是使用MSI或MSI-X的另一个原因，如果它可用的话。MSI和MSI-X被定义为独占中断，
0353 因此不容易受到“尖叫中断”问题的影响。
0354
0355 释放IRQ
0356 -------
0357 一旦设备被静止（不再有IRQ），就可以调用free_irq()。这个函数将在任何待处理
0358 的IRQ被处理后返回控制，从该IRQ上“解钩”驱动程序的IRQ处理程序，最后如果没有人
0359 使用该IRQ，则释放它。
0360
0361
0362 停止所有DMA活动
0363 ---------------
0364 在试图取消分配DMA控制数据之前，停止所有的DMA操作是非常重要的。如果不这样做，
0365 可能会导致内存损坏、挂起，在某些芯片组上还会导致硬崩溃。
0366
0367 在停止IRQ后停止DMA可以避免IRQ处理程序可能重新启动DMA引擎的竞争。
0368
0369 虽然这个步骤听起来很明显，也很琐碎，但过去有几个“成熟”的驱动程序没有做好这个
0370 步骤。
0371
0372
0373 释放DMA缓冲区
0374 -------------
0375 一旦DMA被停止，首先要清理流式DMA。即取消数据缓冲区的映射，如果有的话，将缓
0376 冲区返回给“上游”所有者。
0377
0378 然后清理包含控制数据的“一致的”缓冲区。
0379
0380 关于取消映射接口的细节，请参见Documentation/core-api/dma-api.rst。
0381
0382
0383 从其他子系统取消注册
0384 --------------------
0385 大多数低级别的PCI设备驱动程序支持其他一些子系统，如USB、ALSA、SCSI、NetDev、
0386 Infiniband等。请确保你的驱动程序没有从其他子系统中丢失资源。如果发生这种情况，
0387 典型的症状是当子系统试图调用已经卸载的驱动程序时，会出现Oops（恐慌）。
0388
0389
0390 禁止设备对MMIO/IO端口地址做出响应
0391 ---------------------------------
0392 io_unmap() MMIO或IO端口资源，然后调用pci_disable_device()。
0393 这与pci_enable_device()对称相反。
0394 在调用pci_disable_device()后不要访问设备寄存器。
0395
0396
0397 释放MMIO/IO端口资源
0398 -------------------
0399 调用pci_release_region()来标记MMIO或IO端口范围为可用。
0400 如果不这样做，通常会导致无法重新加载驱动程序。
0401
0402
0403
0404
0405 如何访问PCI配置空间
0406 ===================
0407
0408 你可以使用 `pci_(read|write)_config_(byte|word|dword)` 来访问由
0409 `struct pci_dev *` 表示的设备的配置空间。所有这些函数在成功时返回0，或者返回一个
0410 错误代码（ `PCIBIOS_...` ），这个错误代码可以通过pcibios_strerror翻译成文本字
0411 符串。大多数驱动程序希望对有效的PCI设备的访问不会失败。
0412
0413 如果你没有可用的pci_dev结构体，你可以调用
0414 `pci_bus_(read|write)_config_(byte|word|dword)` 来访问一个给定的设备和该总
0415 线上的功能。
0416
0417 如果你访问配置头的标准部分的字段，请使用<linux/pci.h>中声明的位置和位的符号名称。
0418
0419 如果你需要访问扩展的PCI功能寄存器，只要为特定的功能调用pci_find_capability()，
0420 它就会为你找到相应的寄存器块。
0421
0422
0423 其它有趣的函数
0424 ==============
0425
0426 ============================= =================================================
0427 pci_get_domain_bus_and_slot() 找到与给定的域、总线和槽以及编号相对应的pci_dev。
0428 如果找到该设备，它的引用计数就会增加。
0429 pci_set_power_state() 设置PCI电源管理状态（0=D0 ... 3=D3
0430 pci_find_capability() 在设备的功能列表中找到指定的功能
0431 pci_resource_start() 返回一个给定的PCI区域的总线起始地址
0432 pci_resource_end() 返回给定PCI区域的总线末端地址
0433 pci_resource_len() 返回一个PCI区域的字节长度
0434 pci_set_drvdata() 为一个pci_dev设置私有驱动数据指针
0435 pci_get_drvdata() 返回一个pci_dev的私有驱动数据指针
0436 pci_set_mwi() 启用设备内存写无效
0437 pci_clear_mwi() 关闭设备内存写无效
0438 ============================= =================================================
0439
0440
0441 杂项提示
0442 ========
0443
0444 当向用户显示PCI设备名称时(例如，当驱动程序想告诉用户它找到了什么卡时)，请使
0445 用pci_name(pci_dev)。
0446
0447 始终通过对pci_dev结构体的指针来引用PCI设备。所有的PCI层函数都使用这个标识，
0448 它是唯一合理的标识。除了非常特殊的目的，不要使用总线/插槽/功能号————在有多个
0449 主总线的系统上，它们的语义可能相当复杂。
0450
0451 不要试图在你的驱动程序中开启快速寻址周期写入功能。总线上的所有设备都需要有这样
0452 的功能，所以这需要由平台和通用代码来处理，而不是由单个驱动程序来处理。
0453
0454
0455 供应商和设备标识
0456 ================
0457
0458 不要在include/linux/pci_ids.h中添加新的设备或供应商ID，除非它们是在多个驱
0459 动程序中共享。如果有需要的话，你可以在你的驱动程序中添加私有定义，或者直接使用
0460 普通的十六进制常量。
0461
0462 设备ID是任意的十六进制数字（厂商控制），通常只在一个地方使用，即pci_device_id
0463 表。
0464
0465 请务必提交新的供应商/设备ID到https://pci-ids.ucw.cz/。在
0466 https://github.com/pciutils/pciids，有一个pci.ids文件的镜像。
0467
0468
0469 过时的函数
0470 ==========
0471
0472 当你试图将一个旧的驱动程序移植到新的PCI接口时，你可能会遇到几个函数。它们不再存
0473 在于内核中，因为它们与热插拔或PCI域或具有健全的锁不兼容。
0474
0475 ================= ===================================
0476 pci_find_device() 被pci_get_device()取代
0477 pci_find_subsys() 被pci_get_subsys()取代
0478 pci_find_slot() 被pci_get_domain_bus_and_slot()取代
0479 pci_get_slot() 被pci_get_domain_bus_and_slot()取代
0480 ================= ===================================
0481
0482 另一种方法是传统的PCI设备驱动，即走PCI设备列表。这仍然是可能的，但不鼓励这样做。
0483
0484
0485 MMIO空间和“写通知”
0486 ==================
0487
0488 将驱动程序从使用I/O端口空间转换为使用MMIO空间，通常需要一些额外的改变。具体来说，
0489 需要处理“写通知”。许多驱动程序（如tg3，acenic，sym53c8xx_2）已经做了这个。I/O
0490 端口空间保证写事务在CPU继续之前到达PCI设备。对MMIO空间的写入允许CPU在事务到达PCI
0491 设备之前继续。HW weenies称这为“写通知”，因为在事务到达目的地之前，写的完成被“通知”
0492 给CPU。
0493
0494 因此，对时间敏感的代码应该添加readl()，CPU在做其他工作之前应该等待。经典的“位脉冲”
0495 序列对I/O端口空间很有效::
0496
0497 for (i = 8; --i; val >>= 1) {
0498 outb(val & 1, ioport_reg); /* 置位 */
0499 udelay(10);
0500 }
0501
0502 对MMIO空间来说，同样的顺序应该是::
0503
0504 for (i = 8; --i; val >>= 1) {
0505 writeb(val & 1, mmio_reg); /* 置位 */
0506 readb(safe_mmio_reg); /* 刷新写通知 */
0507 udelay(10);
0508 }
0509
0510 重要的是， ``safe_mmio_reg`` 不能有任何干扰设备正确操作的副作用。
0511
0512 另一种需要注意的情况是在重置PCI设备时。使用PCI配置空间读数来刷新writeel()。如果预期
0513 PCI设备不响应readl()，这将在所有平台上优雅地处理PCI主控器的中止。大多数x86平台将允许
0514 MMIO读取主控中止（又称“软失败”），并返回垃圾（例如~0）。但许多RISC平台会崩溃（又称“硬失败”）。
