我们小组正在使用自定义驱动程序在共享I2C总线上连接四个MAX3107 UART。四个MAX3107的中断通过ARM9处理器（LPC3180模块）上的GPIO引脚连接（即通过逻辑或电路共享中断）。当这些器件中的一个或多个中断时，它们将配置为电平敏感中断的GPIO线拉低。我的问题是否需要禁用处理程序代码中的特定中断行。 （我应该补充一点，我们正在运行Linux 2.6.10）。
基于我阅读几个关于中断的ARM专用应用笔记，似乎当ARM处理器收到一个中断时，它会自动禁用（掩码？）相应的中断线（在我们的例子中，这似乎就是这一行）对应于我们选择的GPIO引脚）。如果这是真的，那么似乎我们不应该在我们的中断处理程序代码中禁用此GPIO引脚的中断，因为这样做似乎是多余的（尽管它似乎工作正常）。换句话说，在我看来，如果ARM处理器在发生中断时自动禁用GPIO中断，那么如果有的话，我们的中断处理程序代码只需要在设备维修后重新启用中断。
我们使用的中断处理程序代码在处理程序的最开始包含disable_irq_nosync(irqno);，在处理程序的末尾包含相应的enable_irq()。如果ARM处理器已经禁用了中断线（在硬件中），这些呼叫会产生什么影响（即呼叫disable_irq_nosync()然后呼叫enable(irq())？
答案 0 :(得分：6)
来自Arm Information Center文档：
进入异常（中断）时：
对所有异常禁用中断请求（IRQ）
FIQ和重置异常禁用快速中断请求（FIQ）。
然后继续说：
处理FIQ会导致IRQ和后续FIQ被禁用， 直到FIQ处理程序启用后才阻止它们被处理 他们。这通常是通过从SPSR恢复CPSR来完成的 处理程序的结束。
因此您不必担心禁用它们，但您必须担心重新启用它们。
您需要在例程结束时包含enable_irq（），但您不需要在开头禁用任何内容。我不认为在硬件中调用后调用disable_irq_nosync（irqno）会影响任何事情。由于在软件调用有机会接管之前，最明确地调用硬件调用。但是最好将它从代码中删除以遵循惯例，而不要混淆下一个看过它的程序员。
更多信息：