Re: [PATCH] scsi: Consistently define pci_device_ids using named initializers

Uwe Kleine-König (The Capable Hub) <[email protected]> Fri, 17 Jul 2026 12:00:27 +0200
Newsgroups org.kernel.vger.target-devel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-scsi
Message-ID <aln8-b9iFDzAPo6V@monoceros>
--r37dgzn723qnryre
Content-Type: text/plain; protected-headers=v1; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PATCH] scsi: Consistently define pci_device_ids using named
 initializers
MIME-Version: 1.0

On Tue, Jun 09, 2026 at 05:34:40PM +0200, Uwe Kleine-K=F6nig (The Capable H=
ub) wrote:
> [Dropping Bradley Grove and Michael Reed from Cc: as their addresses
> bounced]
>=20
> On Wed, Apr 29, 2026 at 12:18:20PM +0200, Uwe Kleine-K=F6nig (The Capable=
 Hub) wrote:
> > ... and PCI device helpers.
> >=20
> > The various struct pci_device_id arrays were initialized mostly by one
> > of the PCI_DEVICE macros and then list expressions. The latter isn't
> > easily readable if you're not into PCI. Using named initializers is more
> > explicit and thus easier to parse.
> >=20
> > Also use PCI_DEVICE* helper macros to assign .vendor, .device,
> > .subvendor and .subdevice where appropriate and skip explicit
> > assignments of 0 (which the compiler takes care of).
> >=20
> > The secret plan is to make struct pci_device_id::driver_data an
> > anonymous union (similar to
> > https://lore.kernel.org/all/cover.1776579304.git.u.kleine-koenig@baylib=
re.com/)
> > and that requires named initializers. But it's also a nice cleanup on
> > its own.
> >=20
> > This change doesn't introduce changes to the compiled pci_device_id
> > arrays. Tested on x86 and arm64.
> >=20
> > Signed-off-by: Uwe Kleine-K=F6nig (The Capable Hub) <u.kleine-koenig@ba=
ylibre.com>
> > ---
> > Hello,
> >=20
> > the mentioned follow-up quest allows to do
> >=20
> > 	-	{ PCI_VDEVICE(TTI, 0x3220), .driver_data =3D (kernel_ulong_t)&hptiop=
_itl_ops },
> > 	+	{ PCI_VDEVICE(TTI, 0x3220), .driver_data_ptr =3D &hptiop_itl_ops },
> >=20
> > which gets rid of a bunch of casts and so brings a little bit more type
> > safety. This patch is a preparation for that.
> >=20
> > I assume a single patch for all of drivers/scsi is fine. If not I can
> > split per driver.
>=20
> Is this patch still on someone's radar?

Hmm, it seems it isn't? Who is the right person to prod?

FTR: The patch still applies fine to next-20260716.

Best regards
Uwe

--r37dgzn723qnryre
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEP4GsaTp6HlmJrf7Tj4D7WH0S/k4FAmpZ/TkACgkQj4D7WH0S
/k4xwQf/VnEmioC8FCW5Ncvp7+gyqhkHvcGCyU/nsGhIZWW5IoHPdkJAiAiQPBRB
My/lY/RZxov08i89DVATsE25Ht1QLoTb7ACOfBzVd+X+Q6cCm/V1HsGrqGH7h5yz
tEjqztO+uiLCsB6/CjjnEIkrogjuoP6wT/fP4eSBy4Bggnx/sOyFX+uo3Zgo4MHm
JIBqSFu9qH+eeU4D+O8PxMl91zUsZ0S2/DbnnhfRmm3u3nWuQEhkGVuordux/EGC
qckWm81ioee2Qu+8lN8KmBWB3Nv2EMoQ6R7gDWs+fr5pzMHHnKzH6vjDQGa9xq3T
AvnzuB+KI/UCWcuR0medIUDxP2C/Gg==
=1KpO
-----END PGP SIGNATURE-----

--r37dgzn723qnryre--