On Sun, 2015-07-05 at 09:03 +0200, Michael S. Tsirkin wrote: > On Sun, Jul 05, 2015 at 09:28:28AM +1000, Benjamin Herrenschmidt wrote: > > Under some circumstances, pci_intx() can return -1 (when the interrupt > > pin in the config space is 0 which normally means no interrupt). > > > > I have seen cases of pci_set_irq() being called on such devices, in > > turn causing pci_irq_handler() to be called with "-1" as an argument > > which doesn't seem like a terribly good idea. > > > > Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> > > Isn't this a device bug though?
Possibly, I can try to dig a bit more see if I can reproduce and find out who is causing it. > I did a grep over all callers of pci_set_irq and didn't > find any that fails to set an interrupt pin. > > So how about an assert instead? > > And maybe stick it in pci_intx to make sure all callers > get checked. Ok, It's also possible that this doesn't happen anymore, I've carried that patch for monthes and rebased several times on top of newer qemu's. I *think* it might have been something that happens due to some generic code initializations, something like pci_update_irq_disabled() in pci_default_write_config()... I'll dbl check. Cheers, Ben.
