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.
