Claude review: drm/xe/drm_ras: Wire up error threshold callbacks

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

Patch Review

This wires the threshold callbacks into the correctable error node only.

**Issues:**

1. **Threshold only wired for correctable, not uncorrectable**: This is the biggest issue with this patch. The `assign_node_params` function handles both correctable and uncorrectable severity:
```c
	if (severity == DRM_XE_RAS_ERR_SEV_CORRECTABLE) {
		node->query_error_counter = query_correctable_error_counter;
		node->clear_error_counter = clear_correctable_error_counter;
+		node->query_error_threshold = query_correctable_error_threshold;
+		node->set_error_threshold = set_correctable_error_threshold;
	} else {
		node->query_error_counter = query_uncorrectable_error_counter;
		node->clear_error_counter = clear_uncorrectable_error_counter;
	}
```
No `query_uncorrectable_error_threshold` or `set_uncorrectable_error_threshold` is added for the else branch. The core drm_ras code (patch 1) already returns `-EOPNOTSUPP` when the callbacks are NULL, so this won't crash — but the commit message doesn't explain why threshold is only meaningful for correctable errors. If this is intentional (e.g., hardware only supports threshold for correctable errors), it should be stated in the commit message.

2. **Redundant validation**: The `query_correctable_error_threshold` callback does its own validation:
```c
	if (!info || !info[error_id].name)
		return -ENOENT;

	if (!xe->info.has_sysctrl)
		return -EOPNOTSUPP;
```
But the core `get_node_error_threshold()` in patch 1 already validates:
- The node exists (xa_load)
- The callback exists (returns `-EOPNOTSUPP` if NULL)
- The error_id is in range

The `!info || !info[error_id].name` check is still useful as driver-level validation (the counter may not be defined for that ID even if it's in range). The `has_sysctrl` check is also correct since threshold requires the mailbox. This is fine, just noting the defense-in-depth.

3. **The callback functions access `ras->info[severity]` directly**: This re-fetches the counter info array that was set up in `assign_node_params`. There's no lock protecting this access. If `cleanup_node_param` could race with a netlink request (e.g., during driver unload while a user is querying), this could be a use-after-free. This is an existing issue with the counter callbacks too, not introduced by this patch.

---
Generated by Claude Code Patch Reviewer