Claude review: drm: Send per-connector hotplug events

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

Patch Review

This patch converts both the polling and HPD paths to send per-connector hotplug events instead of global ones.

**Bug: `delayed_event` path drops hotplug notifications**

> -	if (changed)
> -		drm_kms_helper_hotplug_event(dev);
> +	if (changed) {
> +		drm_connector_list_iter_begin(dev, &conn_iter);
> +		drm_for_each_connector_iter(connector, &conn_iter) {
> +			if (connector->pending_hp)
> +				drm_kms_helper_connector_hotplug_event(connector);
> +		}
> +		drm_connector_list_iter_end(&conn_iter);
> +	}

In `output_poll_execute`, `changed` can become true via two paths: (1) the connector iteration loop detects an epoch counter change and sets both `changed = true` and `connector->pending_hp = true`, or (2) `delayed_event` was already set at the top of the function:

```c
changed = dev->mode_config.delayed_event;
dev->mode_config.delayed_event = false;
```

The `delayed_event` path is triggered from `drm_helper_probe_single_connector_modes` when userspace probes a connector and finds its status changed. In this case, `changed` is true but no connector has `pending_hp` set, so the new loop will iterate all connectors, find none with `pending_hp`, and send no hotplug event at all. The old code called `drm_kms_helper_hotplug_event(dev)` which would have sent a global uevent.

This is a regression: connector status changes detected through userspace-initiated probing will no longer generate hotplug events.

One possible fix: set `pending_hp = true` on the connector in `drm_helper_probe_single_connector_modes` where `delayed_event` is set. Alternatively, fall back to the global `drm_kms_helper_hotplug_event(dev)` when `changed` is true but the connector loop sends zero events.

**Performance: `drm_client_dev_hotplug` called per-connector**

Each call to `drm_kms_helper_connector_hotplug_event` calls `drm_client_dev_hotplug(dev)`, which iterates all DRM clients and invokes their hotplug callback. When multiple connectors change simultaneously, this means the client hotplug callbacks (e.g., fbdev emulation) run N times instead of once. For the common case of a dock with multiple outputs, this is redundant work. It is not a correctness bug, but it may be worth noting.

**HPD path: the `changed == 1` fast path**

> -	if (changed == 1)
> +	if (changed == 1) {
>  		drm_kms_helper_connector_hotplug_event(first_changed_connector);
> -	else if (changed > 0)
> -		drm_kms_helper_hotplug_event(dev);
> +	} else if (changed > 0) {
> +		drm_connector_list_iter_begin(dev, &conn_iter);
> +		drm_for_each_connector_iter(connector, &conn_iter) {
> +			if (connector->pending_hp)
> +				drm_kms_helper_connector_hotplug_event(connector);
> +		}
> +		drm_connector_list_iter_end(&conn_iter);
> +	}

The HPD path in `drm_helper_hpd_irq_event` looks correct. When `changed == 1`, it uses `first_changed_connector` directly (which also has `pending_hp` set, so `drm_kms_helper_connector_hotplug_event` will clear it). When `changed > 1`, it iterates and sends individual events. The `pending_hp` flag was set under `mode_config.mutex` and read here after the mutex was dropped -- this is fine because this is single-threaded within this function and the writes are already committed.

**Reading `pending_hp` without the mutex**

In both the polling and HPD paths, `connector->pending_hp` is read without holding `mode_config.mutex`. The write happened under the mutex and the read happens on the same thread after the mutex was dropped, so the value will be visible. Concurrent writers (e.g., `status_store` on another CPU) could theoretically set `pending_hp` on a connector between the mutex drop and the iteration, but this is benign -- it just means an extra connector event may fire, which is harmless.

No other issues found in this patch beyond the `delayed_event` bug described above.

---
Generated by Claude Code Patch Reviewer