Shared Peripheral Interrupt Lines: Attribute the Event Before Clearing Another Device’s State
A shared interrupt line reports that at least one connected source needs attention. It does not identify that source. Attribute the event using each device’s documented status path, preserve evidence before destructive reads, and acknowledge only the state owned by the servicing driver. A low shared wire is insufficient reason to clear every connected device.
Applicability: the concrete register example uses Microchip MCP23017 documentation DS20001952C and Linux v6.12 IRQ interfaces. Two expanders sharing an interrupt are a hypothetical, electrically qualified arrangement, not a ready-to-build schematic. The example uses port-A input-change interrupts, with relevant INTCON bits zero and open-drain interrupt outputs already configured.
1. Qualify the shared connection before software dispatch
Record every connected interrupt output, its active condition, drive mode, supply domain, reset behavior, and possible power-off state. Shared wiring requires compatible electrical behavior throughout the system lifecycle. A software flag named shared cannot prevent two incompatible output drivers from contending.
The MCP23017 data sheet specifies IOCON.ODR for open-drain interrupt operation; it overrides INTPOL. Its reset configuration is not open drain. Keep interrupt sources disabled during coordinated initialization and qualify reset and partial-power behavior separately before accepting a directly shared connection.
Select pull-up voltage and resistance from the actual connected devices, loading, and required rise time. This article supplies no universal resistor or voltage. If one peer can reset into an incompatible drive mode while another asserts, solve that hardware/lifecycle problem before evaluating the dispatch algorithm.
2. Separate discovery from acknowledgement
For the MCP23017, INTF identifies pending enabled input causes. Reading INTCAP returns the saved port value and clears the corresponding interrupt; reading GPIO also clears it. INTCAP retains the first captured event until acknowledgement rather than storing an event queue. These behaviors are specified in sections 3.5.8–3.6.5 of the data sheet.
Use INTF as the non-clearing discovery read. If this device has a relevant pending cause, preserve that status and read its corresponding INTCAP through the single owning service path. Publish the saved status and capture together. Do not let a diagnostic GPIO read consume the evidence first.
The example’s input-change mode matters. In comparison-against-DEFVAL mode, a persistent mismatch can keep the interrupt condition active despite a capture or GPIO read. Select the actual configuration explicitly; do not transfer an acknowledgement expectation between these modes.
Identify port and bank configuration in the register-access helper. A copied numeric address can refer to a different register after bank changes. Prefer a reviewed device-specific register definition, and restrict the transaction length so a discovery read does not accidentally continue into a clearing register.
3. Design source attribution in the permitted context
The v6.12 generic IRQ interface requires a unique non-null dev_id for shared handlers and distinguishes primary from threaded handling. A primary handler that can safely determine ownership returns IRQ_NONE when the event is not its device’s; sleeping I2C reads cannot be inserted into that hard-handler path.
Where attribution itself requires a sleeping transaction, use a supported threaded design and review all participants’ flags and trigger compatibility. The v6.12 pca954x driver provides a concrete example of a null primary handler with IRQF_SHARED and IRQF_ONESHOT. This demonstrates an implementation pattern, not drop-in MCP23017 driver code.
Such a design may wake service threads for peers that have no cause. A thread must still inspect its own device and distinguish no pending source from an unreadable source. Do not count every thread invocation as an event delivered by that peripheral.
Keep per-device attribution and shared-line coordination separate. One driver should not reset or clear another device merely because the common line remains asserted after its own service. The remaining assertion may be a legitimate pending event belonging to that peer.
4. Walk the simultaneous-event case
Assume hypothetical devices A and B each latch one input-change event before service begins. Their shared line is low. A’s owner discovers A’s pending bit, saves A’s capture, and acknowledges A. The line can remain low because B still has an unserviced event.
B’s owner then discovers and services B. If neither device has acquired another cause, the line can return inactive. The intermediate low level is expected and must not cause A’s driver to repeat destructive reads or declare its acknowledgement broken.
Reverse the service order and require the same attribution result. Also inject a new A event while B is being serviced. The expected event-retention result must follow the device’s capture model; do not demand one software record for every physical transition when the hardware retains only a pending indication and one capture.
5. Make ambiguous observations visible
| Proposed observation | Required interpretation |
|---|---|
| A pending, B clear | Service A; B must not invent a handled device event. |
| A and B pending | Preserve and service both; one acknowledgement need not release the wire. |
| A status read fails | A’s ownership is unknown, not proven absent. |
| Previously seen flag disappears | Audit another reader, reset, or earlier acknowledgement before calling it spurious. |
| All readable sources clear, line active | Investigate omitted sources, configuration, races, and electrical state. |
Use bounded service passes and an explicit fault policy. Disabling the entire shared IRQ to recover one peer also affects healthy peers, so its scope must be coordinated. Where possible, contain a failing source using that device’s own supported masking mechanism and expose the loss of service.
6. Preserve a source-by-source acceptance record
Capture the shared line, addressed bus transactions, and service markers together. Record which status snapshot caused each acknowledgement and which device still owned pending work afterward. Include a deliberate competing-reader test on a safe fixture to verify that diagnostics cannot silently consume capture registers.
Test each source alone, both together, each service order, transport errors, and reset of one participant under the qualified electrical design. Record the exact data-sheet revision, board wiring, kernel configuration, and interrupt registration choices.
No shared interrupt was generated for this article. The deliverable is an attribution matrix and a single-owner capture policy. Acceptance means every serviced event has an identified source, every destructive access has an owner, and remaining shared-line assertion has a bounded explanation rather than triggering indiscriminate clearing.
