[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1360722010.3604.3.camel@thor.lan>
Date: Tue, 12 Feb 2013 21:20:10 -0500
From: Peter Hurley <peter@...leysoftware.com>
To: Yinghai Lu <yinghai@...nel.org>
Cc: Bjorn Helgaas <bhelgaas@...gle.com>,
"Rafael J. Wysocki" <rjw@...k.pl>, linux-pci@...r.kernel.org,
linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ACPI, PCI: Get PRT entry during acpi_pci_enable_irq()
On Tue, 2013-02-12 at 11:11 -0800, Yinghai Lu wrote:
> Peter Hurley found "irq 18 nobody cared" with pci-next, and dmesg has
>
> [ 8.983246] pci 0000:00:1e.0: can't derive routing for PCI INT A
> [ 8.983600] snd_ctxfi 0000:09:02.0: PCI INT A: no GSI - using ISA IRQ 5
>
> bisect to
> | commit 4f535093cf8f6da8cfda7c36c2c1ecd2e9586ee4
> | PCI: Put pci_dev in device tree as early as possible
>
> It turns out we need to call acpi_pci_irq_add_prt() after the pci bridges
> are scanned.
>
> Bjorn said:
> The bus number binding means acpi_pci_irq_add_prt() has to happen
> after enumerating everything below a bridge, and it will prevent us
> from doing any bus number reassignment for hotplug.
>
> I think we should remove the bus numbers from the cached _PRT (or
> maybe even remove the _PRT caching completely). When we enable a PCI
> device's IRQ, we should search up the PCI device tree looking for a
> _PRT associated with each node, and applying normal PCI bridge
> swizzling when we don't find a _PRT. I think this can be done without
> using PCI bus numbers at all.
>
> So here we try to remove _PRT caching completely.
>
> -v2: check !handle early.
>
> Reported-and-tested-by: Peter Hurley <peter@...leysoftware.com>
Actually true now :)
Reported-and-tested-by: Peter Hurley <peter@...leysoftware.com>
Regards and thanks again,
Peter Hurley
PS - I just happened to see this version on the list. Would you please
cc me on any future versions?
--
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