On Fri, Apr 07, 2017 at 06:12:05PM +0100, Ard Biesheuvel wrote:
> On 7 April 2017 at 18:06, Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote:
> > Hi Ard,
> >
> > On Fri, Apr 07, 2017 at 02:22:22PM +0100, Ard Biesheuvel wrote:
> >> We currently derive legacy interrupt routing by matching _PRT
> >> entries on the PCI device only, presumably under the assumption
> >> that PRT entries always have a value of 0xffff in the function
> >> field, meaning 'match all functions'.
> >
> > The spec (ACPI v6.0, sec 6.2.13) contains a note that:
> >
> > The PCI function number in the Address field of the _PRT packages
> > must be 0xFFFF, indicating "any" function number or "all functions".
> >
> > If we need a patch like this, we need to somehow reconcile it with
> > that spec text to make sure firmware and OS folks have a common
> > understanding of how this is supposed to work.
> >
> >> This no longer holds for modern PCIe topologies, where the
> >> legacy interrupts for different slots may be wired to different
> >> functions on the same bridge device. For instance, on AMD Seattle,
> >> we may have something like
> >>
> >> -[0000:00]-+-00.0 Advanced Micro Devices, Inc. [AMD] Device 1a00
> >> +-02.0 Advanced Micro Devices, Inc. [AMD] Device 1a01
> >> +-02.2-[01]----00.0 Renesas uPD720202 USB 3.0 Host Controller
> >> \-02.3-[02]----00.0 Realtek RTL8169 PCIe Gigabit Ethernet
> >>
> >> where the _PRT describes the legacy interrupt routing as
> >>
> >> Name (_PRT, Package () // _PRT: PCI Routing Table
> >> {
> >> // slot 1: dev 2 fn 1
> >> Package () { 0x20001, 0x0, 0x0, 0x140 },
> >> Package () { 0x20001, 0x1, 0x0, 0x141 },
> >> Package () { 0x20001, 0x2, 0x0, 0x142 },
> >> Package () { 0x20001, 0x3, 0x0, 0x143 },
> >>
> >> // slot 1: dev 2 fn 2
> >> Package () { 0x20002, 0x0, 0x0, 0x144 },
> >> Package () { 0x20002, 0x1, 0x0, 0x145 },
> >> Package () { 0x20002, 0x2, 0x0, 0x146 },
> >> Package () { 0x20002, 0x3, 0x0, 0x147 },
> >>
> >> // slot 1: dev 2 fn 3
> >> Package () { 0x20003, 0x0, 0x0, 0x148 },
> >> Package () { 0x20003, 0x1, 0x0, 0x149 },
> >> Package () { 0x20003, 0x2, 0x0, 0x14a },
> >> Package () { 0x20003, 0x3, 0x0, 0x14b }
> >> }) // _PRT
> >
> > But I think this _PRT description is incorrect and we should change
> > the _PRT rather than the kernel. My laptop has a basically identical
> > topology:
> >
> > -[0000:00]-+-00.0 Intel Corporation Sky Lake Host Bridge/DRAM Registers
> > +-1c.0-[02]----00.0 Realtek Semiconductor Co., Ltd. Device 525a
> > +-1c.2-[04]----00.0 Intel Corporation Wireless 8260
> >
> > and the ASL looks like this (paraphrased):
> >
> > Device (EXP1) {
> > Name (_ADR, 0x001C0000)
> > Name (_PRT) {
> > Package () { 0xFFFF, 0x00, \_SB.LNKA, 0x00 },
> > Package () { 0xFFFF, 0x01, \_SB.LNKB, 0x00 },
> > ...
> > }
> > }
> > Device (EXP3) {
> > Name (_ADR, 0x001C0002)
> > Name (_PRT) {
> > Package () { 0xFFFF, 0x00, \_SB.LNKC, 0x00 },
> > Package () { 0xFFFF, 0x01, \_SB.LNKD, 0x00 },
> > ...
> > }
> > }
> >
>
> Thanks for the explanation. But how is this wired up into the PNP0A08
> device then? IOW, how does the ACPI code in Linux discover the
> relation between these devices and my PCI root device?
Device (PCI0) {
Name (_ADR, 0x00)
Name (_HID, "PNP0A08")
Device (EXP1) { ... }
Device (EXP3) { ... }
}
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
