Change Details

Maintaining the intrcnt/intrnames variables are causing problems. Notably INTRNG's interrupt release code is unable to properly release counters. At this point it seems best to work towards moving the values elsewhere. The counters also really belong to the interrupting device, not the controller. As such they should be in the device-side structure, not the interrupt controller structure. Additionally this is an architecture-independent area. This should increase shared source code by taking over.

Presently only layers above `intr_event` consider multi-processor interrupts. Yet these do effect the interrupt core. Notably, if interrupt counters were moved to `intr_event` then it would need to use atomics, per-processor counters, or something else. Additionally there is a concern if a device expects a PPI ("Private Peripheral Interrupt" in ARM terms, but per-processor interrupt), yet receives a SPI ("Shared Peripheral Interrupt" in ARM terms, but opposite of PPI) there will likely be trouble. I believe x86 isn't sending PPI interrupts to `intr_event`. Instead the equivalents are using `intrcnt_add()` and never letting the interrupts reach the core. This is a squash review of 3 commits. One commit for each flag, plus a third for type checking and marking `clk_intr_event` as being multi-processor.

Maintaining the intrcnt/intrnames variables are causing problems. Notably INTRNG's interrupt release code is unable to properly release counters. At this point it seems best to work towards moving the values elsewherPresently only layers above `intr_event` consider multi-processor interrupts. Yet these do effect the interrupt core. Notably, if interrupt counters were moved to `intr_event` then it would need to use atomics, per-processor counters, or something else. The counters also really belong to the iAdditionally there is a concern if a device expects a PPI ("Private Peripheral Interrupting device" in ARM terms, not the controller. As such they should be in the device-side structurebut per-processor interrupt), not the iyet receives a SPI ("Shared Peripheral Interrupt controller structure" in ARM terms, but opposite of PPI) there will likely be trouble. Additionally this is an architecture-independent areaI believe x86 isn't sending PPI interrupts to `intr_event`. Instead the equivalents are using `intrcnt_add()` and never letting the interrupts reach the core. This is a squash review of 3 commits. This should increase shared source code by takOne commit for each flag, plus a third for type checking and marking `clk_intr_event` as being overmulti-processor.