[<c03920c4>](usb_hcd_irq) from [<c0147678>](__handle_irq_event_percpu+0x40/0x128)[<c0147678>](__handle_irq_event_percpu) from [<c0147788>](handle_irq_event_percpu+0x28/0x7c)[<c0147788>](handle_irq_event_percpu) from [<c0147804>](handle_irq_event+0x28/0x3c)[<c0147804>](handle_irq_event) from [<c014b2bc>](handle_level_irq+0x9c/0x114)[<c014b2bc>](handle_level_irq) from [<c0146f34>](generic_handle_irq+0x30/0x44)[<c0146f34>](generic_handle_irq) from [<c0146f90>](__handle_domain_irq+0x48/0xa8)[<c0146f90>](__handle_domain_irq) from [<c030cedc>](vic_handle_irq+0x58/0x9c)[<c030cedc>](vic_handle_irq) from [<c0100b4c>](__irq_svc+0x6c/0x90)
The current design of the Linux kernel uses a single large number
space where each separate IRQ source is assigned a different number.
This is simple when there is only one interrupt controller, but in
systems with multiple interrupt controllers the kernel must ensure
that each one gets assigned non-overlapping allocations of Linux
IRQ numbers.The number of interrupt controllers registered as unique irqchips
show a rising tendency:for example subdrivers of different kinds
such as GPIO controllers avoid reimplementing identical callback
mechanisms as the IRQ core system by modelling their interrupt
handlers as irqchips, i.e. in effect cascading interrupt controllers.Here the interrupt number loose all kind of correspondence to
hardware interrupt numbers: whereas in the past, IRQ numbers could
be chosen so they matched the hardware IRQ line into the root
interrupt controller(i.e. the component actually fireing the
interrupt line to the CPU) nowadays this number is just a number.For this reason we need a mechanism to separate controller-local
interrupt numbers, called hardware irq's, from Linux IRQ numbers.