Re: dmesg: PCI interrupts are no longer routed automatically.........

[Bjorn Helgaas <bjorn.helgaas@hp.com>]

On Wed, 2005-01-05 at 13:15 -0500, linux-os wrote:
> The problem is that the PLX-9656BA INTCSR is not in configuration
> space, but runtime registers off a BAR. The interrupt source
> can be from a PLD that hasn't even had its microcode loaded
> yet!
> 
> FYI, the PLX or similar clone is the bus interface chip for many
> busmastering PCI boards.
> 
> > You wouldn't want your ISR mucking around with a half-initialized
> > device, so does it have to check a "device_configured" flag
> > or something?
> 
> Yes. If the device isn't configured, the ISR reads all the INTCSR
> bits, then writes 0 to the register to prevent anything else.

The PLX might be a common device, but it sounds like this
particular issue depends on the design of the rest of the
board.  And presumably, nobody who cared about performance
would design a board with this property, right?  I mean, to
add a test in the ISR for a condition that exists only for
a few milliseconds at driver startup-time seems sub-optimal.

> If the PLX had been reset, then the INTCSR bits would all
> be masked off. However, reset is really only guaranteed from
> power OFF on some motherboards, in particuar the ones with
> so-called "hot-swap" capabilites fail. There is a software
> reset that, in fact, even reloads its serial EEPROM. However,
> the BAR needs to be accessible for this to be used.
> 
> So it would be wonderful if the correct IRQ could be made
> available before the chip could generate an interrupt.

If we exposed a new pcibios_route_irq() (to hide the arch-
specific nature of IRQ routing via ACPI or other information),
could you do what you need in a pci_fixup_early quirk?