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

["Uwe Kleine-König (The Capable Hub)" <u.kleine-koenig@baylibre.com>]

[-- Attachment #1: Type: text/plain, Size: 2382 bytes --]

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@baylibre.com/
> > 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@kernel.org
> > .
> > 
> > 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]