Claude review: drm/radeon: Consistently define pci_device_ids using named initializers

[Claude Code Review Bot <claude-review@example.com>]

Overall Series Review

Subject: drm/radeon: Consistently define pci_device_ids using named initializers
Author: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig=20=28The=20Capable=20Hub=29?=
 <u.kleine-koenig@baylibre.com>
Patches: 1
Reviewed: 2026-05-05T10:40:32.575422

---

This is a single patch, not a series. It converts 700 entries in `include/drm/drm_pciids.h` from raw positional struct initializers to using the `PCI_DEVICE()` macro with named `.driver_data` initializers.

**Correctness**: The transformation is semantically equivalent. The old format:
```c
{0x1002, 0xNNNN, PCI_ANY_ID, PCI_ANY_ID, 0, 0, driver_data_value}
```
maps to `struct pci_device_id` fields: `vendor=0x1002, device=0xNNNN, subvendor=PCI_ANY_ID, subdevice=PCI_ANY_ID, class=0, class_mask=0, driver_data=driver_data_value`.

The new format:
```c
{ PCI_DEVICE(0x1002, 0xNNNN), .driver_data = driver_data_value }
```
expands `PCI_DEVICE()` to `.vendor=(0x1002), .device=(0xNNNN), .subvendor=PCI_ANY_ID, .subdevice=PCI_ANY_ID`, and the unnamed fields (`class`, `class_mask`, `override_only`) are implicitly zero-initialized. This produces identical results.

**Motivation is sound**: The stated goal of enabling an anonymous union for `driver_data`/`driver_data_ptr` is a well-known cleanup effort across the kernel, and named initializers are a prerequisite. Even without that follow-up, this is a readability improvement.

**Risk**: Very low. The author claims binary equivalence of the compiled `pci_device_id` array, tested on x86 and arm64. The only consumer is `drivers/gpu/drm/radeon/radeon_drv.c:253`.

**Verdict**: Straightforward mechanical transformation. Looks good.

---
Generated by Claude Code Patch Reviewer