On Wed, 2007-11-14 at 13:13 +1100, David Gibson wrote: > Hrm. I *think* I'm convinced this is safe, although acking in a > callback which doesn't say it acks is rather yucky. Essentially this > code is trading flow readability (because just reading > handle_level_irq will tell you something other than what it does in > our case) for smaller code size. I'm not sure if this is a good trade > or not. > > There's also one definite problem: according to the discussions I had > with Thomas Gleixner when I wrote uic.c, handle_edge_irq is not what > we want for edge interrupts. > > Apparently handle_edge_irq is only for edge interrupts on "broken" > PICs which won't latch new interrupts while the irq is masked. UIC is > not in this category, so handle_level_irq is actually what we want, > even for an edge irq. > > Yes, I thought the naming was more than a little confusing, too.
Hrm... handle_edge_irq works for both and you have a small performance benefit in not masking, and thus using handle_edge_irq, so I don't totally agree here. Basically, what handle_edge_irq() does is lazy masking. Now there -is- an issue here is that if you do lazy masking, you need to be able to re-emit in some convenient way. Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
