On Mon, Mar 27, 2017 at 05:36:48PM -0700, Tony Lindgren wrote: > * Mark Brown <broonie@xxxxxxxxxx> [170327 10:52]: > > So, I see your use case but the fact is that as Charles observed this is > > exactly the code used for emulating level triggered IRQs with edge > > triggered interrupt controllers. This means someone is doubtless going > > to end up using it for precisely that. This makes me uncomfortable, we > > do have this open coded into various drivers already but this is more of > > a core thing and it feels like this should be in genirq rather than > > here... that said, looking at the code: > Yes.. But then again we might avoid piling up yet more driver > specific hacks. I don't know what the genirq solution would look Right, my thinking here is that by pushing into genirq we minimise the need even further since it'll also be available to drivers not using regmap-irq. > like, handle until we get IRQ_NONE? :) Well, that's what the per driver emulation does so... yeah. Probably with an upper limit on the number of times we do that. > > There's no protection against screaming interrupts here, I'd really like > > to see that. Also some tracing of the number of times we spin. > Good idea. How about something like below where handle_reread checks > for the total time spent in the thread loop with a large enough > timeout? Or do you have some better ideas in mind? > I tested I can hit that warning with timeout set to much lower > 10 ms with retries being 1 or 2 at that point. That looks sensible, yes.
Attachment:
signature.asc
Description: PGP signature
