Claude review: drm/xe/xe_hw_error: Integrate DRM RAS with hardware error handling

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

Patch Review

**Loss of FATAL vs NONFATAL distinction in log messages:**
The old code logged distinct strings ("CORRECTABLE", "NONFATAL", "FATAL"). The new code collapses NONFATAL and FATAL into "uncorrectable-errors":

```c
+static enum drm_xe_ras_error_severity hw_err_to_severity(const enum hardware_error hw_err)
+{
+	if (hw_err == HARDWARE_ERROR_CORRECTABLE)
+		return DRM_XE_RAS_ERR_SEV_CORRECTABLE;
+
+	/* Uncorrectable errors comprise of both fatal and non-fatal errors */
+	return DRM_XE_RAS_ERR_SEV_UNCORRECTABLE;
+}
```

While this mapping is correct for the RAS counter abstraction, using the severity string directly in kernel log messages (e.g. `"HEC FW %s %s reported"`) loses important diagnostic information. A FATAL error requiring firmware flash vs a NONFATAL error should be distinguishable in `dmesg`. Consider keeping a separate `hw_error_to_str()` for log messages while using `hw_err_to_severity()` for counter bucketing.

**`hw_error_info_init` only for PVC but handler is still Battlemage-gated:**
```c
+static int hw_error_info_init(struct xe_device *xe)
+{
+	if (xe->info.platform != XE_PVC)
+		return 0;
+	return xe_drm_ras_init(xe);
+}
```

In this patch, `hw_error_source_handler` still checks `xe->info.platform != XE_BATTLEMAGE`, so Battlemage will still enter the handler but without RAS info initialized. The `info` pointer will be NULL. This is addressed in patch 4 with the `if (!info) goto clear_reg` guard, but it means this patch alone has a potential NULL dereference on Battlemage if applied independently (broken bisectability).

---

---
Generated by Claude Code Patch Reviewer