From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: drm: Consistently define pci_device_ids using named initializers
Date: Tue, 05 May 2026 08:10:52 +1000 [thread overview]
Message-ID: <review-patch1-20260504150537.2136760-2-u.kleine-koenig@baylibre.com> (raw)
In-Reply-To: <20260504150537.2136760-2-u.kleine-koenig@baylibre.com>
Patch Review
**gma500/psb_drv.c** -- Correct conversion. The old positional form:
```c
{ 0x8086, 0x8108, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &psb_chip_ops }
```
becomes:
```c
{ PCI_DEVICE(0x8086, 0x8108), .driver_data = (long) &psb_chip_ops }
```
`PCI_DEVICE` sets `.vendor`, `.device`, `.subvendor = PCI_ANY_ID`, `.subdevice = PCI_ANY_ID`, matching the original. The class/class_mask fields default to 0 just as before. The sentinel `{ 0, }` becoming `{ }` is also a nice cleanup. All 27 entries check out.
**loongson/lsdc_drv.c** -- Correct conversion. The old form already used `PCI_VDEVICE` but had positional `driver_data`:
```c
{PCI_VDEVICE(LOONGSON, 0x7a06), CHIP_LS7A1000}
```
The positional trailing value after `PCI_VDEVICE`'s `, 0, 0` expansion maps to `driver_data`, so switching to `.driver_data = CHIP_LS7A1000` is equivalent and more explicit. Also adds consistent whitespace inside the braces.
**mgag200/mgag200_drv.c** -- Correct conversion. The old form used `PCI_VENDOR_ID_MATROX` directly:
```c
{ PCI_VENDOR_ID_MATROX, 0x520, PCI_ANY_ID, PCI_ANY_ID, 0, 0, G200_PCI }
```
becomes:
```c
{ PCI_VDEVICE(MATROX, 0x0520), .driver_data = G200_PCI }
```
`PCI_VDEVICE(MATROX, ...)` expands to `.vendor = PCI_VENDOR_ID_MATROX`, so the vendor is identical. The trailing `, 0, 0` in `PCI_VDEVICE` covers class/class_mask, matching the original. The leading-zero normalization (0x520 -> 0x0520) is a nice touch for consistent 4-digit PCI device IDs. Sentinel also cleaned up from `{0,}` to `{ }`.
**qxl/qxl_drv.c** -- Correct conversion. This is the most interesting case because the original entries used class matching:
```c
{ 0x1b36, 0x100, PCI_ANY_ID, PCI_ANY_ID, PCI_CLASS_DISPLAY_VGA << 8, 0xffff00, 0 }
```
becomes:
```c
{ PCI_DEVICE(0x1b36, 0x0100), .class = PCI_CLASS_DISPLAY_VGA << 8, .class_mask = 0xffff00 }
```
`PCI_DEVICE` handles vendor/device/subvendor/subdevice, then `.class` and `.class_mask` are named explicitly, and `driver_data` defaults to 0 matching the original. This is the clearest win for readability -- the class-matching semantics are now obvious. The sentinel `{ 0, 0, 0 }` to `{ }` is also good.
**Minor nit:** In the qxl section, the brace style `}, {` on a single line (line 297 of the mbox) differs from the other drivers where each entry is on its own line. This is fine and arguably compact, but `}, \n\t{` might be slightly more consistent with the rest of the patch. Not a blocker.
**No functional issues found.** The conversions are all equivalent to the originals, the commit message accurately describes the change, and the motivation (preparing for the anonymous union in `driver_data`) is sound.
---
Generated by Claude Code Patch Reviewer
prev parent reply other threads:[~2026-05-04 22:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-04 15:05 [PATCH] drm: Consistently define pci_device_ids using named initializers Uwe Kleine-König (The Capable Hub)
2026-05-04 22:10 ` Claude review: " Claude Code Review Bot
2026-05-04 22:10 ` Claude Code Review Bot [this message]
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=review-patch1-20260504150537.2136760-2-u.kleine-koenig@baylibre.com \
--to=claude-review@example.com \
--cc=dri-devel-reviews@example.com \
/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