On Mon, Aug 09, 2021 at 02:48:17PM -0500, Jeremy Linton wrote:
> 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.
Wow, that's ... special.
I think I would include "ecam" or something in the name. There might
be a variety of quirks, e.g., "P2PDMA allowed between root ports",
that could reasonably fit under "linux-pcie-quirk".
