Linux平台支持的IRQ描述符数量受哪些因素限制？

对于你的场景，软件中断的IRQ描述符数量上限，核心由以下几个因素共同决定：

• 内核编译时的NR_IRQS宏定义：这是最直接的硬限制，它指定了系统中irq_desc数组的总大小，所有硬件中断、GPIO中断、软件中断都要从这个数组里分配描述符。你的旧平台把它设成了硬件中断+GPIO的总数，自然没留软件中断的空间。增大这个值后，数组扩容，就能容纳额外的软件中断描述符了。
• 平台中断控制器的软件IRQ支持能力：有些平台的中断控制器会预留专门的软件中断通道（比如ARM架构里的SGI/PPI，或是x86的APIC中断），这类软件中断的数量上限由硬件控制器的设计决定。但如果是纯内核虚拟的软件中断（比如IIO触发用的irq_create_mapping分配的虚拟IRQ），则不受硬件限制，只受NR_IRQS的约束。
• 内核中断子系统的分配机制：新内核里很多平台已经不再硬编码NR_IRQS，而是支持动态扩展irq_desc数组（比如通过irq_alloc_descs等接口）。但你的旧平台用的是静态数组，所以只能靠增大NR_IRQS来扩容。
• 系统内存资源限制：每个irq_desc结构体占用一定内存空间，极端情况下，过大的NR_IRQS会消耗过多内存，这在内存紧张的嵌入式平台上可能成为实际限制。但一般来说，只要内存足够，增大NR_IRQS是可行的。

针对你的情况，IIO触发用的是虚拟软件中断，不需要对应硬件中断线，所以本质上只要NR_IRQS的大小足够，就能分配到可用的描述符。你的旧平台之前的NR_IRQS刚好卡满了硬件和GPIO的需求，没留余量给软件中断，所以增大后就能正常工作。

内容的提问来源于stack exchange，提问作者col_panic