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

From: Andy Shevchenko

Date: Mon May 04 2026 - 10:10:16 EST


On Mon, May 04, 2026 at 03:55:00PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> On Mon, May 04, 2026 at 01:29:12PM +0300, Andy Shevchenko wrote:
> > On Mon, May 04, 2026 at 12:20:06PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> > > The .driver_data member of the various struct pci_device_id arrays were
> > > initialized by list expressions. This isn't easily readable if you're
> > > not into PCI. Using named initializers is more explicit and thus easier
> > > to parse. Also skip explicit assignments of 0 (which the compiler then
> > > takes care of).
> > >
> > > This change doesn't introduce changes to the compiled pci_device_id
> > > arrays. Tested on x86 and arm64.
> >
> > HSU driver has different change ("Also" is a strong sign to the split required).
>
> HSU is in the category "skip explicit assignments of 0", so I think
> that's fine. I could be talked into splitting if that's what is wanted.

Yes, please. I will Rb/Ack it immediately when standalone change.

...

> > > static const struct pci_device_id pch_dma_id_table[] = {
> > > - { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_EG20T_PCH_DMA_8CH), 8 },
> > > - { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_EG20T_PCH_DMA_4CH), 4 },
> > > - { PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7213_DMA1_8CH), 8}, /* UART Video */
> > > - { PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7213_DMA2_8CH), 8}, /* PCMIF SPI */
> > > - { PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7213_DMA3_4CH), 4}, /* FPGA */
> > > - { PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7213_DMA4_12CH), 12}, /* I2S */
> > > - { PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7223_DMA1_4CH), 4}, /* UART */
> > > - { PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7223_DMA2_4CH), 4}, /* Video SPI */
> > > - { PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7223_DMA3_4CH), 4}, /* Security */
> > > - { PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7223_DMA4_4CH), 4}, /* FPGA */
> > > - { PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7831_DMA1_8CH), 8}, /* UART */
> > > - { PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7831_DMA2_4CH), 4}, /* SPI */
> > > - { 0, },
> > > + { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_EG20T_PCH_DMA_8CH), .driver_data = 8 },
> > > + { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_EG20T_PCH_DMA_4CH), .driver_data = 4 },
> > > + { PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7213_DMA1_8CH), .driver_data = 8 }, /* UART Video */
> > > + { PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7213_DMA2_8CH), .driver_data = 8 }, /* PCMIF SPI */
> > > + { PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7213_DMA3_4CH), .driver_data = 4 }, /* FPGA */
> > > + { PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7213_DMA4_12CH), .driver_data = 12 }, /* I2S */
> > > + { PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7223_DMA1_4CH), .driver_data = 4 }, /* UART */
> > > + { PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7223_DMA2_4CH), .driver_data = 4 }, /* Video SPI */
> > > + { PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7223_DMA3_4CH), .driver_data = 4 }, /* Security */
> > > + { PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7223_DMA4_4CH), .driver_data = 4 }, /* FPGA */
> > > + { PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7831_DMA1_8CH), .driver_data = 8 }, /* UART */
> > > + { PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7831_DMA2_4CH), .driver_data = 4 }, /* SPI */
> > > + { },
> > > };
> >
> > Use PCI_DEVICE_DATA() instead. Same may apply to DesignWare, but one needs to
> > define the device IDs. I think I may help with that.
>
> I'm not a fan of PCI_DEVICE_DATA. While it could indeed be used to
> shorten the assignments here, it's less readable in my opinion.

I'm not fun of these long unreadable lines with tons of repetitions :-)

> Compare
>
> { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_EG20T_PCH_DMA_4CH), .driver_data = 4 },
>
> with
>
> { PCI_DEVICE_DATA(INTEL, PCI_DEVICE_ID_EG20T_PCH_DMA_4CH, 4) },

First of all, with

{ PCI_DEVICE_DATA(INTEL, EG20T_PCH_DMA_4CH, 4) },

> . For someone who doesn't know what PCI_DEVICE_DATA does, the latter is
> less understandable.

Same applicable to many other macros. I don't consider this argument viable.

> Also PCI_DEVICE_DATA has a cast which is something I want to get rid of.

Yes, and you will get rid of in one place instead of tons of them.

--
With Best Regards,
Andy Shevchenko