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

On Mon, Jul 20, 2026 at 02:03:47PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> Hello,
> 
> 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/[email protected]/
> 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/[email protected]
> .
> 
> 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?

-- 
With Best Regards,
Andy Shevchenko