On 10/24/2012 09:17 AM, Jan Kiszka wrote: >>> >>> This is ugly for many reasons. First of all, it is racy as the register >>> content may change while dropping the device lock, no? Then you would >>> raise or clear an IRQ spuriously. >>> >> Device state's intact is protected by busy flag, and will not broken > > Except that the busy flag concept is broken in itself.
How do we fix an mmio that ends up mmio'ing back to itself, perhaps indirectly? Note this is broken in mainline too, but in a different way. Do we introduce clever locks that can detect deadlocks? > I see that we have a all-or-nothing problem here: to address this > properly, we need to convert the IRQ path to lock-less (or at least > compatible with holding per-device locks) as well. There is a transitional path where writing to a register that can cause IRQ changes takes both the big lock and the local lock. Eventually, though, of course all inner subsystems must be threaded for this work to have value. -- error compiling committee.c: too many arguments to function
