搞Linux PCI驱动pci_driver绝对是你绕不开的第一个结构体。上一篇我们把PCI总线枚举、配置空间、BAR资源这些基础盘讲完了设备在总线上是怎么被发现的、怎么读它的厂商ID和类码这些底子打好了接下来最核心的问题就是驱动侧怎么把设备接住。这篇就顺着Linux PCI驱动框架往下走把pci_driver、probe、BAR映射、中断、DMA这一整条线串起来重点说清楚那些头文件里看不出来、但你在工作中一定会撞上的问题。这篇内容适合两类人看一是刚接触Linux驱动开发搞不懂pci_driver和平台驱动、字符设备驱动到底有啥区别的初学者二是已经在写PCI驱动但经常在probe不触发、读BAR全F、DMA乱飞这些坑里打转的工程师。我会把框架的构成、每个回调时机的来龙去脉以及我实测过的踩坑记录都铺开讲尽量做到你照着这篇文章能把一个最小可用的PCI字符设备驱动从零搭起来。1. 从总体看PCI驱动框架它到底在解决什么问题先别急着看结构体先想一个问题一个PCI设备驱动本质上需要做哪些事无非是告诉内核“我能管哪个设备”、设备被发现时初始化它、提供用户态操作接口、在设备移除或驱动卸载时干净地收场。这个描述听着跟I2C、SPI驱动差不多但PCI驱动的特殊之处在于PCI设备是可以热插拔的、由总线动态枚举出来的而且它拿到的是系统物理地址空间里的一段真实映射还承担着高性能DMA传输的任务。所以Linux PCI驱动框架不是一套孤立的东西它挂在设备模型Driver Model这棵大树上。总线pci_bus、设备pci_dev、驱动pci_driver这三者通过bus_type结构里的匹配和探测机制联动。你在驱动里写的probe函数本质上不是一个“你想调就调”的函数而是设备模型在发现PCI总线上出现一个与你的ID表匹配的设备后自动回调你的函数。理解这一点后面很多问题就有了答案为什么insmod之后probe没进来八成是设备模型的匹配机制认为“这个设备跟你这个驱动没关系”。还有一个经常被忽略的点PCI驱动框架把配置空间访问、资源申请、中断申请这些操作抽象成了标准API而不是让你直接去操作IO端口。内核里pci_read_config_byte、pci_enable_device、pci_request_regions这些接口背后是不同架构、不同PCI主机控制器的一大堆适配代码。你只要用这些接口驱动就能在x86、ARM、RISC-V上通用。这个抽象层的价值写驱动的时候可能感觉不明显真让你从零去对着PCIe控制器寄存器写配置空间读取代码的时候你就会知道这套框架替你省了多少事。整个框架围绕pci_driver展开大体可以分成四块第一块是匹配与生命周期管理id_table、probe、remove第二块是资源管理BAR物理地址获取、ioremap映射第三块是中断机制INTx、MSI/MSI-X第四块是DMA数据传输。下面逐个拆。2. pci_driver核心结构把字段先翻译成人话直接贴一个典型的pci_driver结构体定义然后逐字段说它干嘛的static const struct pci_device_id mypci_ids[] { { PCI_DEVICE(0x1234, 0x5678) }, { } }; static struct pci_driver mypci_driver { .name mypci, .id_table mypci_ids, .probe mypci_probe, .remove mypci_remove, .shutdown mypci_shutdown, .suspend mypci_suspend, .resume mypci_resume, .driver { .pm mypci_pm_ops, }, };name就是驱动的名字会在sysfs里体现。真正决定驱动和设备能不能“对上眼”的是id_table。这个表里放的是pci_device_id数组内核遍历设备时拿设备实际的vendor、device、subvendor、subdevice、class这些信息去跟这张表比对。比对通过probe被调用设备移除或驱动卸载时remove被调用。shutdown是系统关机时调用的用来把设备放到安全状态。suspend/resume则是电源管理用的对应系统休眠唤醒。这里有个容易被新手忽略的点probe和remove的调用时机是设备模型管着的不是你自己说了算。设备什么时候出现可能是开机时PCI总线枚举发现的也可能是你往PCIe槽里热插了一块卡。而你insmod一个驱动只会让内核去扫描一遍总线上现有的设备看看有没有跟id_table匹配的。设备已经绑定在别的驱动上或者设备还没被枚举出来你的probe就自然不会被调用。2.1 probe和remove的调用时机与返回值probe函数的原型是static int mypci_probe(struct pci_dev *dev, const struct pci_device_id *id);参数里的dev是内核帮你建好的pci_dev设备对象它包含了设备的全部信息vendor、device、资源、IRQ号、DMA掩码等。第二个参数id是匹配上的那张ID表项有时候一张表里有好几个设备型号靠这个参数就能在probe里区分硬件版本。probe返回0表示成功。返回负数内核就认为驱动跟这个设备“绑定失败”设备模型会把这个驱动从设备的driver列表里摘掉。很多新人在这里犯迷糊probe里执行到一半失败了返回-ENOMEM然后又改代码再insmod结果发现probe根本没被调用。这是因为设备模型认为上次绑定失败后这个驱动和设备已经“无缘”了你需要先unbind或者把上次失败留下的状态清理干净。实际开发里我习惯在probe开头就dev_info打印一下确定函数确实进来了再往下走能省掉很多“我以为它调了但其实没有”的排查时间。remove函数原型是static void mypci_remove(struct pci_dev *dev);它没有返回值因为remove阶段不允许失败内核不会再因为你的remove报了错而把设备恢复到probe状态。所以remove里的顺序问题非常讲究应该先注销中断、释放DMA缓冲、注销字符设备节点然后再释放映射和资源。顺序反了轻则资源泄漏重则直接触发内核崩溃因为中断回调里可能还在访问你已经释放掉的ioremap空间。2.2 id_table的匹配规则驱动和设备是怎么对上眼的pci_device_id的典型写法有几种/* 精确匹配vendor和devicesubvendor/subdevice用PCI_ANY_ID通配 */ { PCI_DEVICE(0x1234, 0x5678) }, /* 精确匹配到子系统厂商和设备适合板卡厂商区分自家子卡 */ { PCI_VDEVICE(0x1234, 0x5678) }, /* 按class匹配比如匹配所有网络控制器 */ { .class PCI_CLASS_NETWORK_ETHERNET 8, .class_mask 0xffff00 },PCI_VDEVICE这个宏会把subvendor设置为PCI_ANY_ID也就是说不管子卡是谁做的只要主vendor和设备ID对得上就行。PCI_DEVICE则匹配vendor、devicesubvendor和subdevice也都是PCI_ANY_ID。如果硬件厂商在同一个主芯片下做了好几个子型号它们共用同一个vendor/device但subdevice不同偏偏你想让一个驱动只管其中某几个子型号那就得自定义结构体字段{ .vendor 0x1234, .device 0x5678, .subvendor 0xabcd, .subdevice 0x0001, }class匹配要特别小心class字段在pci_device_id里存的是把PCI配置空间里的Class Code左移了8位的值所以匹配时也要带上对应的移位写法。这个移位规则是出了名的容易写错我见过有人拿PCI_CLASS_NETWORK_ETHERNET直接填进去结果怎么都不匹配最后翻内核头文件才明白要左移8位。另外ID表最后一项必须是{}空结构体作为结束标志MODULE_DEVICE_TABLE(pci, mypci_ids)这个宏也要保留它让modprobe能通过depmod生成的模块别名找到这个驱动否则手动insmod可以但modprobe可能加载不了。在ARM等嵌入式平台上还有一个of_match_table的概念。PCI设备驱动主要是靠vendor/device匹配但如果你要处理的PCI设备挂在OF设备树描述的节点下有些平台也允许用compatible字符串补充匹配。这个机制在Linux里存在但并不推荐作为PCI设备的主要匹配手段因为标准PCI枚举根本不需要设备树设备树只是提供了一些主机控制器和时钟的描述信息。3. probe为什么总是进不去匹配背后的完整链路很多人的第一个PCI驱动是这样死的insmod成功dmesg里啥也没有probe压根没进。想搞明白这个问题就得把pci_register_driver到probe之间的链路走一遍。pci_register_driver这个宏往上追最终调用的是__pci_register_driver它做的事情是把pci_driver里的driver成员注册到pci_bus_type这个总线类型上。总线类型注册驱动会触发driver_attach也就是对总线上每一个设备调用pci_bus_match用 id_table 去匹配。匹配上了再调用pci_device_probe这里面才会进到pci_call_probe最终调到你的probe函数。所以probe进不去的核心原因就是pci_bus_match觉得“这个设备跟你没关系”。设备模型是这么想的设备是在总线上的客观存在驱动只是它的一个“候选服务者”。一个PCI设备在没有驱动的时候照样可以被lspci看到只是没有driver绑定而已。你insmod了驱动内核不会“强行安排”设备给驱动而是查询设备的vendor/device是否在驱动的ID表里。3.1 匹配失败的八种原因现象可能原因排查手段probe未调用设备显示没有driverid_table里的vendor/device和实际设备不一致lspci -nn看实际ID和模块ID表对照probe未调用但ID表看起来是对的设备已经被另一个驱动绑定了ls -l /sys/bus/pci/devices/0000:01:00.0/driverprobe未调用insmod报错说无效参数驱动编译用的是不同内核版本的headers重新用当前内核源码树编译模块设备存在但/sys里都看不到设备没被枚举或者被controller屏蔽了lspci -v看设备是否在总线上必要时rescanprobe调用后返回了负值设备又被解绑probe中途失败没有清理已申请资源在probe每步失败前用dev_err打印匹配成功但probe只调用了一次后续insmod不再调用第一次probe失败driver和device状态没复位echo 1 /sys/bus/pci/devices/.../remove重新rescan设备树平台上probe不进设备树节点没配好或of_match_table没填检查设备树里PCI节点的compatible属性驱动是y编译进内核但启动时设备不存在probe没调用设备是后插的热插拔卡或者启动太早设备插入后触发rescanecho 1 /sys/bus/pci/rescan这里我要单独说一个经验pci_bus_match里如果ID表里有class匹配项优先级并不比vendor/device匹配低而且class匹配的字段是对齐过的。如果你同时填了vendor/device和class内核要求请求的所有字段都得匹配不是“或”的关系而是“与”的关系。这是个特别容易让老手翻车的地方因为直觉上你会觉得class是“兜底”的实际上它只是“额外条件”。3.2 热插拔与rescan对probe的影响PCIe热插拔在服务器场景里很常见但在嵌入式开发板上很多时候不是真的热插拔而是调试时反复插拔设备。这时候你会发现第一次插上去probe跑了后面拔了再插probe也可能不跑因为设备节点还残留在sysfs里。正确的操作是先移除设备节点再触发重新扫描echo 1 /sys/bus/pci/devices/0000:01:00.0/remove echo 1 /sys/bus/pci/rescan这两个操作会把PCI设备从总线模型里“删干净”再重新枚举新的pci_dev对象生成设备模型才会重新考虑把你的驱动绑上去。这个“先remove再rescan”的操作不仅对热插拔有用也是驱动迭代调试时最常用的自我救赎手段。如果你发现自己的驱动改了几行代码insmod后行为没变先别怀疑内核缓存看看是不是设备压根没重新probe。4. 资源申请与BAR空间映射从配置空间到MMIO匹配和probe只是前戏真正干活的是资源。PCI设备有几个重要的地址空间都通过BAR寄存器暴露给系统。BAR0到BAR5一共6个每个代表一段独立的地址区域可能是MMIO也可能是IO端口但PCIe时代IO空间基本废弃了绝大多数情况是MMIO。在驱动的视角里这些地址区域是物理地址你要通过ioremap把它们变成内核虚拟地址才能用CPU访问。4.1 先enable还是先request顺序别搞反一个非常常见的坑probe里用ioremap(pci_resource_start(dev, 0), pci_resource_len(dev, 0))拿到虚拟地址后直接readl读寄存器读出来全是0xffffffff。为什么会这样极大概率是你没先调用pci_enable_device。pci_enable_device做的事情是把设备配置空间里的Command寄存器打开使能IO和MMIO访问同时做DMA资源初始化。设备出厂默认情况下Command寄存器的Memory Space Enable位很可能就是0意味着设备的BAR空间根本没被映射到系统地址空间。你直接读地址上是空的读回来就是全F。正确顺序是ret pci_enable_device(dev); if (ret 0) return ret; ret pci_request_regions(dev, mypci); if (ret 0) { pci_disable_device(dev); return ret; }先enable再request_regions。pci_request_regions的作用是检查并保留这些BAR区域在系统IO/内存资源表里避免另一个驱动也来claim同一段地址。这个检查不是可选项万一有两个驱动都去ioremap同一段物理地址产生的bug极难排查。所以内核即使不强制你调用它你也应该在框架里把它当成强制步骤。另外注意pci_request_regions申请成功后在remove里要对应调用pci_release_regions。很多新手只记得pci_enable_device要配pci_disable_device却忘了release_regions结果反复insmod/rmmod之后/proc/iomem里全是残留的region标记后面insmod就老是报“resource busy”。4.2 一个标准的MMIO映射流程直接看代码块注释里写清楚每一步的意图static int mypci_probe(struct pci_dev *dev, const struct pci_device_id *id) { int ret; resource_size_t start, len; void __iomem *regs; /* 1. 使能设备打开MMIO/IO访问否则后面ioremap了也读不到数据 */ ret pci_enable_device(dev); if (ret 0) return ret; /* 2. 向内核资源管理系统声明这段BAR区域归本驱动所有 */ ret pci_request_regions(dev, mypci); if (ret 0) { pci_disable_device(dev); return ret; } /* 3. 获取BAR0的物理起始地址和长度 */ start pci_resource_start(dev, 0); len pci_resource_len(dev, 0); dev_info(dev-dev, BAR0: phys%pa len%pa\n, start, len); /* 4. 物理地址映射为内核虚拟地址注意返回的是__iomem指针 */ regs ioremap(start, len); if (!regs) { pci_release_regions(dev); pci_disable_device(dev); return -ENOMEM; } /* 5. 验证映射后能读到设备的寄存器通常读Vendor ID或版本号 */ dev_info(dev-dev, config read: %04x\n, ioread16(regs)); /* 6. 把regs保存到dev的drvdataremove里要用 */ pci_set_drvdata(dev, regs); return 0; } static void mypci_remove(struct pci_dev *dev) { void __iomem *regs pci_get_drvdata(dev); /* 释放顺序和申请顺序相反 */ if (regs) iounmap(regs); pci_release_regions(dev); pci_disable_device(dev); }这个流程里ioremap返回的指针类型是void __iomem *你不能像一个普通unsigned long *那样直接解引用而要用ioread32/iowrite32或readl/writel去访问。这些接口会做必要的内存屏障保证CPU访问和外设端的状态一致。如果你非要直接敲指针解引用在某些架构上会因为内存序的问题读到陈旧数据。这个“MMIO要用专门的读写接口”的规矩x86上可能感觉不明显在ARM上就是实打实的稳定性分水岭。4.3 新版内核的简化写法pcim_ *如果你用的是较新的内核版本5.x之后可以考虑用managed版本资源管理。pcim_enable_device、pcim_iomap_regions这类函数的好处是驱动的remove回调没写或者probe中途失败内核也会自动释放这些资源不会泄漏。static int mypci_probe(struct pci_dev *dev, const struct pci_device_id *id) { void __iomem *regs; int ret; ret pcim_enable_device(dev); if (ret 0) return ret; ret pcim_iomap_regions(dev, BIT(0), mypci); if (ret 0) return ret; regs pcim_iomap_table(dev)[0]; ... }pcim_iomap_table(dev)[0]就是BAR0映射后的虚拟地址。这套API我在新的板卡驱动里用得比较多因为它让remove函数变得很短很多资源释放逻辑都交给设备模型在驱动卸载时统一收尾。但对刚上手的人来说建议先把非managed那套手动映射流程彻底搞懂再切换到managed版本否则会不理解“为什么remove里没写iounmap也不会泄漏”背后的机制。5. 中断处理INTx、MSI与MSI-X怎么选PCI设备中断有几种形态。传统INTx中断是电平/边沿触发的共享中断线一个中断线可以被多个设备共享触发后内核逐个调用该线上的handler来判断是不是自己的设备。MSIMessage Signaled Interrupts则是设备直接往系统内存写一条特定消息来触发中断不再复用中断线。MSI-X是MSI的扩展版支持更多中断向量每个向量可以独立配置高吞吐网卡和NVMe SSD基本都依赖它。5.1 三种中断方式的对比类型中断线数量是否共享适合场景驱动注意事项INTx每设备最多4线是老设备、中断频率低的设备handler里要判断中断状态寄存器不是自己的中断要返回IRQ_NONEMSI每设备最多32向量否一般性能设备申请时用pci_alloc_irq_vectors减少向量数量可提高亲和性MSI-X每设备最多2048向量否高性能多队列设备每个向量可绑定不同CPU核心适合多队列处理我个人的看法是新设计的驱动能用MSI就尽量用MSI/MSI-X。MSI不仅中断处理效率高更重要的是它不需要在handler里做“是不是我的中断”这种轮询判断天然规避了共享中断线的麻烦。但MSI也有一个短板如果系统里PCIe RCRoot Complex对MSI消息地址支持不好或者设备驱动忘了调用pci_set_masterMSI中断就可能完全不触发。这个“忘了pci_set_master导致MSI不工作”的问题是我在实机上踩过最深的一个坑。我一度以为是自己中断号申请错了排查了一整天最后发现就是少了这一行。5.2 现代驱动里推荐的中断申请方式老式写法是直接request_irq(dev-irq, handler, ...)这个dev-irq是配置空间中断线寄存器给的值在MSI设备上不一定准。所以现在内核推荐用pci_alloc_irq_vectors动态分配int ret; int irq; ret pci_alloc_irq_vectors(dev, 1, 1, PCI_IRQ_MSI | PCI_IRQ_MSIX | PCI_IRQ_LEGACY); if (ret 0) return ret; irq pci_irq_vector(dev, 0); ret request_irq(irq, mypci_irq_handler, 0, mypci, dev); if (ret 0) { pci_free_irq_vectors(dev); return ret; }pci_alloc_irq_vectors的第一个参数是设备第二、三个参数是需要的向量数区间第四个参数是你允许的中断类型。内核会按照“MSI-X优先MSI其次最后INTx”的顺序去尝试分配最终给你申请到尽可能多的向量数。你拿到的中断号不一定是dev-irq而是pci_irq_vector(dev, index)。使用多个MSI-X向量时每个向量对应一个index分别给不同的队列。在remove里先free_irq再pci_free_irq_vectors。顺序别反否则中断处理函数还在跑向量已经被释放了典型的use-after-free。如果驱动没有使用pci_set_masterMSI也发不出来因为MSI本质上就是设备发起一个内存写操作来完成中断通知设备的bus master权限没开这个内存写就被拦住了。6. DMA高性能数据传输的核心PCI设备的强项就是DMA。网卡、存储卡、采集卡通通是靠DMA把数据直接塞到内存里才配得上“高性能”三个字。Linux内核给PCI驱动提供了两套DMA API一致性DMAConsistent DMA和流式DMAStreaming DMA。6.1 一致性DMA和流式DMA的区别一致性DMA用dma_alloc_coherent申请得到的内存是“CPU和设备都能访问且数据一致”的不需要额外的同步操作。适合那些设备持续读写的数据结构比如DMA描述符环、控制块。这个API返回两个值CPU虚拟地址和dma_addr_t总线地址。注意dma_addr_t不是物理地址它是设备视角的地址。在很多平台上它恰好和物理地址一样但你不应该依赖这一点要把它当作不透明句柄传给设备。流式DMA用dma_map_single/dma_map_page/dma_map_sg申请针对的是你原本就有的内核缓冲区比如kmalloc出来的内存、或者page用完之后要dma_unmap_single。它和一致性DMA的区别在于流式DMA映射期间CPU和设备访问这块内存需要通过dma_sync_single_for_device和dma_sync_single_for_cpu来保证一致性。在驱动的实际应用场景里最简单的数据搬运往往是设备把数据DMA到一个预先分配的缓冲区然后通过中断通知CPU去读。这个缓冲区用什么方式分配我最常用的方案是probe阶段用dma_alloc_coherent分配一块环形缓冲区设备一直往里面写CPU在中断里读走并重置写指针。这套逻辑简单、稳定、不用频繁map/unmap非常适合嵌入式数据采集。6.2 DMA方向和同步方向错了数据全是乱的DMA方向分几种DMA_TO_DEVICECPU往设备写、DMA_FROM_DEVICE设备往CPU写、DMA_BIDIRECTIONAL双向。方向错了轻则数据错乱重则缓存一致性问题导致读到的数据是旧值。典型错误场景你kmalloc了一个缓冲区用dma_map_single(dev-dev, buf, len, DMA_FROM_DEVICE)映射好了设备DMA写完触发中断你在中断里直接读buf发现数据不对。原因很可能是你漏了dma_sync_single_for_cpu。在DMA写内存之后CPU的cache里可能还有这块内存的旧副本直接从cache读就是旧的。正确做法是/* 设备写完数据后CPU要读之前必须先做一次sync */ dma_sync_single_for_cpu(dev-dev, dma_handle, len, DMA_FROM_DEVICE); /* 此时再读buf数据才是设备写进去的 */反过来如果CPU先写数据再让设备去读就要在写完后调用dma_sync_single_for_device。这个同步操作在使用了IOMMU或者非一致性的ARM平台上尤其关键。x86平台上因为硬件cache一致性做得比较好漏了sync可能偶尔不报错但这个“偶尔”就是一个定时炸弹哪天换了平台就炸。还有一点必须强调dma_alloc_coherent返回的dma_handle是给设备用的不是给CPU直接当物理地址用的。不少新人会用phys_to_virt(dma_handle)去转CPU地址这在某些平台上可能是对的但在有IOMMU的平台上就是完全错误的。你要记住CPU访问用dma_alloc_coherent返回的那个虚拟地址设备访问用dma_handle这两个值应该被当作两个独立的句柄使用。7. 现在内核推荐的写法一个最小PCI字符设备驱动理论讲了一堆不如来一个能编译、能加载的最小驱动骨架。这个例子综合了前面说的匹配、probe、ioremap和miscdevice字符设备框架方便你直接抄作业。#include linux/module.h #include linux/pci.h #include linux/miscdevice.h #include linux/fs.h #include linux/uaccess.h #include linux/io.h #define MYPCI_BAR 0 #define MYPCI_BAR_SIZE 0x1000 static void __iomem *mypci_regs; static ssize_t mypci_reg_read(struct file *file, char __user *buf, size_t count, loff_t *ppos) { u32 val; /* 简单起见只支持4字节对齐的读操作 */ if (count sizeof(val)) return -EINVAL; val ioread32(mypci_regs (*ppos 0xff)); if (copy_to_user(buf, val, sizeof(val))) return -EFAULT; return sizeof(val); } static const struct file_operations mypci_fops { .owner THIS_MODULE, .read mypci_reg_read, }; static struct miscdevice mypci_miscdev { .minor MISC_DYNAMIC_MINOR, .name mypci, .fops mypci_fops, }; static int mypci_probe(struct pci_dev *dev, const struct pci_device_id *id) { int ret; /* 使能设备并申请BAR资源 */ ret pcim_enable_device(dev); if (ret 0) return ret; ret pcim_iomap_regions(dev, BIT(MYPCI_BAR), mypci); if (ret 0) { dev_err(dev-dev, failed to iomap regions: %d\n, ret); return ret; } mypci_regs pcim_iomap_table(dev)[MYPCI_BAR]; if (!mypci_regs) { dev_err(dev-dev, invalid iomap table\n); return -ENOMEM; } pci_set_master(dev); /* 注册misc设备用户态就能通过/dev/mypci访问 */ ret misc_register(mypci_miscdev); if (ret 0) { dev_err(dev-dev, misc_register failed: %d\n, ret); return ret; } dev_info(dev-dev, mypci probed, regs%p\n, mypci_regs); return 0; } static void mypci_remove(struct pci_dev *dev) { misc_deregister(mypci_miscdev); dev_info(dev-dev, mypci removed\n); } static const struct pci_device_id mypci_ids[] { { PCI_DEVICE(0x1234, 0x5678) }, { } }; MODULE_DEVICE_TABLE(pci, mypci_ids); static struct pci_driver mypci_driver { .name mypci, .id_table mypci_ids, .probe mypci_probe, .remove mypci_remove, }; module_pci_driver(mypci_driver); MODULE_LICENSE(GPL); MODULE_DESCRIPTION(Minimal PCI character device driver);这个例子里用的是managed API所以remove里不需要手动iounmap和pci_release_regionspcim_ *系列会在设备销毁时自动收尾。misc_register是最简单的字符设备注册方式内核自动分配主设备号在/dev下生成一个名为mypci的设备节点。驱动加载后你可以这样测试modprobe mypci ls -l /dev/mypci cat /dev/mypci | hexdump如果设备硬件就绪读到的前两个字节应该就是设备的vendor ID。这个验证方法特别直接我在拿到新板卡时第一件事就是写个最小驱动probe里读vendor ID确认映射和配置空间访问通路是健康的再往后续功能加。8. 实战排障PCI驱动开发最常见的6个问题开发过程中我积累了一个自己的排障清单几乎每个PCI驱动问题最后都能归到这几类里直接整理成表格问题现象常见原因排查动作insmod后probe没有被调用id_table不匹配、设备已被其他驱动绑定、设备未rescanlspci -nn核对ID检查/sys/bus/pci/drivers/下有没有别的驱动占着必要时手动rescan读BAR返回全F没有调用pci_enable_device、设备没上电、BAR被映射成IO空间确认probe里先enable再ioremap用lspci -vvv看BAR的flags和地址pci_request_regions返回-EBUSY同一BAR被之前的驱动占用或残留region没有释放cat /proc/iomem查对应物理地址段被谁占了确认之前rmmod时remove有没有执行完整中断不触发没调用pci_set_master、MSI/MSI-X申请失败、IRQ号错误确认probe里有pci_set_master查看/proc/interrupts里对应中断号是否有设备DMA传输出错或数据错乱DMA方向不对、漏了dma_sync_single_*、用错了地址核对方向宏核对CPU虚拟地址和dma_handle是不是用反了remove时内核崩溃中断还没free就释放了ioremap、misc设备还在被访问就注销先free_irq再iounmap再misc_deregister检查打开设备节点的fd是否还挂着这里有个比较隐蔽的心得想说一下PCI驱动排障信息的优先级是dmesg大于一切。内核在驱动加载和probe失败时会打印一堆pci 0000:01:00.0: ...开头的信息很多人看dmesg只盯着自己dev_err打出来的内容却忽略了前半段设备模型自己打印的“driver不匹配”或者“resource busy”提示。尤其是-EPROBE_DEFER、-EBUSY这类返回值dmesg里往往已经写得很直白只是藏在了一大堆输出中间。我建议调试时先用dmesg -w开一个窗口然后insmod把内核从模块加载到probe结束这段时间完整日志抓出来再对着日志逐行分析。还有一点板卡挂上去之后不要急着写驱动代码先lspci -vvv看一遍设备配置空间。里面包括了设备ID、BAR地址、中断线、MSI能力寄存器、链路状态信息。这些信息能帮你判断硬件上电和枚举是否正常。如果lspci里BAR地址全是0说明设备没有被正确分配资源这时候驱动写再多也是白搭问题在RC侧或者BIOS/固件的地址分配上。9. 我对这套框架的个人体会这套PCI驱动框架我前前后后摸了好几年最大的感受是它是一个把设备模型、资源管理、并发模型、DMA一致性全部串起来的综合体。写字符设备驱动你可能只需要懂file_operations和miscdevice写平台驱动懂platform driver和设备树就行但写PCI驱动你得同时理解总线枚举、配置空间访问、MMIO映射规则、中断子系统、DMA API、电源管理。这是Linux驱动开发里最全面的“训练场”啃完一遍你再去看I2C驱动、SPI驱动、甚至V4L2驱动框架都会觉得轻松很多。如果非要说一个最重要的建议别跳过手动管理资源的老API先从pci_enable_devicepci_request_regionsioremap这套流程开始。虽然新内核的managed API写着省事但理解背后的申请、释放、失败路径对你排查问题起决定性作用。等老流程彻底吃透了再切换到pcim_ *或者设备模型自动管理的写法。PCI驱动框架的内容非常深这一篇讲完了驱动侧的主干链路还有不少硬核话题没有展开比如设备树/ACPI下的PCI资源分配、SR-IOV虚拟功能驱动、PCIe AER错误处理、VPD配置空间读取这些都是很好的后续选题。我后面会继续写这个系列把那些“看得见但不在标准文档里”的坑一个一个填上。
Linux PCI驱动开发全解析：pci_driver、probe、BAR映射与DMA实践
搞Linux PCI驱动pci_driver绝对是你绕不开的第一个结构体。上一篇我们把PCI总线枚举、配置空间、BAR资源这些基础盘讲完了设备在总线上是怎么被发现的、怎么读它的厂商ID和类码这些底子打好了接下来最核心的问题就是驱动侧怎么把设备接住。这篇就顺着Linux PCI驱动框架往下走把pci_driver、probe、BAR映射、中断、DMA这一整条线串起来重点说清楚那些头文件里看不出来、但你在工作中一定会撞上的问题。这篇内容适合两类人看一是刚接触Linux驱动开发搞不懂pci_driver和平台驱动、字符设备驱动到底有啥区别的初学者二是已经在写PCI驱动但经常在probe不触发、读BAR全F、DMA乱飞这些坑里打转的工程师。我会把框架的构成、每个回调时机的来龙去脉以及我实测过的踩坑记录都铺开讲尽量做到你照着这篇文章能把一个最小可用的PCI字符设备驱动从零搭起来。1. 从总体看PCI驱动框架它到底在解决什么问题先别急着看结构体先想一个问题一个PCI设备驱动本质上需要做哪些事无非是告诉内核“我能管哪个设备”、设备被发现时初始化它、提供用户态操作接口、在设备移除或驱动卸载时干净地收场。这个描述听着跟I2C、SPI驱动差不多但PCI驱动的特殊之处在于PCI设备是可以热插拔的、由总线动态枚举出来的而且它拿到的是系统物理地址空间里的一段真实映射还承担着高性能DMA传输的任务。所以Linux PCI驱动框架不是一套孤立的东西它挂在设备模型Driver Model这棵大树上。总线pci_bus、设备pci_dev、驱动pci_driver这三者通过bus_type结构里的匹配和探测机制联动。你在驱动里写的probe函数本质上不是一个“你想调就调”的函数而是设备模型在发现PCI总线上出现一个与你的ID表匹配的设备后自动回调你的函数。理解这一点后面很多问题就有了答案为什么insmod之后probe没进来八成是设备模型的匹配机制认为“这个设备跟你这个驱动没关系”。还有一个经常被忽略的点PCI驱动框架把配置空间访问、资源申请、中断申请这些操作抽象成了标准API而不是让你直接去操作IO端口。内核里pci_read_config_byte、pci_enable_device、pci_request_regions这些接口背后是不同架构、不同PCI主机控制器的一大堆适配代码。你只要用这些接口驱动就能在x86、ARM、RISC-V上通用。这个抽象层的价值写驱动的时候可能感觉不明显真让你从零去对着PCIe控制器寄存器写配置空间读取代码的时候你就会知道这套框架替你省了多少事。整个框架围绕pci_driver展开大体可以分成四块第一块是匹配与生命周期管理id_table、probe、remove第二块是资源管理BAR物理地址获取、ioremap映射第三块是中断机制INTx、MSI/MSI-X第四块是DMA数据传输。下面逐个拆。2. pci_driver核心结构把字段先翻译成人话直接贴一个典型的pci_driver结构体定义然后逐字段说它干嘛的static const struct pci_device_id mypci_ids[] { { PCI_DEVICE(0x1234, 0x5678) }, { } }; static struct pci_driver mypci_driver { .name mypci, .id_table mypci_ids, .probe mypci_probe, .remove mypci_remove, .shutdown mypci_shutdown, .suspend mypci_suspend, .resume mypci_resume, .driver { .pm mypci_pm_ops, }, };name就是驱动的名字会在sysfs里体现。真正决定驱动和设备能不能“对上眼”的是id_table。这个表里放的是pci_device_id数组内核遍历设备时拿设备实际的vendor、device、subvendor、subdevice、class这些信息去跟这张表比对。比对通过probe被调用设备移除或驱动卸载时remove被调用。shutdown是系统关机时调用的用来把设备放到安全状态。suspend/resume则是电源管理用的对应系统休眠唤醒。这里有个容易被新手忽略的点probe和remove的调用时机是设备模型管着的不是你自己说了算。设备什么时候出现可能是开机时PCI总线枚举发现的也可能是你往PCIe槽里热插了一块卡。而你insmod一个驱动只会让内核去扫描一遍总线上现有的设备看看有没有跟id_table匹配的。设备已经绑定在别的驱动上或者设备还没被枚举出来你的probe就自然不会被调用。2.1 probe和remove的调用时机与返回值probe函数的原型是static int mypci_probe(struct pci_dev *dev, const struct pci_device_id *id);参数里的dev是内核帮你建好的pci_dev设备对象它包含了设备的全部信息vendor、device、资源、IRQ号、DMA掩码等。第二个参数id是匹配上的那张ID表项有时候一张表里有好几个设备型号靠这个参数就能在probe里区分硬件版本。probe返回0表示成功。返回负数内核就认为驱动跟这个设备“绑定失败”设备模型会把这个驱动从设备的driver列表里摘掉。很多新人在这里犯迷糊probe里执行到一半失败了返回-ENOMEM然后又改代码再insmod结果发现probe根本没被调用。这是因为设备模型认为上次绑定失败后这个驱动和设备已经“无缘”了你需要先unbind或者把上次失败留下的状态清理干净。实际开发里我习惯在probe开头就dev_info打印一下确定函数确实进来了再往下走能省掉很多“我以为它调了但其实没有”的排查时间。remove函数原型是static void mypci_remove(struct pci_dev *dev);它没有返回值因为remove阶段不允许失败内核不会再因为你的remove报了错而把设备恢复到probe状态。所以remove里的顺序问题非常讲究应该先注销中断、释放DMA缓冲、注销字符设备节点然后再释放映射和资源。顺序反了轻则资源泄漏重则直接触发内核崩溃因为中断回调里可能还在访问你已经释放掉的ioremap空间。2.2 id_table的匹配规则驱动和设备是怎么对上眼的pci_device_id的典型写法有几种/* 精确匹配vendor和devicesubvendor/subdevice用PCI_ANY_ID通配 */ { PCI_DEVICE(0x1234, 0x5678) }, /* 精确匹配到子系统厂商和设备适合板卡厂商区分自家子卡 */ { PCI_VDEVICE(0x1234, 0x5678) }, /* 按class匹配比如匹配所有网络控制器 */ { .class PCI_CLASS_NETWORK_ETHERNET 8, .class_mask 0xffff00 },PCI_VDEVICE这个宏会把subvendor设置为PCI_ANY_ID也就是说不管子卡是谁做的只要主vendor和设备ID对得上就行。PCI_DEVICE则匹配vendor、devicesubvendor和subdevice也都是PCI_ANY_ID。如果硬件厂商在同一个主芯片下做了好几个子型号它们共用同一个vendor/device但subdevice不同偏偏你想让一个驱动只管其中某几个子型号那就得自定义结构体字段{ .vendor 0x1234, .device 0x5678, .subvendor 0xabcd, .subdevice 0x0001, }class匹配要特别小心class字段在pci_device_id里存的是把PCI配置空间里的Class Code左移了8位的值所以匹配时也要带上对应的移位写法。这个移位规则是出了名的容易写错我见过有人拿PCI_CLASS_NETWORK_ETHERNET直接填进去结果怎么都不匹配最后翻内核头文件才明白要左移8位。另外ID表最后一项必须是{}空结构体作为结束标志MODULE_DEVICE_TABLE(pci, mypci_ids)这个宏也要保留它让modprobe能通过depmod生成的模块别名找到这个驱动否则手动insmod可以但modprobe可能加载不了。在ARM等嵌入式平台上还有一个of_match_table的概念。PCI设备驱动主要是靠vendor/device匹配但如果你要处理的PCI设备挂在OF设备树描述的节点下有些平台也允许用compatible字符串补充匹配。这个机制在Linux里存在但并不推荐作为PCI设备的主要匹配手段因为标准PCI枚举根本不需要设备树设备树只是提供了一些主机控制器和时钟的描述信息。3. probe为什么总是进不去匹配背后的完整链路很多人的第一个PCI驱动是这样死的insmod成功dmesg里啥也没有probe压根没进。想搞明白这个问题就得把pci_register_driver到probe之间的链路走一遍。pci_register_driver这个宏往上追最终调用的是__pci_register_driver它做的事情是把pci_driver里的driver成员注册到pci_bus_type这个总线类型上。总线类型注册驱动会触发driver_attach也就是对总线上每一个设备调用pci_bus_match用 id_table 去匹配。匹配上了再调用pci_device_probe这里面才会进到pci_call_probe最终调到你的probe函数。所以probe进不去的核心原因就是pci_bus_match觉得“这个设备跟你没关系”。设备模型是这么想的设备是在总线上的客观存在驱动只是它的一个“候选服务者”。一个PCI设备在没有驱动的时候照样可以被lspci看到只是没有driver绑定而已。你insmod了驱动内核不会“强行安排”设备给驱动而是查询设备的vendor/device是否在驱动的ID表里。3.1 匹配失败的八种原因现象可能原因排查手段probe未调用设备显示没有driverid_table里的vendor/device和实际设备不一致lspci -nn看实际ID和模块ID表对照probe未调用但ID表看起来是对的设备已经被另一个驱动绑定了ls -l /sys/bus/pci/devices/0000:01:00.0/driverprobe未调用insmod报错说无效参数驱动编译用的是不同内核版本的headers重新用当前内核源码树编译模块设备存在但/sys里都看不到设备没被枚举或者被controller屏蔽了lspci -v看设备是否在总线上必要时rescanprobe调用后返回了负值设备又被解绑probe中途失败没有清理已申请资源在probe每步失败前用dev_err打印匹配成功但probe只调用了一次后续insmod不再调用第一次probe失败driver和device状态没复位echo 1 /sys/bus/pci/devices/.../remove重新rescan设备树平台上probe不进设备树节点没配好或of_match_table没填检查设备树里PCI节点的compatible属性驱动是y编译进内核但启动时设备不存在probe没调用设备是后插的热插拔卡或者启动太早设备插入后触发rescanecho 1 /sys/bus/pci/rescan这里我要单独说一个经验pci_bus_match里如果ID表里有class匹配项优先级并不比vendor/device匹配低而且class匹配的字段是对齐过的。如果你同时填了vendor/device和class内核要求请求的所有字段都得匹配不是“或”的关系而是“与”的关系。这是个特别容易让老手翻车的地方因为直觉上你会觉得class是“兜底”的实际上它只是“额外条件”。3.2 热插拔与rescan对probe的影响PCIe热插拔在服务器场景里很常见但在嵌入式开发板上很多时候不是真的热插拔而是调试时反复插拔设备。这时候你会发现第一次插上去probe跑了后面拔了再插probe也可能不跑因为设备节点还残留在sysfs里。正确的操作是先移除设备节点再触发重新扫描echo 1 /sys/bus/pci/devices/0000:01:00.0/remove echo 1 /sys/bus/pci/rescan这两个操作会把PCI设备从总线模型里“删干净”再重新枚举新的pci_dev对象生成设备模型才会重新考虑把你的驱动绑上去。这个“先remove再rescan”的操作不仅对热插拔有用也是驱动迭代调试时最常用的自我救赎手段。如果你发现自己的驱动改了几行代码insmod后行为没变先别怀疑内核缓存看看是不是设备压根没重新probe。4. 资源申请与BAR空间映射从配置空间到MMIO匹配和probe只是前戏真正干活的是资源。PCI设备有几个重要的地址空间都通过BAR寄存器暴露给系统。BAR0到BAR5一共6个每个代表一段独立的地址区域可能是MMIO也可能是IO端口但PCIe时代IO空间基本废弃了绝大多数情况是MMIO。在驱动的视角里这些地址区域是物理地址你要通过ioremap把它们变成内核虚拟地址才能用CPU访问。4.1 先enable还是先request顺序别搞反一个非常常见的坑probe里用ioremap(pci_resource_start(dev, 0), pci_resource_len(dev, 0))拿到虚拟地址后直接readl读寄存器读出来全是0xffffffff。为什么会这样极大概率是你没先调用pci_enable_device。pci_enable_device做的事情是把设备配置空间里的Command寄存器打开使能IO和MMIO访问同时做DMA资源初始化。设备出厂默认情况下Command寄存器的Memory Space Enable位很可能就是0意味着设备的BAR空间根本没被映射到系统地址空间。你直接读地址上是空的读回来就是全F。正确顺序是ret pci_enable_device(dev); if (ret 0) return ret; ret pci_request_regions(dev, mypci); if (ret 0) { pci_disable_device(dev); return ret; }先enable再request_regions。pci_request_regions的作用是检查并保留这些BAR区域在系统IO/内存资源表里避免另一个驱动也来claim同一段地址。这个检查不是可选项万一有两个驱动都去ioremap同一段物理地址产生的bug极难排查。所以内核即使不强制你调用它你也应该在框架里把它当成强制步骤。另外注意pci_request_regions申请成功后在remove里要对应调用pci_release_regions。很多新手只记得pci_enable_device要配pci_disable_device却忘了release_regions结果反复insmod/rmmod之后/proc/iomem里全是残留的region标记后面insmod就老是报“resource busy”。4.2 一个标准的MMIO映射流程直接看代码块注释里写清楚每一步的意图static int mypci_probe(struct pci_dev *dev, const struct pci_device_id *id) { int ret; resource_size_t start, len; void __iomem *regs; /* 1. 使能设备打开MMIO/IO访问否则后面ioremap了也读不到数据 */ ret pci_enable_device(dev); if (ret 0) return ret; /* 2. 向内核资源管理系统声明这段BAR区域归本驱动所有 */ ret pci_request_regions(dev, mypci); if (ret 0) { pci_disable_device(dev); return ret; } /* 3. 获取BAR0的物理起始地址和长度 */ start pci_resource_start(dev, 0); len pci_resource_len(dev, 0); dev_info(dev-dev, BAR0: phys%pa len%pa\n, start, len); /* 4. 物理地址映射为内核虚拟地址注意返回的是__iomem指针 */ regs ioremap(start, len); if (!regs) { pci_release_regions(dev); pci_disable_device(dev); return -ENOMEM; } /* 5. 验证映射后能读到设备的寄存器通常读Vendor ID或版本号 */ dev_info(dev-dev, config read: %04x\n, ioread16(regs)); /* 6. 把regs保存到dev的drvdataremove里要用 */ pci_set_drvdata(dev, regs); return 0; } static void mypci_remove(struct pci_dev *dev) { void __iomem *regs pci_get_drvdata(dev); /* 释放顺序和申请顺序相反 */ if (regs) iounmap(regs); pci_release_regions(dev); pci_disable_device(dev); }这个流程里ioremap返回的指针类型是void __iomem *你不能像一个普通unsigned long *那样直接解引用而要用ioread32/iowrite32或readl/writel去访问。这些接口会做必要的内存屏障保证CPU访问和外设端的状态一致。如果你非要直接敲指针解引用在某些架构上会因为内存序的问题读到陈旧数据。这个“MMIO要用专门的读写接口”的规矩x86上可能感觉不明显在ARM上就是实打实的稳定性分水岭。4.3 新版内核的简化写法pcim_ *如果你用的是较新的内核版本5.x之后可以考虑用managed版本资源管理。pcim_enable_device、pcim_iomap_regions这类函数的好处是驱动的remove回调没写或者probe中途失败内核也会自动释放这些资源不会泄漏。static int mypci_probe(struct pci_dev *dev, const struct pci_device_id *id) { void __iomem *regs; int ret; ret pcim_enable_device(dev); if (ret 0) return ret; ret pcim_iomap_regions(dev, BIT(0), mypci); if (ret 0) return ret; regs pcim_iomap_table(dev)[0]; ... }pcim_iomap_table(dev)[0]就是BAR0映射后的虚拟地址。这套API我在新的板卡驱动里用得比较多因为它让remove函数变得很短很多资源释放逻辑都交给设备模型在驱动卸载时统一收尾。但对刚上手的人来说建议先把非managed那套手动映射流程彻底搞懂再切换到managed版本否则会不理解“为什么remove里没写iounmap也不会泄漏”背后的机制。5. 中断处理INTx、MSI与MSI-X怎么选PCI设备中断有几种形态。传统INTx中断是电平/边沿触发的共享中断线一个中断线可以被多个设备共享触发后内核逐个调用该线上的handler来判断是不是自己的设备。MSIMessage Signaled Interrupts则是设备直接往系统内存写一条特定消息来触发中断不再复用中断线。MSI-X是MSI的扩展版支持更多中断向量每个向量可以独立配置高吞吐网卡和NVMe SSD基本都依赖它。5.1 三种中断方式的对比类型中断线数量是否共享适合场景驱动注意事项INTx每设备最多4线是老设备、中断频率低的设备handler里要判断中断状态寄存器不是自己的中断要返回IRQ_NONEMSI每设备最多32向量否一般性能设备申请时用pci_alloc_irq_vectors减少向量数量可提高亲和性MSI-X每设备最多2048向量否高性能多队列设备每个向量可绑定不同CPU核心适合多队列处理我个人的看法是新设计的驱动能用MSI就尽量用MSI/MSI-X。MSI不仅中断处理效率高更重要的是它不需要在handler里做“是不是我的中断”这种轮询判断天然规避了共享中断线的麻烦。但MSI也有一个短板如果系统里PCIe RCRoot Complex对MSI消息地址支持不好或者设备驱动忘了调用pci_set_masterMSI中断就可能完全不触发。这个“忘了pci_set_master导致MSI不工作”的问题是我在实机上踩过最深的一个坑。我一度以为是自己中断号申请错了排查了一整天最后发现就是少了这一行。5.2 现代驱动里推荐的中断申请方式老式写法是直接request_irq(dev-irq, handler, ...)这个dev-irq是配置空间中断线寄存器给的值在MSI设备上不一定准。所以现在内核推荐用pci_alloc_irq_vectors动态分配int ret; int irq; ret pci_alloc_irq_vectors(dev, 1, 1, PCI_IRQ_MSI | PCI_IRQ_MSIX | PCI_IRQ_LEGACY); if (ret 0) return ret; irq pci_irq_vector(dev, 0); ret request_irq(irq, mypci_irq_handler, 0, mypci, dev); if (ret 0) { pci_free_irq_vectors(dev); return ret; }pci_alloc_irq_vectors的第一个参数是设备第二、三个参数是需要的向量数区间第四个参数是你允许的中断类型。内核会按照“MSI-X优先MSI其次最后INTx”的顺序去尝试分配最终给你申请到尽可能多的向量数。你拿到的中断号不一定是dev-irq而是pci_irq_vector(dev, index)。使用多个MSI-X向量时每个向量对应一个index分别给不同的队列。在remove里先free_irq再pci_free_irq_vectors。顺序别反否则中断处理函数还在跑向量已经被释放了典型的use-after-free。如果驱动没有使用pci_set_masterMSI也发不出来因为MSI本质上就是设备发起一个内存写操作来完成中断通知设备的bus master权限没开这个内存写就被拦住了。6. DMA高性能数据传输的核心PCI设备的强项就是DMA。网卡、存储卡、采集卡通通是靠DMA把数据直接塞到内存里才配得上“高性能”三个字。Linux内核给PCI驱动提供了两套DMA API一致性DMAConsistent DMA和流式DMAStreaming DMA。6.1 一致性DMA和流式DMA的区别一致性DMA用dma_alloc_coherent申请得到的内存是“CPU和设备都能访问且数据一致”的不需要额外的同步操作。适合那些设备持续读写的数据结构比如DMA描述符环、控制块。这个API返回两个值CPU虚拟地址和dma_addr_t总线地址。注意dma_addr_t不是物理地址它是设备视角的地址。在很多平台上它恰好和物理地址一样但你不应该依赖这一点要把它当作不透明句柄传给设备。流式DMA用dma_map_single/dma_map_page/dma_map_sg申请针对的是你原本就有的内核缓冲区比如kmalloc出来的内存、或者page用完之后要dma_unmap_single。它和一致性DMA的区别在于流式DMA映射期间CPU和设备访问这块内存需要通过dma_sync_single_for_device和dma_sync_single_for_cpu来保证一致性。在驱动的实际应用场景里最简单的数据搬运往往是设备把数据DMA到一个预先分配的缓冲区然后通过中断通知CPU去读。这个缓冲区用什么方式分配我最常用的方案是probe阶段用dma_alloc_coherent分配一块环形缓冲区设备一直往里面写CPU在中断里读走并重置写指针。这套逻辑简单、稳定、不用频繁map/unmap非常适合嵌入式数据采集。6.2 DMA方向和同步方向错了数据全是乱的DMA方向分几种DMA_TO_DEVICECPU往设备写、DMA_FROM_DEVICE设备往CPU写、DMA_BIDIRECTIONAL双向。方向错了轻则数据错乱重则缓存一致性问题导致读到的数据是旧值。典型错误场景你kmalloc了一个缓冲区用dma_map_single(dev-dev, buf, len, DMA_FROM_DEVICE)映射好了设备DMA写完触发中断你在中断里直接读buf发现数据不对。原因很可能是你漏了dma_sync_single_for_cpu。在DMA写内存之后CPU的cache里可能还有这块内存的旧副本直接从cache读就是旧的。正确做法是/* 设备写完数据后CPU要读之前必须先做一次sync */ dma_sync_single_for_cpu(dev-dev, dma_handle, len, DMA_FROM_DEVICE); /* 此时再读buf数据才是设备写进去的 */反过来如果CPU先写数据再让设备去读就要在写完后调用dma_sync_single_for_device。这个同步操作在使用了IOMMU或者非一致性的ARM平台上尤其关键。x86平台上因为硬件cache一致性做得比较好漏了sync可能偶尔不报错但这个“偶尔”就是一个定时炸弹哪天换了平台就炸。还有一点必须强调dma_alloc_coherent返回的dma_handle是给设备用的不是给CPU直接当物理地址用的。不少新人会用phys_to_virt(dma_handle)去转CPU地址这在某些平台上可能是对的但在有IOMMU的平台上就是完全错误的。你要记住CPU访问用dma_alloc_coherent返回的那个虚拟地址设备访问用dma_handle这两个值应该被当作两个独立的句柄使用。7. 现在内核推荐的写法一个最小PCI字符设备驱动理论讲了一堆不如来一个能编译、能加载的最小驱动骨架。这个例子综合了前面说的匹配、probe、ioremap和miscdevice字符设备框架方便你直接抄作业。#include linux/module.h #include linux/pci.h #include linux/miscdevice.h #include linux/fs.h #include linux/uaccess.h #include linux/io.h #define MYPCI_BAR 0 #define MYPCI_BAR_SIZE 0x1000 static void __iomem *mypci_regs; static ssize_t mypci_reg_read(struct file *file, char __user *buf, size_t count, loff_t *ppos) { u32 val; /* 简单起见只支持4字节对齐的读操作 */ if (count sizeof(val)) return -EINVAL; val ioread32(mypci_regs (*ppos 0xff)); if (copy_to_user(buf, val, sizeof(val))) return -EFAULT; return sizeof(val); } static const struct file_operations mypci_fops { .owner THIS_MODULE, .read mypci_reg_read, }; static struct miscdevice mypci_miscdev { .minor MISC_DYNAMIC_MINOR, .name mypci, .fops mypci_fops, }; static int mypci_probe(struct pci_dev *dev, const struct pci_device_id *id) { int ret; /* 使能设备并申请BAR资源 */ ret pcim_enable_device(dev); if (ret 0) return ret; ret pcim_iomap_regions(dev, BIT(MYPCI_BAR), mypci); if (ret 0) { dev_err(dev-dev, failed to iomap regions: %d\n, ret); return ret; } mypci_regs pcim_iomap_table(dev)[MYPCI_BAR]; if (!mypci_regs) { dev_err(dev-dev, invalid iomap table\n); return -ENOMEM; } pci_set_master(dev); /* 注册misc设备用户态就能通过/dev/mypci访问 */ ret misc_register(mypci_miscdev); if (ret 0) { dev_err(dev-dev, misc_register failed: %d\n, ret); return ret; } dev_info(dev-dev, mypci probed, regs%p\n, mypci_regs); return 0; } static void mypci_remove(struct pci_dev *dev) { misc_deregister(mypci_miscdev); dev_info(dev-dev, mypci removed\n); } static const struct pci_device_id mypci_ids[] { { PCI_DEVICE(0x1234, 0x5678) }, { } }; MODULE_DEVICE_TABLE(pci, mypci_ids); static struct pci_driver mypci_driver { .name mypci, .id_table mypci_ids, .probe mypci_probe, .remove mypci_remove, }; module_pci_driver(mypci_driver); MODULE_LICENSE(GPL); MODULE_DESCRIPTION(Minimal PCI character device driver);这个例子里用的是managed API所以remove里不需要手动iounmap和pci_release_regionspcim_ *系列会在设备销毁时自动收尾。misc_register是最简单的字符设备注册方式内核自动分配主设备号在/dev下生成一个名为mypci的设备节点。驱动加载后你可以这样测试modprobe mypci ls -l /dev/mypci cat /dev/mypci | hexdump如果设备硬件就绪读到的前两个字节应该就是设备的vendor ID。这个验证方法特别直接我在拿到新板卡时第一件事就是写个最小驱动probe里读vendor ID确认映射和配置空间访问通路是健康的再往后续功能加。8. 实战排障PCI驱动开发最常见的6个问题开发过程中我积累了一个自己的排障清单几乎每个PCI驱动问题最后都能归到这几类里直接整理成表格问题现象常见原因排查动作insmod后probe没有被调用id_table不匹配、设备已被其他驱动绑定、设备未rescanlspci -nn核对ID检查/sys/bus/pci/drivers/下有没有别的驱动占着必要时手动rescan读BAR返回全F没有调用pci_enable_device、设备没上电、BAR被映射成IO空间确认probe里先enable再ioremap用lspci -vvv看BAR的flags和地址pci_request_regions返回-EBUSY同一BAR被之前的驱动占用或残留region没有释放cat /proc/iomem查对应物理地址段被谁占了确认之前rmmod时remove有没有执行完整中断不触发没调用pci_set_master、MSI/MSI-X申请失败、IRQ号错误确认probe里有pci_set_master查看/proc/interrupts里对应中断号是否有设备DMA传输出错或数据错乱DMA方向不对、漏了dma_sync_single_*、用错了地址核对方向宏核对CPU虚拟地址和dma_handle是不是用反了remove时内核崩溃中断还没free就释放了ioremap、misc设备还在被访问就注销先free_irq再iounmap再misc_deregister检查打开设备节点的fd是否还挂着这里有个比较隐蔽的心得想说一下PCI驱动排障信息的优先级是dmesg大于一切。内核在驱动加载和probe失败时会打印一堆pci 0000:01:00.0: ...开头的信息很多人看dmesg只盯着自己dev_err打出来的内容却忽略了前半段设备模型自己打印的“driver不匹配”或者“resource busy”提示。尤其是-EPROBE_DEFER、-EBUSY这类返回值dmesg里往往已经写得很直白只是藏在了一大堆输出中间。我建议调试时先用dmesg -w开一个窗口然后insmod把内核从模块加载到probe结束这段时间完整日志抓出来再对着日志逐行分析。还有一点板卡挂上去之后不要急着写驱动代码先lspci -vvv看一遍设备配置空间。里面包括了设备ID、BAR地址、中断线、MSI能力寄存器、链路状态信息。这些信息能帮你判断硬件上电和枚举是否正常。如果lspci里BAR地址全是0说明设备没有被正确分配资源这时候驱动写再多也是白搭问题在RC侧或者BIOS/固件的地址分配上。9. 我对这套框架的个人体会这套PCI驱动框架我前前后后摸了好几年最大的感受是它是一个把设备模型、资源管理、并发模型、DMA一致性全部串起来的综合体。写字符设备驱动你可能只需要懂file_operations和miscdevice写平台驱动懂platform driver和设备树就行但写PCI驱动你得同时理解总线枚举、配置空间访问、MMIO映射规则、中断子系统、DMA API、电源管理。这是Linux驱动开发里最全面的“训练场”啃完一遍你再去看I2C驱动、SPI驱动、甚至V4L2驱动框架都会觉得轻松很多。如果非要说一个最重要的建议别跳过手动管理资源的老API先从pci_enable_devicepci_request_regionsioremap这套流程开始。虽然新内核的managed API写着省事但理解背后的申请、释放、失败路径对你排查问题起决定性作用。等老流程彻底吃透了再切换到pcim_ *或者设备模型自动管理的写法。PCI驱动框架的内容非常深这一篇讲完了驱动侧的主干链路还有不少硬核话题没有展开比如设备树/ACPI下的PCI资源分配、SR-IOV虚拟功能驱动、PCIe AER错误处理、VPD配置空间读取这些都是很好的后续选题。我后面会继续写这个系列把那些“看得见但不在标准文档里”的坑一个一个填上。
