Hi Bjorn, On Fri, 22 Jul 2022 15:39:05 +0100, Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: > > [+cc Marc, can you clarify when we need irq_dispose_mapping()?] In general, interrupt controllers should not have to discard mappings themselves, just like they rarely create mappings themselves. That's usually a different layer that has created it (DT, for example). The problem is that these mappings persist even if the interrupt has been released by the driver (it called free_irq()), and the IRQ number can be further reused. The client driver could dispose of the mapping after having released the IRQ, but nobody does that in practice. >From the point of view of the controller, there is no simple way to tell when an interrupt is "unused". And even if a driver was overzealous and called irq_dispose_mapping() on all the possible mappings (and made sure no mapping could be created in parallel), this could result in a bunch of dangling pointers should a client driver still have the interrupt requested. Fixing this is pretty hard, as IRQ descriptors are leaky (you can either have a pointer to one, or just an IRQ number -- they are strictly equivalent). So in general, being able to remove an interrupt controller driver is at best fragile, and I'm trying not to get more of this in the tree. Hope this helps, M. -- Without deviation from the norm, progress is not possible.