Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5;
Message-ID: <fbf91189babaf640b573dfe3a1c68932718bda4e.camel@redhat.com>
Subject: Re: [PATCH 3/4] pci: move devres code from pci.c to devres.c
From:   Philipp Stanner <pstanner@redhat.com>
To:     Arnd Bergmann <arnd@kernel.org>,
        Bjorn Helgaas <bhelgaas@google.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Randy Dunlap <rdunlap@infradead.org>,
        Jason Gunthorpe <jgg@ziepe.ca>,
        Eric Auger <eric.auger@redhat.com>,
        Kent Overstreet <kent.overstreet@gmail.com>,
        Niklas Schnelle <schnelle@linux.ibm.com>,
        Neil Brown <neilb@suse.de>, John Sanpe <sanpeqf@gmail.com>,
        Dave Jiang <dave.jiang@intel.com>,
        Yury Norov <yury.norov@gmail.com>,
        Kees Cook <keescook@chromium.org>,
        Masami Hiramatsu <mhiramat@kernel.org>,
        David Gow <davidgow@google.com>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        Thomas Gleixner <tglx@linutronix.de>,
        "wuqiang.matt" <wuqiang.matt@bytedance.com>,
        Jason Baron <jbaron@akamai.com>,
        Ben Dooks <ben.dooks@codethink.co.uk>,
        Danilo Krummrich <dakr@redhat.com>
Cc:     linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
Date:   Tue, 21 Nov 2023 11:36:04 +0100
In-Reply-To: <3bc69019-7867-4f51-806d-02bf85a3cbf9@app.fastmail.com>
References: <20231120215945.52027-2-pstanner@redhat.com>
         <20231120215945.52027-5-pstanner@redhat.com>
         <3bc69019-7867-4f51-806d-02bf85a3cbf9@app.fastmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) 
MIME-Version: 1.0
Precedence: bulk

On Tue, 2023-11-21 at 11:17 +0100, Arnd Bergmann wrote:
> On Mon, Nov 20, 2023, at 22:59, Philipp Stanner wrote:
> > The file pci.c is very large and contains a number of devres-
> > functions.
> > These functions should now reside in devres.c
> >=20
> > There are a few callers left in pci.c that do devres operations.
> > These
> > should be ported in the future. Corresponding TODOs are added by
> > this
> > commit.
> >=20
> > The reason they are not moved right now in this commit is that
> > pci's
> > devres currently implements a sort of "hybrid-mode":
> > pci_request_region(), for instance, does not have a corresponding
> > pcim_
> > equivalent, yet. Instead, the function can be made managed by
> > previously
> > calling pcim_enable_device() (instead of pci_enable_device()). This
> > makes it unreasonable to move pci_request_region() to devres.c
> > Moving the functions would require changes to pci's API and is,
> > therefore, left for future work.
> >=20
> > Move as much devres-specific code from pci.c to devres.c as
> > possible.
> >=20
> > Suggested-by: Danilo Krummrich <dakr@redhat.com>
> > Signed-off-by: Philipp Stanner <pstanner@redhat.com>
> > ---
> > =C2=A0drivers/pci/devres.c | 243
> > +++++++++++++++++++++++++++++++++++++++++
> > =C2=A0drivers/pci/pci.c=C2=A0=C2=A0=C2=A0 | 249 -----------------------=
----------------
> > ----
> > =C2=A0drivers/pci/pci.h=C2=A0=C2=A0=C2=A0 |=C2=A0 24 +++++
> > =C2=A03 files changed, 267 insertions(+), 249 deletions(-)
>=20
> I had just commented in the other mail that you'd have to move
> these functions to devres.c for the file to make sense, but that
> I think the existing state is better.
>=20
> Just to clarify again here: this patch does not seem to improve
> anything to me,

Have you read the cover letter? It elaborates on that.

The idea behind centralizing devres-pci-code in a separate file is that
the current implementation is strangely torn.
My mid-term goal would be to fix that, but that's beyond the scope of
this series.

PCI has some separate devres functions, prefixed with pcim_ =E2=80=93 and t=
hen
there are some other functions that use a crazy hybrid mode:

drivers/pci/pci.c:

void pci_release_region(struct pci_dev *pdev, int bar)
{
	/* ..... SNIP ......... */

 dr =3D find_pci_dr(pdev);
 if (dr)
 dr->region_mask &=3D ~(1 << bar);
}

Some functions without pcim_ prefix switch to managed mode if
pcim_enable_device() instead of pci_enable_device() was called.

So some functions are sometimes managed and others never are, which is
totally inconsistent.

This is bug-provoking because programmers won't know without looking
very closely which functions become managed and which don't.

That should be fixed. And a first step towards that goal is to cleanly
split them. Everything managed should reside, on the long term, in
drivers/pci/devres.c

>  I'd much prefer leaving it the way it is, and
> moving the pcim_iomap family to corresponding drivers/pci/iomap.c.=20

We could branch that change out of the patch series and handle the
topics independently

P.

>=20
> =C2=A0=C2=A0=C2=A0=C2=A0 Arnd
>=20