Re: New consolidate irqs vs . probe_irq_*()

[Ingo Molnar <mingo@elte.hu>]

* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> On Wed, 2004-10-20 at 18:48, Ingo Molnar wrote:
> 
> > yeah. I've put it into a separate autoprobe.c file specifically for that
> > reason, you can exclude it in the Makefile and can provide your own
> > architecture version. Or should we make the no-autoprobing choice
> > generic perhaps?
> 
> I like this later option... How may archs actually had autoprobing
> implemented and actually used ?
> 
> Well, I'll do some grep'ing around tonight as I do the NO_IRQ stuff
> and see what makes more sense. I don't think an arch that didn't have
> autoprobing needs it now, besides, it's not exactly a reliable
> mecanism...

btw., auto-detection of interrupt sources is not _necessarily_ broken. 
Especially with level-triggered interrupts (where no active irq source
can get lost) it can be doable and reliable. (Here i dont mean the
probe_irq_on/off interface, but the concept of auto-detection.)

Alan has a very neat hack that fixes laptop BIOS breakage in associating
a screaming interrupt with the driver that responds to it with
IRQ_HANDLED, by probing through all the SHIRQ handlers and checking
whether the return code is IRQ_HANDLED. (this patch was in -mm but has
not been integrated into the generic irq subsystem yet.) This patch
turned a broken-under-Linux into a working laptop so we cannot ignore
it.

In theory, as long as all drivers involved are shared-irq-capable, and
all interrupts are level-triggered and get repeated if unhandled, we can
always do this kinds of driver-feedback-based irq vector discovery.

Think about the positive effects: in theory we could even boot into a
box without _any_ BIOS interrupt info whatsoever, assuming only a few
architecture basics like the identity of the timer interrupt.
Furthermore, if the BIOS reports _bad_ interrupt information, we can
detect & redirect that interrupt to the driver that responds to it.

this is not a concept that would be too useful for the server space, but
it sure could be useful for the produce-and-forget PC mass-market. We
are playing a constant and mostly losing catchup game with BIOS quirks.

what can never work fully reliably is of course what the feature was
used for primarily: ISA :-) One-time edge-triggered interrupts that get
lost are nasty ...

so i thought autodetect.c could survive in the generic code - maybe we
can make something really nice out of it, based on Alan's patch.

	Ingo