On Tuesday 03 February 2015 10:38:25 Marc Zyngier wrote:
>
> That's exactly what I thought until Lorenzo reported kvmtool falling
> over because of this write. Obviously, some platforms must actually
> require this (possibly for bridges that are not known by the firmware).
This sounds much like a bug in kvmtool.
> Entirely removing that code solves my problem too, but that'd cannot be
> the right solution...
The comment in pdev_fixup_irq() says
/* Always tell the device, so the driver knows what is
the real IRQ to use; the device does not use it. */
which I read to mean that there are drivers that incorrectly use
'pci_read_config_byte(dev, PCI_INTERRUPT_LINE)' as the number
they pass into request_irq, rather than using dev->irq.
However, this means that your patch is actually wrong, because
what the driver cares about is the virtual irq number (which
request_irq expects), not the number relative to some interrupt
controller.
There is another comment in include/linux/pci.h that states
/*
* Instead of touching interrupt line and base address registers
* directly, use the values stored here. They might be different!
*/
unsigned int irq;
so apparently this has been a cause for problems in the past,
and drivers that rely on the number are already broken.
I also checked ancient kernel versions from the 2.1 days when the
code was first added. And indeed at the time drivers used to read
the word, but now none of them use the number for anything real,
they were all fixed during linux-2.2 at the latest.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
