上周帮一个朋友做驱动移植板子换了平台外设芯片型号没变驱动代码几乎原样搬过去。结果I2C能探测到设备GPIO也正常设备就是不干活。最后定位下来中断根本没进来。这种场景在linux驱动移植里太常见了尤其是WiFi、触摸屏、SDIO这类高度依赖中断的外设。很多人遇到中断问题就死盯着驱动里的request_irq其实真正的问题往往出在中断子系统这一整条链路上硬件中断控制器、设备树里的中断描述、内核的中断号映射、驱动注册时的触发方式哪一环对不上外设就是“叫不到人”。这篇文章就把linux驱动移植中必须先搞清楚的“中断子系统整体框架”拉通一遍。看完你会知道中断从硬件引脚到驱动handler到底经历了什么移植驱动时该核对哪些东西以及中断不触发、中断风暴这类问题该怎么一步步查。1. 中断子系统到底“框架”在哪一条完整的中断流水线很多人嘴上说“中断子系统是个框架”但真遇到问题又不知道从哪看起。原因很简单没把这条中断流水线在脑子里建立起来。中断不是“硬件触发一下软件函数被调用”这么简单它至少横跨硬件、内核抽象、驱动注册三层任何一层断了外设都收不到通知。1.1 硬件层外设芯片是如何“喊救命”的先看最底层的硬件行为。一颗外设芯片比如WiFi模块、触摸屏控制器、SDIO卡有事情要通知CPU时会拉高或拉低自己的中断引脚这叫assert中断请求线。这个信号不是直接进CPU核心的而是先进中断控制器。在Cortex-A系列处理器平台最常见的中断控制器是GICGeneric Interrupt Controller比如GIC-400、GICv3。GIC的职责不只是把中断信号转发给CPU它还负责中断屏蔽某个中断源暂时不想处理可以单独mask掉优先级仲裁多个中断同时来先给CPU响应更高优先级那个CPU分发多核平台里把中断分发给哪个核由这里决定中断状态跟踪active、pending、inactive等状态转换你可以把GIC想象成一个小区的物业前台。每个外设就是一个住户住户按下门铃assert中断物业前台GIC根据登记信息判断该通知哪栋楼CPU核然后派人去按门铃。如果物业没登记这个住户或者登记的门牌号是错的那住户按多少次门铃都不会有人来管。1.2 内核的抽象为什么驱动拿到的“中断号”不是硬件中断号这是整个中断子系统框架里最核心、也最容易被移植新手搞混的一点驱动里用的是一个叫“irq number”的虚拟中断号它不是硬件中断号两者之间存在一层映射。为什么要这么设计因为硬件中断号是由中断控制器决定的而不同厂商、不同世代的GIC硬件中断号的编码方式不一样。有的中断控制器还支持级联比如一个GPIO控制器本身也是一个中断源挂在GIC的某个SPI上而它内部又有几十个GPIO各自对应不同的“子中断号”。如果驱动直接面对硬件中断号同一个外设换一颗中断控制器就得改驱动这显然没法维护。内核的解决方案就是引入irq domain中断域和irq number。驱动只需要拿到一个稳定的虚拟中断号剩下的事由irq domain负责把虚拟中断号翻译成“哪个中断控制器、哪个bank、哪个bit”。这个过程的常见触发点是设备树解析设备树 interrupts 属性 - of_irq_get / platform_get_irq 解析 - irq_domain.translate 把 dts 里的描述翻译成硬件中断描述 - irq_domain.map 建立虚拟中断号到硬件中断的映射 - 返回给驱动的就是一个 irq number每个irq number背后对应一个内核结构体struct irq_desc。这个结构体里保存着这个中断的基本信息当前触发类型、是否被屏蔽、正在执行的处理函数链表、统计信息等。/proc/interrupts能显示每个中断的触发次数靠的就是irq_desc里的统计字段。1.3 驱动侧注册request_irq 之后发生了什么驱动拿到irq number后调用request_irq或request_threaded_irq把中断处理函数注册进去。这一步本质上是在对应的irq_desc-action链表上挂一个新的节点struct irqaction节点的核心成员是handler和thread_fn。中断产生后的调用路径大致是硬件信号 - 中断控制器 - CPU 进入异常向量表 - 内核 find irq_desc通过 irq number - generic_handle_irq 进入该中断的处理流程 - 遍历 irq_desc-action 链表调用每个 action 的 handler - 如果注册了 thread_fn则唤醒内核线程处理剩余工作注意“遍历链表”这个细节。如果这个中断被设计成共享的IRQF_SHARED也就是多个驱动共用同一个irq number那么一次中断触发会依次调用链路上的所有handler直到某个handler返回IRQ_HANDLED。如果所有handler都返回IRQ_NONE内核会把它记为一次spurious interrupt虚假中断。所以“框架”两个字不是空话它的含义是硬件中断控制器、irq domain映射、irq_desc管理、驱动action注册这四层各司其职层与层之间通过irq number串起来。2. 驱动移植中对齐中断资源三个必须校对的环节理解了分层之后回到移植场景里最实在的问题换平台之后中断资源到底要对齐哪些东西我归纳成三个环节每一个都在实际项目中让我吃过亏。2.1 设备树里的 interrupts 属性先帮硬件把“门牌”写对驱动移植到新平台第一个要改的往往就是设备树dts/dtsi。interrupts属性写错后面kernel解析出来的中断号肯定是错的。不同类型中断控制器的#interrupt-cells不同。GIC通常是3个cell每个cell表达三段信息中断类型、中断号、触发方式。比如interrupt-parent gic; interrupts 0 131 IRQ_TYPE_LEVEL_HIGH;三个字段的含义第一个cell中断类型0表示SPIShared Peripheral Interrupt共享外设中断1表示PPIPrivate Peripheral Interrupt私有外设中断比如每个核的定时器第二个cell中断号。SPI的中断号一般从32开始对应GIC内部的硬件中断号第三个cell触发类型IRQ_TYPE_EDGE_RISING、IRQ_TYPE_LEVEL_HIGH这类宏在dts里会展开成数字如果是GPIO控制器作为中断控制器通常#interrupt-cells 2格式是引脚号 触发类型interrupt-parent gpio2; interrupts 21 IRQ_TYPE_LEVEL_LOW;移植时最容易踩的坑是“沿用老平台的GPIO中断写法但新平台的中断控制器已经换成GIC”。比如老平台外设中断挂在某个GPIO bank上新平台把同一颗芯片的中断脚接到了GIC的某个SPI上设备树只改了引脚连接却忘了改中断控制器和迭代表述于是驱动拿到的中断号和实际硬件完全对不上。核对方法也很简单在驱动probe里把解析到的irq number打印出来再去查平台的中断控制器手册确认这个irq number映射到的硬件中断源是不是这颗芯片真正接的那个脚。2.2 中断号获取的姿势为什么推荐 platform_get_irq设备树写对了之后驱动侧获取中断号的接口选择也会影响移植。常见有几种platform_get_irq(pdev, index)平台驱动专用从设备树的interrupts属性按index解析irq_of_parse_and_map(node, index)老接口手动解析设备树节点gpio_to_irq(gpio)/gpiod_to_irq(desc)GPIO中断专用把GPIO号转成irq numberof_irq_get(node, index)通用解析接口内核对platform_get_irq的底层实现之一我的建议是标准platform驱动优先用platform_get_irq不要手动调用irq_of_parse_and_map。原因不只是代码更简洁而是platform_get_irq内部已经处理了很多老接口的边界情况并且能对错误情况打印更清晰的日志。新内核里platform_get_irq返回负数错误码很多老驱动写成if (irq 0) return -EINVAL;但早期版本里它是返回0表示获取失败移植时这一条判断逻辑就得跟着改。还有一类驱动是GPIO中断。比如触摸屏的INT脚接到一个GPIO上老代码用gpio_to_irq。这个API在新内核里逐渐被gpiod_to_irq取代因为后者基于GPIO描述符不依赖GPIO编号。gpio编号在新平台上极不稳定如果你还在用gpio_to_irq很可能在设备树gpio配置稍有变化时拿不到正确中断号。2.3 触发方式与共享中断具体行为比看着合规更重要中断触发方式这个细节是很多“中断偶尔不工作”类问题的根源。设备树里你写了IRQ_TYPE_EDGE_RISING驱动注册时也传了IRQF_TRIGGER_RISING看起来一致但外设实际的中断脚行为可能不是这样。举个例子某传感器芯片的中断脚是低电平有效并且会一直保持低电平直到软件读走数据。这种情况下用边沿触发falling edge虽然第一次下降沿能触发中断但之后芯片一直拉着低电平不会再产生新的边沿内核也就不会再收到下一次中断。结果是“只触发一次然后设备再也不响应”。改成IRQ_TYPE_LEVEL_LOW后只要芯片还拉着低电平内核就会持续处理中断驱动在读数据清标志后芯片释放引脚整个流程才恢复正常。这里要特别强调设备树里的触发类型和驱动调用request_irq时传入的flags本质上都是触发配置但设备树会先被解析并覆盖硬件初始触发状态驱动侧flags则用来在注册时确认/修改。移植时如果你只在设备树改了驱动里没改request_irq会因为配置不一致报错这在老内核里很容易遇到。共享中断是另一个移植雷区。多个设备共享一个中断号时所有驱动必须都传IRQF_SHARED而且每个handler都要尽快判断中断是否属于自己的设备不是就直接返回IRQ_NONE。我在一个项目中见过某驱动在共享中断链路上直接返回了IRQ_HANDLED结果其他设备的handler每注册一个就被误判一次某个本来正常的外设从此中断频率暴增整个系统被打到接近死机。这属于典型的“看似没多大问题实际影响全局”的坑。3. 上半部与下半部中断处理代码该放在哪儿驱动移植过程中除了要把中断“注册上”还要想清楚中断来了之后代码怎么组织。很多老驱动把大量处理逻辑直接塞在handler里这在老平台可能能跑换到新平台、新内核后就可能出问题。这里的关键是理解中断处理的“上半部”和“下半部”边界。3.1 硬中断上下文里的“三不原则”注册在request_irq里的handler也就是所谓上半部运行在硬中断上下文atomic context。这个上下文里有三样事情不能做不能睡眠。包括kmalloc(..., GFP_KERNEL)、mutex_lock、msleep、copy_from_user这些可能触发调度的操作全都会被内核报“scheduling while atomic”的错不能长时间占用CPU。硬中断处理期间当前CPU核的其他中断会被屏蔽或延迟处理越久实时性就越差不能随便调用可能被中断嵌套的锁。spin_lock在中断上下文里好用但必须配合local_irq_save这类操作避免死锁所以上半部里的标准操作就三件事快速读取硬件状态、判断中断来源、把真正的工作丢给下半部去做。底层外设的数据拷贝、通信协议解析、复杂状态机流转都不该出现在上半部里。3.2 下半部机制对比tasklet、workqueue、threaded irq下半部是“把非紧急工作拖到更宽松的环境去做”的机制。Linux内核里常见几种softirq、tasklet、workqueue、threaded irq线程化中断。驱动层常见的是tasklet、workqueue和threaded irq。机制执行上下文是否可以睡眠优先级特点适用场景softirq软中断上下文硬中断返回前由内核触发否很高不能被进程抢占网络收发、块设备等内核核心路径tasklet软中断上下文基于softirq封装否较高同一tasklet串行执行老驱动的数据搬运、修改后无需睡眠的场景workqueue内核线程上下文进程上下文是普通调度优先级耗时操作、可能睡眠的场景threaded irq内核线程上下文是可由调度器控制优先级新驱动首选兼顾处理能力与实时性看到这个表你就明白threaded irq其实是“长下半部”的进化形态。它把一个中断的处理过程放进了内核线程不再占用硬中断上下文。驱动里注册方式变成request_threaded_irq(irq, handler, thread_fn, flags, ...)。handler主handler仍然跑在硬中断上下文负责快速处理紧急动作thread_fn跑在线程里可以安心地做耗时操作。如果你的主handler传NULL内核用默认主handler线程fn直接在中断触发后唤醒这基本就是把整个处理移到了线程里。3.3 移植时的选择标准我现在的经验是新内核、新平台上的驱动移植默认就选threaded irq不要再在新代码里写tasklet。tasklet在软中断上下文执行不能睡眠而且要处理各种local_bh_disable/resume的嵌套问题移植到新内核上坑很多。workqueue虽好但你在通用workqueuesystem_wq里跑中断处理时要考虑和其他驱动共享线程池导致的延迟处理中断这种需要快速响应的任务threaded irq更直接每个中断都有独立线程还可以通过/proc/irq/irq/smp_affinity单独调整亲和性。这里有一个不能忽略的细节线程化中断注册时如果不显式设置IRQF_ONESHOT标志request_threaded_irq会返回-EINVAL。原因很简单线程化之后主handler跑完、线程fn还没跑的时候中断已经重新使能了如果硬件还在断言中断信号就会立刻再次触发造成死循环般的重复唤醒。IRQF_ONESHOT的作用是直到线程fn执行完才重新使能中断保证中断线程化处理的闭环。这段逻辑可以说就是整个下半部机制里最值得新移植工程师注意的一点。我自己第一次把老驱动的tasklet改成threaded irq时就因为这个标志查了半天的内核源码。4. 一次WiFi驱动移植中的中断丢事件完整排查链路复盘前面讲的是框架和原则这一节直接复盘一次真实遇到的移植排查过程。这个例子我按通用场景稍微做了抽象排查思路是完全可以复用的。4.1 现象描述与第一份证据当时把某个SDIO WiFi模块从旧平台老内核、老设备树框架移植到新平台。驱动编译过了、firmware也加载了、网络接口能创建但ping网关时丢包率高达百分之三四十吞吐量惨不忍睹。第一件事就是看/proc/interruptscat /proc/interrupts输出里能看到所有中断的触发计数。重点观察WiFi设备对应的中断行。那一行如果计数几乎不增长说明中断信号根本没有有效到达CPU如果计数增长很猛说明中断风暴要么是触发方式不对要么是handle里没有及时清标志。我们的情况是计数增长极少几次增长集中在初始化那一下之后几乎停住。结合WiFi丢包现象基本可以断定中断链路“通了一半”但触发时机极不正常。4.2 从 /proc/interrupts 往下追中断号到底对没对确认中断没怎么进来之后第二个问题是驱动到底注册到了哪个中断号上这个不确定就没法判断硬件信号是不是真正到了该到的地方。做法很直接在驱动probe里打印irq platform_get_irq(pdev, 0)的返回值重新编译加载看dmesg。把打印出来的irq number和/proc/interrupts里的行对应起来确认注册成功。然后再确认这个irq number背后映射的硬件中断源。新内核里可以看cat /proc/device-tree/wifi1/interrupts | xxd把设备树里interrupts属性原始字节读出来对照平台的手册核对SPI号、触发类型。这一步能排除“设备树写得和实际硬件不一致”的问题。当时检查发现设备树里给WiFi配的触发类型是IRQ_TYPE_EDGE_FALLING而WiFi模块的中断脚行为是低电平有效且保持低电平需要用IRQ_TYPE_LEVEL_LOW。为什么会变成edge triggering呢老平台那颗主控的中断控制器比较特殊所有外部中断都只支持边沿触发所以老驱动、老设备树全家都在沿用edge配置。新平台的GIC按电平触发模式工作完全没问题但dts是老平台带过来的没人注意到这个差异。4.3 根因确认与修复根因很清楚中断触发方式和外设实际信号行为不匹配。WiFi在初始化期间拉低了中断脚产生一次下降沿内核收到一次中断之后WiFi一直保持低电平因为还有数据没传完但边沿触发模式下不会有新边沿产生于是后续所有中断都被硬件“吞掉”了。修复方案就是两行改动。设备树里interrupts IRQ_TYPE_LEVEL_LOW;驱动里在request_threaded_irq注册时对应的flags也改成IRQF_TRIGGER_LOW。两边对齐之后重新加载驱动/proc/interrupts里WiFi中断计数立刻以稳定的速率增长ping丢包率直接归零。4.4 同类问题的快速体检清单下次再遇到驱动移植后“设备能识别但不干活”我建议按这个顺序检查cat /proc/interrupts看中断计数是否正常确认“中断到底来没来”打印platform_get_irq返回值确认驱动注册的irq number对得上设备树描述加载后立即看dmesg有没有“scheduling while atomic”或“IRQF_SHARED”相关报错比对设备树interrupts属性和驱动注册时传入的flags触发类型必须一致确认设备的中断脚有效电平行为用示波器或逻辑分析仪看实际波形不要只信硬件文档如果中断计数暴涨优先怀疑共享中断和缺少标志清除这套链路基本覆盖了我在移植类项目里遇到的九成中断问题。5. 移植过程中容易忽视的几个细节最后一节说几个不那么起眼、但一旦踩中就能让人查很久的细节。5.1 devm_ 版本与裸版的取舍老驱动里常见的写法是request_irq 在remove函数里free_irq。新内核推荐用devm_request_threaded_irq它把中断资源的生命周期绑定在struct device上。设备remove时中断自动释放省得你每次都要检查错误路径里有没有漏掉free_irq。移植时如果驱动的probe流程写得很乱、从一开始就失败过devm版本能省不少事。5.2 IRQF_ONESHOT 的“小字条款”之前提过threaded irq创建时必须带IRQF_ONESHOT。但要注意IRQF_ONESHOT会改变中断的enable时机主handler跑完中断不会立即重新使能而是等线程fn执行完才恢复。如果你的线程fn依赖“中断被重新触发”来推进工作用IRQF_ONESHOT时需要格外谨慎否则可能变成“线程执行期间中断被锁死后续事件堆积”。别问我是怎么知道的。5.3 中断函数里千万别睡报错信息可能晚到硬中断上下文睡眠的报错通常不立即出现而是在内核调度器检测到异常时打印有时候报错的时间点离实际出错代码已经十万八千里。排查方法是用CONFIG_DEBUG_ATOMIC_SLEEP重新编内核开启该配置后任何在原子上下文里尝试睡眠的代码都会立刻打出来。对付这类问题的最佳策略不是排错而是从结构上避免主handler只做状态记录和唤醒所有可能产生睡眠的操作全部放到threaded irq的线程fn或专用workqueue里。5.4 中断亲和性多核平台上的负载平衡新平台基本都是多核。如果一个外设中断总是打在一个核上高吞吐场景下那个核可能被中断处理任务占满。可以通过/proc/irq/irq/smp_affinity调整亲和性把中断分散到不同核。比如echo f /proc/irq/45/smp_affinity这个值表示CPU掩码f就是让中断可以在CPU0-3之间路由。在驱动代码里也可以调用irq_set_affinity_hint来设置但注意有些中断控制器不支持中断分发GIC这类通常没问题。移植时如果发现某个核load很高而其他核空闲先查这个。5.5 老接口和老flag的清理问题老驱动里可能还残留着IRQF_DISABLED、IRQF_SAMPLE_RANDOM这类已经废弃的flag。新内核里IRQF_DISABLED直接被忽略了IRQF_SAMPLE_RANDOM也早已从内核中移除。移植时过了编译并不代表正确有条件的话应该去做一次接口清查把废弃flag删干净把request_irq换成request_threaded_irq或至少换成devm_request_irq。另外irq_of_parse_and_map的返回值是irq number但它不会被platform设备资源跟踪与platform_get_irq混用容易出现重复解析、重复注册的问题。老平台驱动里这种混用很常见新平台上最好统一用一种获取方式。写到这里我把驱动移植里关于中断子系统最核心的部分都覆盖完了。我个人的习惯是拿到一份驱动移植任务第一件事不是看驱动代码而是把外设的所有中断资源列成一张表中断控制器是哪颗、中断引脚接在哪个bank/bit、有效电平是高还是低、设备树怎么描述、驱动注册用什么flags。这张表列完驱动里八九成的问题其实已经能提前看出来了。如果你也正在搞linux驱动移植不妨从cat /proc/interrupts开始先把链路走通再谈性能优化。