Claude review: drm/i915/dp: Clear accumulated HPD events after link training

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

Patch Review

**Correctness:**

The block/unblock pairing is correct:
- `intel_dp_start_link_train()` calls `intel_hpd_block(encoder)` at line 1655
- `intel_dp_stop_link_train()` calls the unblock at line 1155

The change from `intel_hpd_unblock()` (which calls `queue_work_for_missed_irqs()` to replay accumulated events) to `intel_hpd_clear_and_unblock()` (which clears `event_bits`, `retry_bits`, `short_hpd_pin_mask`, and `long_hpd_pin_mask`) is the right approach. The cleared events genuinely are stale — they were generated during link training and reflect pre-retrain link status.

**Safety net:**

The commit message correctly identifies that the safety net exists at lines 1157-1162:

```c
if (!display->hotplug.ignore_long_hpd &&
    intel_dp->link.seq_train_failures < MAX_SEQ_TRAIN_FAILURES) {
    int delay_ms = intel_dp->link.seq_train_failures ? 0 : 2000;
    intel_encoder_link_check_queue_work(encoder, delay_ms);
}
```

This queues a link check after 2 seconds (on first success), which will catch any legitimate link degradation post-retrain. Any *new* HPD events arriving after the unblock are processed normally through the standard path.

**Minor observation:**

The commit message could benefit from a `Fixes:` or `Cc: stable@` tag if this is intended for backporting, given that it fixes a GPU hard lockup. The commit that introduced `intel_hpd_block()`/`intel_hpd_unblock()` in the link training path would be the appropriate `Fixes:` target. This doesn't affect the code quality, but would help with stable kernel backporting.

**Overall:** Clean, minimal, correct fix. The commit message is well-written and explains both the problem (stale HPD burst racing with modeset) and why the fix is safe (events are stale + link check safety net).

---
Generated by Claude Code Patch Reviewer