From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: "Uwe Kleine-König (The Capable Hub)" <u.kleine-koenig@baylibre.com>
Cc: Vinod Koul <vkoul@kernel.org>,
Basavaraj Natikar <Basavaraj.Natikar@amd.com>,
Frank Li <Frank.Li@kernel.org>,
Manivannan Sadhasivam <mani@kernel.org>,
Viresh Kumar <vireshk@kernel.org>,
dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org,
Frank Li <Frank.Li@nxp.com>
Subject: Re: [PATCH v3 2/2] dmaengine: Consistently define pci_device_ids using named initializers
Date: Tue, 11 Aug 2026 16:39:44 +0300 [thread overview]
Message-ID: <ansmIBcCdXlkOS4W@ashevche-desk.local> (raw)
In-Reply-To: <148354eaf657c30428c678baaef07b2ff9888c00.1784547700.git.u.kleine-koenig@baylibre.com>
On Mon, Jul 20, 2026 at 02:03:49PM +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.
>
> While touching these arrays, unify the list terminators to be just an
> empty struct with no trailing comma.
>
> This change doesn't introduce changes to the compiled pci_device_id
> arrays, which was confirmed using x86 and arm64 builds.
...
> +++ b/drivers/dma/dw-edma/dw-edma-pcie.c
> static const struct pci_device_id dw_edma_pcie_id_table[] = {
> { PCI_DEVICE_DATA(SYNOPSYS, EDDA, &snps_edda_data) },
> { PCI_VDEVICE(XILINX, PCI_DEVICE_ID_XILINX_B054),
> - (kernel_ulong_t)&xilinx_mdb_data },
> + .driver_data = (kernel_ulong_t)&xilinx_mdb_data },
> { PCI_VDEVICE(XILINX, PCI_DEVICE_ID_XILINX_B00F),
> .driver_data = (kernel_ulong_t)&xilinx_cpm6_dma_data },
It's inconsistent and can use PCI_DEVICE_DATA() in all cases.
> { }
...
> +++ b/drivers/dma/pch_dma.c
> 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 */
> + { }
> };
And I'm still strongly against this churn, which also makes lines too long.
PCI_DEVICE_DATA() makes it condensed and moves the burden of any future
conversions to the macro without touching users again.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2026-08-11 13:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-20 12:03 [PATCH v3 0/2] dmaengine: Use named initializers for arrays of pci_device_id Uwe Kleine-König (The Capable Hub)
2026-07-20 12:03 ` [PATCH v3 1/2] dmaengine: hsu: Drop unused pci driver data Uwe Kleine-König (The Capable Hub)
2026-07-20 12:03 ` [PATCH v3 2/2] dmaengine: Consistently define pci_device_ids using named initializers Uwe Kleine-König (The Capable Hub)
2026-08-11 13:39 ` Andy Shevchenko [this message]
2026-08-11 13:45 ` [PATCH v3 0/2] dmaengine: Use named initializers for arrays of pci_device_id Andy Shevchenko
2026-08-11 14:43 ` Uwe Kleine-König (The Capable Hub)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ansmIBcCdXlkOS4W@ashevche-desk.local \
--to=andriy.shevchenko@linux.intel.com \
--cc=Basavaraj.Natikar@amd.com \
--cc=Frank.Li@kernel.org \
--cc=Frank.Li@nxp.com \
--cc=dmaengine@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mani@kernel.org \
--cc=u.kleine-koenig@baylibre.com \
--cc=vireshk@kernel.org \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox