From: "Uwe Kleine-König (The Capable Hub)" <u.kleine-koenig@baylibre.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Vinod Koul <vkoul@kernel.org>,
Markus Schneider-Pargmann <msp@baylibre.com>,
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
Subject: Re: [PATCH] dmaengine: Consistently define pci_device_ids using named initializers
Date: Mon, 4 May 2026 15:55:00 +0200 [thread overview]
Message-ID: <afijNvdU6HPbjDCX@monoceros> (raw)
In-Reply-To: <afh0-BSmchvY-W-d@ashevche-desk.local>
[-- Attachment #1: Type: text/plain, Size: 3564 bytes --]
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.
> ...
>
> > 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.
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) },
. For someone who doesn't know what PCI_DEVICE_DATA does, the latter is
less understandable.
Also PCI_DEVICE_DATA has a cast which is something I want to get rid of.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2026-05-04 13:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-04 10:20 [PATCH] dmaengine: Consistently define pci_device_ids using named initializers Uwe Kleine-König (The Capable Hub)
2026-05-04 10:29 ` Andy Shevchenko
2026-05-04 13:55 ` Uwe Kleine-König (The Capable Hub) [this message]
2026-05-04 14:09 ` Andy Shevchenko
2026-05-04 16:38 ` Uwe Kleine-König (The Capable Hub)
2026-05-05 7:01 ` Andy Shevchenko
2026-05-05 7:04 ` Andy Shevchenko
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=afijNvdU6HPbjDCX@monoceros \
--to=u.kleine-koenig@baylibre.com \
--cc=Basavaraj.Natikar@amd.com \
--cc=Frank.Li@kernel.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=dmaengine@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mani@kernel.org \
--cc=msp@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