aspeed_intc0_resolve_route(9)

💅 aspeed_intc0_resolve_route(9) — the kernel api manual, but make it make sense

okay bestie so this is a page from the Kernel API Manual and it's about aspeed_intc0_resolve_route, a function that figures out which interrupt output at intc1 you actually need. like, route resolution. it's giving air-traffic-control for interrupts ✈️✨

---

✨ NAME ✨

aspeed_intc0_resolve_route — determine the necessary interrupt output at intc1 🎯

---

🎀 SYNOPSIS 🎀

int aspeed_intc0_resolve_route (const struct irq_domain *c0domain ,
       size_t nc1outs , const u32 *c1outs , size_t nc1ranges ,
       const struct aspeed_intc_interrupt_range *c1ranges ,
       struct aspeed_intc_interrupt_range *resolved );

like yes that's a lot of parameters, she's high-maintenance but she delivers 💅

---

🫶 ARGUMENTS 🫶

• c0domain — the pointer to intc0's irq_domain. the source of truth, the main character 👑
• nc1outs — how many valid intc1 outputs are available for the input. yes, count them 🧮
• c1outs — the array of available intc1 output indices for the input. the menu of options 🍓
• nc1ranges — the number of interrupt range entries for intc1
• c1ranges — the array of configured intc1 interrupt ranges
• resolved — the fully resolved range entry after applying the resolution algorithm. the glow-up result ✨

---

🌈 RETURN 🌈

on success you get the intc1 route index associated with the intc1 output identified in resolved 🔥 otherwise you get a negative errno value. and no, we do not stan a negative errno 😭

---

💖 DESCRIPTION 💖

okay so the AST2700 interrupt architecture is genuinely iconic: it lets any peripheral interrupt source be routed to one of up to four processors running in the SoC. four! choices! 🌸

a processor binding a driver for a peripheral that requests an interrupt is — without further design and effort — the destination for the requested interrupt. that's just how it is, no cap.

routing a peripheral interrupt to its destination processor needs coordination between INTC0 on the CPU die and one or more INTC1 instances. at minimum there's one INTC1 instance in the SoC on the IO-die, but up to two more instances may be integrated via LTPI (LVDS Tunneling Protocol & Interface). like, tunneling. through LVDS. weird flex but okay 🦋

so between the multiple destinations, various route constraints, and the devicetree binding design, some info that's needed at INTC1 instances to route inbound interrupts correctly to the destination processor is only available at INTC0. tragic, honestly. the intc1 girlies simply do not have it 💀

aspeed_intc0_resolve_route is to be invoked by INTC1 driver instances to perform the route resolution. the implementation in INTC0 lets INTC0 encapsulate the information used to perform route selection, and gives it an opportunity to apply policy as part of the selection process. such policy may, for instance, choose to de-prioritise some interrupts destined for the PSP (Primary Service Processor) GIC. policy! decisions! drama! 🙈

---

🔍 SEE ALSO 🔍

• kernel file ./drivers/irqchip/irq-ast2700-intc0.c — go read the source, iykyk 💜

---

fr fr, everything above is verbatim-important: the paths, the parameter names, the errno behaviour. the vibes are mine, the facts are the kernel's 🫶

---

and that's the page bestie 💅 written for the ./drivers/irqchip section of the kernel api manual, dated October 2026, and the function name in the corner is — say it with me — aspeed_intc0_resolve_route(9). slay, go resolve those routes ✨🎀🦋