linux-kernel - Re: [PATCH 2/3] PCI: brcmstb: Add ACPI config space quirk

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: <4d4732b9-e8df-3803-2db7-c6eef1196269@arm.com>
Date:   Mon, 9 Aug 2021 14:48:17 -0500
From:   Jeremy Linton <jeremy.linton@....com>
To:     Bjorn Helgaas <helgaas@...nel.org>
Cc:     linux-pci@...r.kernel.org, lorenzo.pieralisi@....com,
        nsaenz@...nel.org, bhelgaas@...gle.com, rjw@...ysocki.net,
        lenb@...nel.org, robh@...nel.org, kw@...ux.com,
        f.fainelli@...il.com, bcm-kernel-feedback-list@...adcom.com,
        linux-acpi@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-rpi-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] PCI: brcmstb: Add ACPI config space quirk

Hi,

On 8/9/21 12:42 PM, Bjorn Helgaas wrote:
> On Fri, Aug 06, 2021 at 09:55:27PM -0500, Jeremy Linton wrote:
>> Hi,
>>
>> On 8/6/21 5:21 PM, Bjorn Helgaas wrote:
>>> On Thu, Aug 05, 2021 at 04:11:59PM -0500, Jeremy Linton wrote:
>>>> The PFTF CM4 is an ACPI platform that is following the PCIe SMCCC
>>>> standard because its PCIe config space isn't ECAM compliant and is
>>>> split into two parts. One part for the root port registers and a
>>>> moveable window which points at a given device's 4K config space.
>>>> Thus it doesn't have a MCFG (and really any MCFG provided would be
>>>> nonsense anyway). As Linux doesn't support the PCIe SMCCC standard
>>>> we key off a Linux specific host bridge _DSD to add custom ECAM
>>>> ops and cfgres. The cfg op selects between those two regions, as
>>>> well as disallowing problematic accesses, particularly if the link
>>>> is down because there isn't an attached device.
>>>
>>> I'm not sure SMCCC is *really* relevant here.  If it is, an expansion
>>> of the acronym and a link to a spec would be helpful.
>>>
>>> But AFAICT the only important thing here is that it doesn't have
>>> standard ECAM, and we're going to work around that.
>>
>> I will reword it a bit.
>>
>>> I don't see anything about _DSD in this series.
>>
>> That is the "linux,pci-quirk" in the next patch.
> 
> The next patch doesn't mention _DSD either.  Is it obfuscated by
> being inside fwnode_property_read_string()?  If so, it's well and
> truly hidden; I gave up trying to connect that with ACPI.

Right, the fwnode stuff works as a DT/ACPI abstraction for reading 
values from firmware tables. In this case the ACPI definition looks 
something like:

Device(PCI0) {
...
   Name (_DSD, Package () {
   ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
     Package () {
     Package () { "linux-pcie-quirk", "bcm2711" },
   }
   })

...
}

Which explains a bit of why the underlying code is a bit uh... complicated.