Re: [PATCH] pci: do not try to assign irq 255
From: Hannes Reinecke
Date: Wed Feb 20 2013 - 02:58:14 EST
On 02/19/2013 08:40 PM, Yinghai Lu wrote:
On Mon, Feb 18, 2013 at 2:09 AM, Hannes Reinecke <hare@xxxxxxx> wrote:
The PCI config space reseves a byte for the interrupt line,
so irq 255 actually refers to 'not set'.
However, the 'irq' field for struct pci_dev is an integer,
so the original meaning is lost, causing the system to
assign an interrupt '255', which fails.
So we should _not_ assign an interrupt value here, and
allow upper layers to fixup things.
This patch make PCI devices with MSI interrupts only
(like the xhci device on certain HP laptops) work properly.
looks like the bios does not provide _PRT for device in ACPI.
also according to PCI spec, BIOS *must* set interrupt line.Apparently this device is meant to use MSI _only_ so the BIOS
developer didn't feel the need to assign an INTx here.
According to PCI-3.0, section 6.8 (Message Signalled Interrupts):
> It is recommended that devices implement interrupt pins to
> provide compatibility in systems that do not support MSI
> (devices default to interrupt pins). However, it is expected
> that the need for interrupt pins will diminish over time.
> Devices that do not support interrupt pins due to pin
> constraints (rely on polling for device service) may implement
> messages to increase performance without adding additional pins.
> Therefore, system configuration software must not assume that a
> message capable device has an interrupt pin.
Which sounds to me as if the implementation is valid...
And in either case, I've added the relevant details plus patch
Including ACPI dump, so you can check for yourself.
And correct me if I'm wrong, of course :-)
Dr. Hannes Reinecke zSeries & Storage
hare@xxxxxxx +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/