Messages in this thread | | | From | <> | Subject | Re: Why set .suppress_bind_attrs even though .remove() implemented? | Date | Mon, 25 Jul 2022 17:49:05 +0000 |
| |
On 22/07/2022 18:06, Marc Zyngier wrote: > Hi Bjorn, > > On Fri, 22 Jul 2022 15:39:05 +0100, > Bjorn Helgaas <helgaas@kernel.org> 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. >
Sorry to butt back in here - but I am taking this to mean that rather than add a remove callback for the microchip pci controller driver when making it buildable as a module it would instead be better to forgo that entirely and prevent unloading the module (since it does INTX & MSI).
Would that be an accurate assessment? Thanks, Conor.
| |