Hello. Benjamin Herrenschmidt wrote:
As fasteoi type chips never had to define their ack() method before the recent Ingo's change to handle_fasteoi_irq(), any attempt to execute handler in thread resulted in the kernel crash. So, define their ack() methods to be the same as their eoi() ones...
Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>
--- Since there was no feedback on three solutions I suggested, I'm going the way of least resistance and making the fasteoi type chips behave the way that handle_fasteoi_irq() is expecting from them...
Wait wait wait .... Can somebody (Ingo ?) explain me why the fasteoi handler is being changed and what is the rationale for adding an ack that was not necessary before ?
It's changed in the RT patch for the case of threaded IRQ. This patch is not for the mainline kernels.
To be more precise, I don't see in what circumstances a fasteoi type PIC would need an ack routine that does something different than the eoi... and if it always does the same thing, why not just call eoi ?
Because Ingo decided that calling mask() and ack() methods was a better than calling mask() and eoi(). Here's the thread:
http://ozlabs.org/pipermail/linuxppc-dev/2006-October/026546.html
Ben.
WBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
