为什么有些代码以 NULL 作为 irq_handler 的参数调用 request_threaded_irq？答案

【问题标题】：why some code calls request_threaded_irq with NULL as a parameter for irq_handler?为什么有些代码以 NULL 作为 irq_handler 的参数调用 request_threaded_irq？
【发布时间】：2014-04-15 00:46:35
【问题描述】：

根据内核文档，request_threaded_irq 用于将其分为两部分，irq_handler 检查中断是否来自设备。如果是，则需要禁用设备上的中断并返回IRQ_WAKE_THREAD，这将唤醒处理程序线程并运行@thread_fn。

但是我发现了一些代码寄存器中断，使用request_threaded_irq 同时将NULL 作为irq_handler 传递，它们在thread_fn 中保留了完整的功能。

所以我怀疑为什么我们在这种情况下使用request_threaded_irq()，而我们可以轻松使用request_irq，它在上述场景中的行为相同。

【问题讨论】：

request_irq 先创建然后 request_threaded_irq 。而现代内核中的request_irq 由request_threaded_irq 包装，thread_fn 为NULL 以实现兼容性。见interrupt.h。

标签： linux-kernel kernel linux-device-driver interrupt

【解决方案1】：

documentation 说：

如果 NULL 和 thread_fn != NULL 则安装默认的主处理程序

默认的主要处理程序没有记录，但其来源应该是不言自明的：

 static irqreturn_t irq_default_primary_handler(int irq, void *dev_id)
 {
         return IRQ_WAKE_THREAD;
 }

【讨论】：

在那种情况下它和request_irq不是一回事吗？由于启用了中断，因此只有您要求 thread_fn 运行。
@Rahul，至少，实际处理程序运行的上下文（进程VS硬IRQ）有所不同，顺便说一句，这是线程IRQ处理程序的要点。