Claude review: drm/xe/xe_ras: Add support for error counter

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

Patch Review

Marked "Do not review, CI only" — I'll note substantive issues only.

**Issues:**

1. **`get_counter` doesn't check `response.status`**: In `get_counter()`:
```c
	common = &response.counter.common;
	*value = response.value;
```
It reads the response value without checking any status field. Compare with `xe_ras_clear_counter()` which does:
```c
	ret = ras_status_to_errno(response.status);
	if (ret) { ... }
```
The `xe_ras_get_counter_response` struct does have a `threshold` field but no explicit `status` field, while `xe_ras_clear_counter_response` has a `status` field. If the firmware can report errors in the get-counter response, this is a bug. If the protocol doesn't include status in get-counter responses, then the structures are correct but the asymmetry should be documented.

2. **Probe order change**: The patch moves `xe_soc_remapper_init()` and `xe_sysctrl_init()` earlier in `xe_device_probe()`, before display and GT initialization. The commit message doesn't explain why this reordering is needed. Moving init earlier could introduce regressions if the remapper/sysctrl depends on state set up between the old and new positions.

3. **Mixed initialization style**: Uses `= {0}` throughout:
```c
	struct xe_ras_get_counter_response response = {0};
```
While patch 3 uses `= {}`. Should be consistent; `= {}` is the preferred kernel style.

4. **`xe_ras_get_counter` parameter name mismatch**: The function signature uses `component` as the third parameter, but the caller (`query_error_counter` in `xe_drm_ras.c`) passes `error_id`:
```c
return xe_ras_get_counter(xe, severity, error_id, val);
```
This works because the DRM RAS error_id IS the component enum value, but the naming conflation is confusing. The `query_error_counter` callback receives `error_id` (which ranges over the counter range, which is set to `DRM_XE_RAS_ERR_COMP_CORE_COMPUTE..DRM_XE_RAS_ERR_COMP_MAX-1`), and `xe_ras_get_counter` calls it `component`. Naming it consistently would help.

5. **Large reserved array in `xe_ras_get_counter_response`**:
```c
	u32 reserved[57];
```
That's 228 bytes of reserved space. This is a protocol struct for a mailbox command — presumably the firmware defines this layout. If so, fine, but it's unusual to see such large reserved fields and it suggests the struct mirrors a fixed-size mailbox buffer rather than the actual response payload.

---
Generated by Claude Code Patch Reviewer