Messages in this thread | | | From | Thomas Gleixner <> | Subject | Re: [PATCH v1] gpio: dwapb: mask/unmask IRQ when disable/enable it | Date | Fri, 15 Dec 2023 11:56:02 +0100 |
| |
On Fri, Dec 15 2023 at 13:24, Serge Semin wrote: > On Fri, Dec 15, 2023 at 09:09:09AM +0100, Thomas Gleixner wrote: >> On Sat, Dec 05 2020 at 22:58, Linus Walleij wrote: >> > Sorry for top posting but I need the help of the irqchip maintainer >> > Marc Z to hash this out. >> > >> > The mask/unmask/disable/enable semantics is something that >> > you need to work with every day to understand right. >> >> The patch is correct. >> >> The irq_enable() callback is required to be a superset of >> irq_unmask(). I.e. the core code expects it to do: >> >> 1) Some preparatory work to enable the interrupt line >> >> 2) Unmask the interrupt, which is why the masked state is cleared >> by the core after invoking the irq_enable() callback. >> >> #2 is pretty obvious because if an interrupt chip does not implement the >> irq_enable() callback the core defaults to irq_unmask() >> >> Correspondingly the core expects from the irq_disable() callback: >> >> 1) To mask the interrupt >> >> 2) To do some extra work to disable the interrupt line >> >> Same reasoning as above vs. #1 as the core fallback is to invoke the >> irq_unmask() callback when the irq_disable() callback is not >> implemented. > > Just curious. Wouldn't that be more correct/portable for the core to > call both callbacks when it's required and if both are provided? So > the supersetness requirement would be no longer applied to the > IRQ enable/disable callbacks implementation thus avoiding the code > duplications in the low-level drivers.
We could do that, but there are chips which require atomicity of the operations (#1/#2). Not sure whether it safes much.
Thanks,
tglx
| |