ppc irq handling vs. sym53c500_cs driver

David Hinds dhinds at sonic.net
Wed Oct 27 15:24:49 EDT 2004


On Wed, Oct 27, 2004 at 12:37:17PM -0500, Bob Tracy wrote:
> I'm the current author/maintainer of the sym53c500_cs driver for 2.6
> and later kernels, and the other user of the New Media Bus Toaster
> (PCMCIA SCSI card, circa 1997) made contact a few days ago :-).  He's
> trying to use the sym53c500_cs driver on a Mac G4 Powerbook (ppc
> architecture), and failing...  The problem seems to be something
> associated with the request_irq() implementation on ppc machines.
> Card Services is attempting to assign the card the same IRQ as his
> yenta controller, which isn't necessarily a problem except request_irq()
> on ppc will fail unless both drivers agree to share the interrupt.
> Anyway, for Guiseppe, the request_irq() call fails, and the sym53c500_cs
> driver exits.
> 
> The nsp_cs.c PCMCIA SCSI driver seems to avoid the issue entirely by
> doing something like "link->irq.Handler = &nspintr;".  Presumably, I
> could do something similar in the sym53c500_cs driver, but I could
> use some guidance as far as pros/cons of the two approaches.  I suspect
> there's more to converting the sym53c500_cs driver to use the new
> scheme than meets the eye.  For whatever it's worth, there's no
> identified need for this driver to be usable on non-PCMCIA hardware,
> so if the use of request_irq() is a relic associated with the non-Card
> Services environment, that would be useful information.

You do have two options; either call request_irq() with the SA_SHIRQ
flag, or specify irq.Handler and let Card Services request the
interrupt for you.  The latter is marginally safer because Card
Services knows whether the SA_SHIRQ flag is actually needed.  But
really, either option is ok.

This should be all you need to do.  The only potential issue is that
when sharing interrupts, your driver needs to be a little bit more
careful to ensure that every card interrupt is promptly acknowledged.
This has come up as an issue once or twice.  Mainly it was a problem
with the IDE driver, which used to generate interrupts during probes
before calling request_irq().

-- Dave



More information about the linux-pcmcia mailing list