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

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

Patch Review

**Correctness of the transformation:**

The old form:
```c
{0x1002, 0x6780, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TAHITI},
```
maps to `struct pci_device_id` fields: `.vendor=0x1002, .device=0x6780, .subvendor=PCI_ANY_ID, .subdevice=PCI_ANY_ID, .class=0, .class_mask=0, .driver_data=CHIP_TAHITI`.

The new form:
```c
{ PCI_DEVICE(0x1002, 0x6780), .driver_data = CHIP_TAHITI },
```
`PCI_DEVICE()` expands (`include/linux/pci.h:1052-1054`) to:
```c
.vendor = (vend), .device = (dev), .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID
```
The remaining fields (`.class`, `.class_mask`, `.override_only`) are implicitly zero-initialized. This is semantically identical.

**Sentinel entry:**

The change from `{0, 0, 0}` to `{ }` is correct — both produce a fully zeroed `struct pci_device_id`, which is the expected terminator for `MODULE_DEVICE_TABLE`.

**Consistency with existing code:**

The table already had entries using named initializers for the class-match CHIP_IP_DISCOVERY entries:
```c
{ PCI_DEVICE(0x1002, PCI_ANY_ID),
  .class = PCI_CLASS_DISPLAY_VGA << 8,
  .class_mask = 0xffffff,
  .driver_data = CHIP_IP_DISCOVERY },
```
These were left untouched. The patch makes the rest of the table match this style.

**Spot-checked entries:** Verified several entries across different chip families (TAHITI, PITCAIRN with AMD_IS_MOBILITY flags, KAVERI with AMD_IS_MOBILITY|AMD_IS_APU, etc.) — all PCI IDs and driver_data values are preserved exactly.

**The 309-line insertion / 309-line deletion count** confirms a clean 1:1 line mapping with no entries added or removed.

**No issues found.** The patch is a clean mechanical transformation with good motivation (readability + preparation for the `driver_data` anonymous union work referenced in the cover letter).

---
Generated by Claude Code Patch Reviewer