Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 13 Sep 2022 23:24:21 +0200
From:   Pali =?utf-8?B?Um9ow6Fy?= <pali@kernel.org>
To:     Bjorn Helgaas <helgaas@kernel.org>
Cc:     Bjorn Helgaas <bhelgaas@google.com>,
        Lorenzo Pieralisi <lpieralisi@kernel.org>,
        Rob Herring <robh@kernel.org>,
        Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= <kw@linux.com>,
        Sergio Paracuellos <sergio.paracuellos@gmail.com>,
        Matthias Brugger <matthias.bgg@gmail.com>,
        linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [RFC PATCH 1/3] PCI: Add standard PCI Config Address macros
Message-ID: <20220913212421.yblwhgbd7zpdg5eo@pali>
References: <20220911112024.14304-2-pali@kernel.org>
 <20220913211143.GA624473@bhelgaas>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20220913211143.GA624473@bhelgaas>
User-Agent: NeoMutt/20180716
Precedence: bulk

On Tuesday 13 September 2022 16:11:43 Bjorn Helgaas wrote:
> On Sun, Sep 11, 2022 at 01:20:22PM +0200, Pali Rohár wrote:
> > Lot of PCI and PCIe controllers are using standard Config Address for PCI
> > Configuration Mechanism #1 (as defined inPCI Local Bus Specification) or
> > its extended version.
> > 
> > So introduce new macros PCI_CONF1_ADDRESS() and PCI_CONF1_EXT_ADDRESS() in
> > new include file linux/pci-conf1.h which can be suitable for PCI and PCIe
> > controllers which uses this type of access to PCI config space.
> > 
> > Signed-off-by: Pali Rohár <pali@kernel.org>
> > ---
> >  include/linux/pci-conf1.h | 51 +++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 51 insertions(+)
> >  create mode 100644 include/linux/pci-conf1.h
> 
> This seems like a nice addition, but it would be nice if we could
> encapsulate it in drivers/pci.
> 
> I know it's parallel to the existing include/linux/pci-ecam.h.  I wish
> we could encapsulate *that* in drivers/pci, too.  For pci-ecam.h, I
> think the only things that prevent that are drivers/acpi/pci_mcfg.c,
> loongarch, and a few arm64 things.

As these macros describe original Intel x86 API, it can be used also in
arch/x86 PCI code.

> pci_mcfg.c arguably would make more sense in drivers/pci; it uses
> acpi_table_parse(), but no other ACPI services.
> 
> The arm64 code that uses pci-ecam.h is really generic code that would
> not be in arch/arm64 except for the fact that x86 has really ugly
> legacy x86-specific mmconfig code.

IIRC that legacy x86-specific code is used also on modern AMD processors
which have broken ECAM. AMD supports that extended version of CF8/CFC
with access to PCIe extended config space registers.

> I guess that's a long-winded way of saying that I think maybe we could
> put this in drivers/pci/pci.h even though the parallel ECAM stuff is
> in include/linux/pci-ecam.h.
> 
> Bjorn

Well, if you like this change, let me know where to put those new
macros, into which file and in which subdirectory, and I can prepare a
new patch version.

But doing all those arm64, x86, ACPI cleanup is a huge cross-tree work
which I'm really not going to do...