Geert,
I didn't realize it before, but the EtherNAT CPLD acts as an interrupt controller?
That's correct.
So you are probably better off creating a separate IRQ chip for it (IRQ 139 is USB, IRQ 140 is Ethernet). Then all this can be hidden in the EtherNAT CPLD irq_chip methods.
Meaning request_irq will enable it and so on? That would be the ideal solution indeed. The irq to vector mapping remains the same here?
BTW, are there any other IRQs generated by this CPLD?
Nope, that's all. Cheers, Michael -- 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