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?
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.
> ---
> hw/pci/pci.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> index 8185bbc..eea6f5d 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c
> @@ -1281,7 +1281,9 @@ qemu_irq pci_allocate_irq(PCIDevice *pci_dev)
> void pci_set_irq(PCIDevice *pci_dev, int level)
> {
> int intx = pci_intx(pci_dev);
> - pci_irq_handler(pci_dev, intx, level);
> + if (intx >= 0) {
> + pci_irq_handler(pci_dev, intx, level);
> + }
> }
>
> /* Special hooks used by device assignment */
>
