Hi Scott, Thanks for your reply. Comments below.
Scott Wood wrote: > Alex Zeffertt wrote: >> Well, mpc832xemds_phy_interrupt_enable() does nothing except call >> request_irq(,,SA_SHIRQ,,). I suspect that request_irq() is somehow >> reenabling interrupts, but I can't see where it might be doing so. > > One possibile way (in 2.6.18; I'm assuming 2.6.11 is similar) is that > request_irq() calls setup_irq(), which calls register_irq_proc() and > register_handler_proc(), both of which call proc_mkdir(), which > eventually calls proc_create(), which calls kmalloc() with GFP_KERNEL. > This is probably a bug, since request_irq itself uses GFP_ATOMIC, > indicating an intent for request_irq() to be safely callable in atomic > context. > I agree this indicates an intent to make it atomic, but I don't see how this could cause interrupts to become re-enabled during the request_irq() call. Also, since I am calling request_irq at insmod time, i.e. in process context, both GFP_ flags *should* work. > Can you disable the interrupts at the device level until the handler is > in place, and thus avoid the need to disable IRQs at all? > > -Scott Yup, I've come to the same conclusion. I now, for each shared interrupt: * initialise all the devices which share the interrupt, turning interrupt generation off * register all handlers for each device which shares the interrupt * turn interrupt generation back on for each device. This avoids the original problem, but it does not explain it. I still can't see how I can get an interrupt on line 3 below: 1. local_irq_save(flags); 2. request_irq(MPC83xx_IRQ_EXT6, handler, SA_SHIRQ, "name", dev1); 3. 4. request_irq(MPC83xx_IRQ_EXT6, handler, SA_SHIRQ, "name", dev2); 5 local_irq_restore(flags); Regards, Alex _______________________________________________ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
