On Thu, 2015-09-24 at 00:44 +0200, Francois Romieu wrote: > David Woodhouse <dw...@infradead.org> : > [...] > > But sure, for now I'll drop this from the series and I can try to > > convince you separately. > > You may as well change the IRQ storm avoidance logic so that it does not > require conformant driver code if you do not want to waste more time :o)
That's not entirely trivial — at a certain level we *do* require that drivers don't lie to the core IRQ logic. I suppose even if a rogue driver is returning IRQ_HANDLED in an IRQ storm, when it's *not* actually doing anything or making any progress, perhaps there's a way we could detect that we're always going straight back into the next interrupt handler as *soon* as we exit the previous one. Perhaps there's merit in exploring that option. I'm not sure that gives you a valid excuse for not wanting to fix the driver though :) I might start by "clarifying" the documentation on the IRQ handler's return value... -- David Woodhouse Open Source Technology Centre david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
