From mboxrd@z Thu Jan  1 00:00:00 1970
From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: drm/drm_ras: Add DRM RAS netlink error event notification
Date: Thu, 12 Mar 2026 07:06:13 +1000
Message-ID: <review-patch3-20260311102913.3387468-9-riana.tauro@intel.com>
In-Reply-To: <20260311102913.3387468-9-riana.tauro@intel.com>
References: <20260311102913.3387468-6-riana.tauro@intel.com> <20260311102913.3387468-9-riana.tauro@intel.com>
X-Mailer: Claude Code Patch Reviewer
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0

Patch Review

This is the core event notification infrastructure. The implementation follows standard genl multicast patterns.

**`drm_ras_error_notify` looks correct:**

```c
void drm_ras_error_notify(struct drm_ras_node *node, u32 error_id, gfp_t flags)
{
    ...
    genl_info_init_ntf(&info, &drm_ras_nl_family, DRM_RAS_CMD_ERROR_EVENT);
    msg = genlmsg_new(NLMSG_GOODSIZE, flags);
    ...
    genlmsg_multicast(&drm_ras_nl_family, msg, 0, DRM_RAS_NLGRP_ERROR_NOTIFY, flags);
```

The function properly accepts `gfp_t flags` which is important since it will be called from atomic context (patch 4 calls it with `GFP_ATOMIC`). The error handling with `goto err_cancel` / `goto err_free` is correct.

**`DRM_RAS_NLGRP_ERROR_NOTIFY` placement:**

```c
enum {
    DRM_RAS_NLGRP_ERROR_NOTIFY,
};
```

This enum is defined in `drm_ras_nl.h` which is a driver-internal header. That's fine since the multicast group index is kernel-internal; userspace uses the string name `"error-notify"` to subscribe.

**`EXPORT_SYMBOL` vs `EXPORT_SYMBOL_GPL`:**

```c
EXPORT_SYMBOL(drm_ras_error_notify);
```

The existing RAS framework presumably uses one or the other consistently. If the base series uses `EXPORT_SYMBOL_GPL` for other RAS functions, this should match.

**No validation of `node` or `error_id`:**

The function doesn't validate that `node` is non-NULL or that `error_id` is within range. Since this is a DRM-internal API called only by drivers, this is likely acceptable, but a brief note or `WARN_ON(!node)` might help catch driver bugs.

---
Generated by Claude Code Patch Reviewer