On Thu, 15 Nov 2018 18:37:33 +0000, Trent Piepho <tpiepho@xxxxxxxxxx> wrote: > > On Thu, 2018-11-15 at 15:22 +0000, Gustavo Pimentel wrote: > > On 14/11/2018 18:28, Trent Piepho wrote: > > > On Tue, 2018-11-13 at 22:57 +0000, Marc Zyngier wrote: > > > > > > > Now it works again. Race still present. I don't see the > > > dw_pci_msi_bottom_(un)mask methods ever get called. I seem to recall > > > that they are called as a substitute if enable/disable are not present, > > > but haven't confirmed that, which would explain why they are not called > > > after I added enable. > > > > Hum, this probably is correlated with [1] where on the describition the this > > enumerator says that "One shot does not require mask/unmask" see [2] > > That seems reasonable then. I've said before that while I think > masking could be added in the interrupt flow without breaking anything, > I think it's redundant to do it at this layer. > > I suspect it might be possible mask/unmask the interrupt "manually", > e.g. UIO does this to allow handling a level interrupt from userspace, > and that would be a path to reach the mask methods. The real use case is that a driver can perfectly disable (mask) an interrupt while being in the interrupt handler, and enable it again at a later time. M. -- Jazz is not dead, it just smell funny.
