[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5124820D.2080900@suse.de>
Date: Wed, 20 Feb 2013 08:58:05 +0100
From: Hannes Reinecke <hare@...e.de>
To: Yinghai Lu <yinghai@...nel.org>
Cc: Bjorn Helgaas <bhelgaas@...gle.com>, linux-kernel@...r.kernel.org,
Frederik Himpe <fhimpe@....ac.be>,
Oliver Neukum <oneukum@...e.de>,
David Haerdeman <david@...deman.nu>, linux-usb@...r.kernel.org,
linux-pci@...r.kernel.org
Subject: Re: [PATCH] pci: do not try to assign irq 255
On 02/19/2013 08:40 PM, Yinghai Lu wrote:
> On Mon, Feb 18, 2013 at 2:09 AM, Hannes Reinecke <hare@...e.de> 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.
>
Correct.
> 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
to bnc#52591.
Including ACPI dump, so you can check for yourself.
And correct me if I'm wrong, of course :-)
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@...e.de +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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists