I wrote a driver for our custom MPC860 platform that we've ported linux 2.4.19
to. When I insmod'd the driver it produced a kernel panic. I traced it to
request_irq() in ppc8xx_pic.c, where the code calls panic() if the requested
irq is anything other than IDEx_INTERRUPT. I fixed my problem by just adding
another case.
First, it seems extreme to me to crash the system instead of just refusing the
request. Am I missing something?
Second, a suggested improvement: How about having the individual board.h
files include #defines like ENABLE_SIU_LEVEL1, etc. that could be used like
the 'well known' IDEx_INTERRUPTs in request_irq()?
Mark Chambers
Microfirst, Inc.
mchambers@microfirst.com
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Mark Chambers writes:
I wrote a driver for our custom MPC860 platform that we've ported linux 2.4.19
to. When I insmod'd the driver it produced a kernel panic. I traced it to
request_irq() in ppc8xx_pic.c, where the code calls panic() if the requested
irq is anything other than IDEx_INTERRUPT. I fixed my problem by just adding
another case.
First, it seems extreme to me to crash the system instead of just refusing the
request. Am I missing something?
No. IMO the current request_8xxirq / request_irq stuff is completely
bogus. I can understand it as a temporary construction while
debugging stuff, but it has long outlived its usefulness. We should
just use request_irq for everything, request_8xxirq should die.
Paul.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
No. IMO the current request_8xxirq / request_irq stuff is completely
bogus. I can understand it as a temporary construction while
debugging stuff, but it has long outlived its usefulness. We should
just use request_irq for everything, request_8xxirq should die.
Multiple people have submitted patches to fix this but they have not made it
into the release code. What can be done?
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/