共享中断通过 request_irq 来安装就像不共享的一样, 但是有 2 个不同:
- SA_SHIRQ 位必须在 flags 参数中指定, 当请求中断时.
- dev_id 参数必须是独特的. 任何模块地址空间的指针都行, 但是 dev_id 明确地 不能设置为 NULL.
内核保持着一个与中断相关联的共享处理者列表, 并且 dev_id 可认为是区别它们的签名. 如果 2 个驱动要在同一个中断上注册 NULL 作为它们的签名, 在卸载时事情可能就乱了, 在中断到的时候引发内核 oops. 由于这个理由, 如果在注册共享中断时传给了一个 NULL dev_id , 现代内核会大声抱怨. 当请求一个共享的中断, request_irq 成功, 如果下列 之一是真:
- 中断线空闲.
- 所有这条线的已经注册的处理者也指定共享这个 IRQ.
无论何时 2 个或多个驱动在共享中断线, 并且硬件中断在这条线上中断处理器, 内核为 这个中断调用每个注册的处理者, 传递它的 dev_id 给每个. 因此, 一个共享的处理者必 须能够识别它自己的中断并且应当快速退出当它自己的设备没有被中断时. 确认返回 IRQ_NONE 无论何时你的处理者被调用并且发现设备没被中断.
如果你需要探测你的设备, 在请求 IRQ 线之前, 内核无法帮你. 没有探测函数可给共享 处理者使用. 标准的探测机制有效如果使用的线是空闲的, 但是如果这条线已经被另一个 有共享能力的驱动持有, 探测失败, 即便你的驱动已正常工作. 幸运的是, 大部分设计为 中断共享的硬件能够告知处理器它在使用哪个中断, 因此减少明显的探测的需要.
释放处理者以正常方式进行, 使用 free_irq. 这里 dev_id 参数用来从这个中断的共享 处理者列表中选择正确的处理者来释放. 这就是为什么 dev_id 指针必须是独特的.
一个使用共享处理者的驱动需要小心多一件事: 它不能使用 enable_irq 或者 disable_irq. 如果它用了, 对其他共享这条线的设备就乱了; 禁止另一个设备的中断即 便短时间也可能产生延时, 这对这个设备和它的用户是有问题的. 通常, 程序员必须记住, 他的驱动不拥有这个 IRQ, 并且它的行为应当比它拥有这个中断线更加"社会性".
来源：https://www.cnblogs.com/fanweisheng/p/11142328.html