Re: [PATCH v3 0/2] dmaengine: Use named initializers for arrays of pci_device_id

From: Uwe Kleine-König (The Capable Hub)

Date: Tue Aug 11 2026 - 10:48:29 EST


Hello Andy,

On Tue, Aug 11, 2026 at 04:45:01PM +0300, Andy Shevchenko wrote:
> On Mon, Jul 20, 2026 at 02:03:47PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> > the objective of this patch series is to prepare drivers/dma for a
> > change of pci_device_id that requires all users to initialize
> > .driver_data by name. See
> > https://lore.kernel.org/all/cover.1780048925.git.u.kleine-koenig@xxxxxxxxxxxx/
> > for more details. (This is about platform_device_id, but I intend to do
> > that for pci_device_id in the same manner.)
> >
> > v2 is available at
> > https://lore.kernel.org/dmaengine/cover.1781161455.git.ukleinek@xxxxxxxxxx
> > .
> >
> > Changes since then:
> >
> > - Rebase to current next
> > - Add review tags by Frank Li and Andy Shevchenko
> > - Fix commit log to talk about the right device_id type (i.e.
> > pci_device_id and neither pnp nor platform) (partly found by Sashiko)
> >
> > Note that Andy prefers the use of PCI_DEVICE_DATA() over PCI_VDEVICE() +
> > explicit .driver_data because the former is more compact and the
> > follow-up change to struct pci_device_id could be handled in the
> > definition of that macro. I disagree here, as the compactness is bought
> > with quite some magic in the #define once it handles the union, and
> > being explicit (and thus less compact) has its merits, too. Additionally
> > the affected drivers need an adaption anyhow in their probe function,
> > and switching both .probe() and the .id_table in a single patch seems
> > right to me. Because from my POV my subjective opinion is obviously the
> > right one, I didn't follow Andy's request.
>
> I think we have not enough understanding regarding implementation. I'm not sure
> how the union will affect the change in the drivers. When each driver is going
> to be changed to support whatever pointers you want (CFI) this won't affect the
> ID table. and hence makes _less_ churn.
>
> Do you have a Git repository to show an example of the road map of the changes
> for, say, one single driver on your choice to see the difference between your
> approach and my suggestion?

No, but I think I explained it in enough detail at
https://lore.kernel.org/all/af7yKdRdDSJjkoIk@monoceros/ . If the
description there still provokes open questions, please ask (maybe in
that thread).

Best regards
Uwe

Attachment: signature.asc
Description: PGP signature