linux-kernel - Re: [PATCH] ACPI, PCI: Get PRT entry during acpi_pci_enable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAE9FiQXan3J7-m2Wgd0pVybed_BgRAiqMGofh7t+vX_6e8zh7g@mail.gmail.com>
Date:	Fri, 15 Feb 2013 17:26:04 -0800
From:	Yinghai Lu <yinghai@...nel.org>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
Cc:	"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 Fri, Feb 15, 2013 at 4:39 PM, Bjorn Helgaas <bhelgaas@...gle.com> wrote:
> On Thu, Feb 14, 2013 at 5:50 PM, Yinghai Lu <yinghai@...nel.org> wrote:
>> On Tue, Feb 12, 2013 at 12:22 PM, Rafael J. Wysocki <rjw@...k.pl> wrote:
>>> On Tuesday, February 12, 2013 11:11:23 AM 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>
>>>> Suggested-by: Bjorn Helgaas <bhelgaas@...gle.com>
>>>> Signed-off-by: Yinghai Lu <yinghai@...nel.org>
>>>
>>> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
>>>
>>>> ---
>>>>  drivers/acpi/pci_irq.c      |   95 +++++++++++++++++---------------------------
>>>>  drivers/acpi/pci_root.c     |   18 --------
>>>>  drivers/pci/pci-acpi.c      |   24 -----------
>>>>  include/acpi/acpi_drivers.h |    5 --
>>>>  4 files changed, 38 insertions(+), 104 deletions(-)
>>
>> Bjorn,
>>
>> Can you put this one into pci/next?
>
> I'm not sure what this patch is based on or what the best way to merge
> it is.  It doesn't apply cleanly to my next or
> pci/yinghai-root-bus-hotplug branches.

My fault, that is based on pci/next + pm/linux-next

linux-next removed
acpi_power_resource_(un)register_device ...

>
> I did apply it manually on top of pci/yinghai-root-bus-hotplug to try
> it out, but we need to tweak the messages a little bit.
>
> Previously we printed "ACPI: PCI Interrupt Routing Table [%s._PRT]"
> once when loading it, which was fine.  Now we print it every time we
> look at a _PRT, which is too much because it isn't really adding any
> information.
>
> We also print "ACPI Exception: AE_NOT_FOUND, Evaluating _PRT
> [AE_NOT_FOUND] (20121018/pci_irq-259)" if we find ACPI nodes without
> _PRTs, which we shouldn't do, because that's a common and normal
> situation.

Sure. Can you have separated patch to do that ?

Or want me to resend the patch.

Thanks

Yinghai
--
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/