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

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Tue, May 05, 2026 at 10:01:35AM +0300, Andy Shevchenko wrote:
> On Mon, May 04, 2026 at 06:38:51PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> > On Mon, May 04, 2026 at 05:09:55PM +0300, Andy Shevchenko wrote:
> > > 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:

...

> > > > > >  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 :-)
> > 
> > Seems to be subjective.
> > 
> > > > 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) },
> > 
> > Agreed. That doesn't considerably weaken my reasoning however.
> > 
> > > > . 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 agreed. But other bad macros don't justify using that (admittedly
> > subjectively) bad PCI_DEVICE_DATA macro that mixes device identity
> > (.vendor, .device, .subvendor and .subdevice) with a driver specific
> > struct member.
> > 
> > > > 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.
> > 
> > This would require another (subjectively bad) macro PCI_DEVICE_DATAPTR.
> > I think I let someone else tackle that quest.
> 
> No, it wouldn't. Since we support C11, we have _Generic(). It may be used.

The example you probably want to look at is
d7cdbbc93c56 ("software node: allow referencing firmware nodes")
(yes, it's not a union there, but I think we can manage unions as well).

> And please use PCI_DEVICE_DATA() in this driver.

-- 
With Best Regards,
Andy Shevchenko