linux-kernel - Re: [RFC PATCH 1/3] PCI: Add standard PCI Config Address macros

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] [day] [month] [year] [list]

Message-ID: <20220913215300.GA626928@bhelgaas>
Date:   Tue, 13 Sep 2022 16:53:00 -0500
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     Pali Rohár <pali@...nel.org>
Cc:     Bjorn Helgaas <bhelgaas@...gle.com>,
        Lorenzo Pieralisi <lpieralisi@...nel.org>,
        Rob Herring <robh@...nel.org>,
        Krzysztof Wilczyński <kw@...ux.com>,
        Sergio Paracuellos <sergio.paracuellos@...il.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org
Subject: Re: [RFC PATCH 1/3] PCI: Add standard PCI Config Address macros

On Tue, Sep 13, 2022 at 11:24:21PM +0200, Pali Rohár wrote:
> 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@...nel.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.

I would love to see that happen, too, and that could be a reason to
put pci-conf.h in include/linux.  But this series doesn't include
that.

> > 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.
> 
> 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.

drivers/pci/pci.h

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

Of course not, I didn't suggest or expect that.  What I'm trying to
point out is that I don't think we have very good reasons for
pci-ecam.h to be public.  And therefore, I don't think we need
pci-conf1.h to be next to it.

Unless you want to convert the arch/x86 code to use them as well.  I'm
not asking you to do that either, just that if you *did* do that, it
would be an argument for keeping the macros where you put them.

Bjorn