Received-SPF: pass (google.com: domain of linux-kernel+bounces-29914-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <96f355a41bf42c6a604aec37449d35246395d929.camel@redhat.com>
Subject: Re: [PATCH 00/10] Make PCI's devres API more consistent
From: Philipp Stanner <pstanner@redhat.com>
To: andy.shevchenko@gmail.com
Cc: Jonathan Corbet <corbet@lwn.net>, Hans de Goede <hdegoede@redhat.com>, 
 Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Maxime Ripard
 <mripard@kernel.org>, Thomas Zimmermann <tzimmermann@suse.de>, David Airlie
 <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, Bjorn Helgaas
 <bhelgaas@google.com>, Sam Ravnborg <sam@ravnborg.org>, dakr@redhat.com,
 linux-doc@vger.kernel.org,  linux-kernel@vger.kernel.org,
 dri-devel@lists.freedesktop.org,  linux-pci@vger.kernel.org
Date: Thu, 18 Jan 2024 09:48:11 +0100
In-Reply-To: <5e760f104c75efe37100cee5a26b7ee3581f03b4.camel@redhat.com>
References: <20240115144655.32046-2-pstanner@redhat.com>
	 <ZabyY3csP0y-p7lb@surfacebook.localdomain>
	 <5e760f104c75efe37100cee5a26b7ee3581f03b4.camel@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) 
Precedence: bulk
MIME-Version: 1.0

On Wed, 2024-01-17 at 10:59 +0100, Philipp Stanner wrote:
> On Tue, 2024-01-16 at 23:17 +0200, andy.shevchenko@gmail.com=C2=A0wrote:
> > Mon, Jan 15, 2024 at 03:46:11PM +0100, Philipp Stanner kirjoitti:

[...]

> >=20
> >=20
> > > PCI's devres API suffers several weaknesses:
> > >=20
> > > 1. There are functions prefixed with pcim_. Those are always
> > > managed
> > > =C2=A0=C2=A0 counterparts to never-managed functions prefixed with pc=
i_ =E2=80=93
> > > or
> > > so one
> > > =C2=A0=C2=A0 would like to think. There are some apparently unmanaged
> > > functions
> > > =C2=A0=C2=A0 (all region-request / release functions, and pci_intx())=
 which
> > > =C2=A0=C2=A0 suddenly become managed once the user has initialized th=
e
> > > device
> > > with
> > > =C2=A0=C2=A0 pcim_enable_device() instead of pci_enable_device(). Thi=
s
> > > "sometimes
> > > =C2=A0=C2=A0 yes, sometimes no" nature of those functions is confusin=
g and
> > > =C2=A0=C2=A0 therefore bug-provoking. In fact, it has already caused =
a bug
> > > in
> > > DRM.
> > > =C2=A0=C2=A0 The last patch in this series fixes that bug.
> > > 2. iomappings: Instead of giving each mapping its own callback,
> > > the
> > > =C2=A0=C2=A0 existing API uses a statically allocated struct tracking=
 one
> > > mapping
> > > =C2=A0=C2=A0 per bar. This is not extensible. Especially, you can't c=
reate
> > > =C2=A0=C2=A0 _ranged_ managed mappings that way, which many drivers w=
ant.
> > > 3. Managed request functions only exist as "plural versions" with
> > > a
> > > =C2=A0=C2=A0 bit-mask as a parameter. That's quite over-engineered
> > > considering
> > > =C2=A0=C2=A0 that each user only ever mapps one, maybe two bars.
> > >=20
> > > This series:
> > > - add a set of new "singular" devres functions that use devres
> > > the
> > > way
> > > =C2=A0 its intended, with one callback per resource.
> > > - deprecates the existing iomap-table mechanism.
> > > - deprecates the hybrid nature of pci_ functions.
> > > - preserves backwards compatibility so that drivers using the
> > > existing
> > > =C2=A0 API won't notice any changes.
> > > - adds documentation, especially some warning users about the
> > > =C2=A0 complicated nature of PCI's devres.
> >=20
> > Instead of adding pcim_intx(), please provide proper one for
> > pci_alloc_irq_vectors(). Ideally it would be nice to deprecate
> > old IRQ management functions in PCI core and delete them in the
> > future.
> >=20
>=20
> In order to deprecate the intermingling with half-managed hyprid
> devres
> in pci.c, you need to have pci_intx() be backwards compatible. Unless
> you can remove it at once.
> And the least broken way to do that I thought would be pcim_intx(),
> because that's consistent with how I make pci_request_region() & Co.
> call into their managed counterparts.
>=20
> There are 25 users of pci_intx().
> We'd have to look how many of them call pcim_enable_device() and how
> easy they would be to port to... pci_alloc_irq_vectors() you say? I
> haven't used that before. Would have to look into it and see how we
> could do that.

Alright, so I thought about that a bit.

So pci_intx() is the old way to do it and you would like to deprecate
it for good. Understood, makes sense

This series, however, is about deprecating PCI's broken devres
implementation =E2=80=93 not about deprecating outdated PCI features in
general.

So I wouldn't like to touch anything here unless cleaning up devres
demands it.
Now the question would be: how can we solve this?

My suggestion would be:
Let's implement pcim_intx(), but only make it visible through
drivers/pci/pci.h. So we won't make it usable for other drivers, don't
EXPORT_SYMBOL() it and basically only have it as a tool to move the
devres-part clearly and cleanly from pci.c to devres.c

Further deprecating old PCI stuff could then be done in a separate
series.

ACK?

P.


>=20
>=20
> P.