lkml.org 
[lkml]   [1998]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: probe_irq_{on,off}
Date
From
>1. Currently, probe_irq_on() returns a mask of interrupts currently
> enabled for a probe. This is then passed to probe_irq_off(),
> to identify which IRQ has been triggered.
>
> Does this information have to be passed this way, or can the
> architecture IRQ code keep a mask? (eg, if you have 64 or more
> interrupts/sparse interrupt numbers etc).

Since it doesn't make any sense to have two probes active concurrently, it
seems to me that it's probably OK for the architecture to store a mask.

> 1) Drivers using autoirq_report have a horrible bug in them
> that can lead to -ve interrupt numbers being requested
> (but that request_irq will trap).

The way to fix that one is just to kill auto_irq.c altogether and fix the
drivers to use the probe_irq interface instead.

>I propose introducing a new kernel macro, NO_IRQ, to contain an
>architecture defined value which can be used in drivers and
>probe_irq_off() to indicate either failure or no interrupt.

That sounds reasonable. Updating all the drivers is going to be a pain but it
shouldn't be particularly difficult, just tedious.

>The return method for probe_irq_off() could be changed as well,
>such that it returns either success/failure, and returns the
>probed interrupt number via a pointer thus:

Given the above I don't really see what this buys us.

p.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.027 / U:0.612 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site