Currently the NCR5380.h defines IRQ_NONE to be 255, is there any special
reason for this? why not use UINT32_MAX-1?..
The VAX actually has got more than 255 interrupt handlers which we've
mapped to IRQs, and it happens the external SCSI interface is at 255, so
this makes it a bit sick...
I've redefined it in our tree to 65535 but I see no reason not to go to
the above... any objections?
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / [email protected]
pam_smb / Linux DecStation / Linux VAX / ILUG person
On Fri, May 30, 2003 at 12:27:25AM +0100, Dave Airlie wrote:
> Currently the NCR5380.h defines IRQ_NONE to be 255, is there any special
> reason for this? why not use UINT32_MAX-1?..
>
> The VAX actually has got more than 255 interrupt handlers which we've
> mapped to IRQs, and it happens the external SCSI interface is at 255, so
> this makes it a bit sick...
>
> I've redefined it in our tree to 65535 but I see no reason not to go to
> the above... any objections?
Only that ARM already has a NO_IRQ macro fairly well established for this
thing, which should probably be propagated to the other architectures.
Could we call it NO_IRQ instead?
I seem to remember that in the dim and distant past, several drivers
used to store IRQ numbers in byte-sized objects, so this would need to
be fixed before making NO_IRQ > 255.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Gwe, 2003-05-30 at 00:27, Dave Airlie wrote:
> Currently the NCR5380.h defines IRQ_NONE to be 255, is there any special
> reason for this? why not use UINT32_MAX-1?..
Shouldnt cause any problems at all. I have the same problem with the IDE
layer and "picking an IRQ that cant exist". Maybe we need a global
IRQ_NONE type value