Re: pcmcia oops on 2.6.17-rc[12]

From: Rogier Wolff
Date: Mon May 22 2006 - 07:50:08 EST

On Tue, May 16, 2006 at 12:00:26AM +0100, Alan Cox wrote:
> > So I would strongly argue that any driver that depends on getting an
> > exclusive IRQ is buggy, not the PCMCIA layer itself, and that it would be
> > a lot more productive to try to fix those drivers.
> It would certainly be a lot cleaner than this sort of code in the pcmcia
> core right now. Want me to send a patch which only allows for SA_SHIRQ
> and WARN_ON()'s for any driver not asking for shared IRQ ?

The question I'm stuck with is: When is it valid to ask for a non-shared
IRQ, and get back a shared one.

Drivers that know that they don't work well if they are called by the
"other" interrupt?

I happen to know (ISA) hardware that CANNOT share an interrupt: It
drives the IRQ line either high or low, and has a driver that will
overpower anything else on that line. This sounds like a good place to
me to have the driver request no sharing (*), and to prevent the IRQ
line drivers getting in eachothers way, it would be nice if the kernel
refused "early on" (i.e. before the stronger driver asserts: No IRQ
pending, and the weaker one keeps trying to assert: "YES, I have an
IRQ", and the weaker one slowly burning out).

Or am I talking nonsense again?


(*) The driver knows to allow sharing when it's talking to the PCI
version of the card.

** R.E.Wolff@xxxxxxxxxxxx ** ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at