Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 9 Aug 2021 12:42:44 -0500
From:   Bjorn Helgaas <helgaas@kernel.org>
To:     Jeremy Linton <jeremy.linton@arm.com>
Cc:     linux-pci@vger.kernel.org, lorenzo.pieralisi@arm.com,
        nsaenz@kernel.org, bhelgaas@google.com, rjw@rjwysocki.net,
        lenb@kernel.org, robh@kernel.org, kw@linux.com,
        f.fainelli@gmail.com, bcm-kernel-feedback-list@broadcom.com,
        linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-rpi-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] PCI: brcmstb: Add ACPI config space quirk
Message-ID: <20210809174244.GA2167737@bjorn-Precision-5520>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <51a11c89-d49b-7367-a75c-13016a2ea5d9@arm.com>
Precedence: bulk

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.

Bjorn