Hi Richard, I'm a bit puzzled by the Q40 interrupt architecture. arch/m68k/q40/q40ints.c says: * Q40 IRQs are defined as follows: * 3,4,5,6,7,10,11,14,15 : ISA dev IRQs Yep, that's _9_ interrupts. * 16-31: reserved * 32 : keyboard int * 33 : frame int (50/200 Hz periodic timer) * 34 : sample int (10/20 KHz periodic timer) According to the Q40_IRQ*_MASK definitions (8 bits in the mask) and the code (e.g. q40_irq_startup()), ISA IRQ 11 is not implemented. In the "new" interrupt code, by Roman Zippel, all interrupts sources are handled through q40_irq_handler(). Only autovector IRQs IRQ_AUTO_2 and IRQ_AUTO_4 are enabled. In the old (pre-2006) interrupt code, only internal (master) and ISA interrupts go through q40_irq2_handler on IRQ_AUTO_2. Q40_IRQ_SAMPLE goes via both IRQ_AUTO_4 and IRQ_AUTO_6. Why doesn't the new code use IRQ_AUTO_6? Does the new code work? For the genirq conversion, I was first thinking about using a custom chain-alike flow handler. But it looks like this is not possible, as the Q40 handler remaps autovector interrupts to conflicting numbers (it handles IRQ_AUTO_4 = 4, but ISA interrupt 4 is also 4). So if the custom flow handler would call generic_handle_irq(4) for ISA interrupt 4, it would recurse into the flow handler set up for autovector IRQ 4 :-( Changing the numbers is not trivial, as ISA assumes interrupts 1-15 everywhere. So I'm afraid we're stuck with the current m68k_setup_auto_interrupt() hack, which overwrites the lowest-level asm interrupt code, and keep the current q40_irq_handler() (This is similar to process_int() for 68328 on nommu). Thanks for your clarifications and suggestions! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html