Claude review: drm/bridge: it6505: disable HDCP retry when KSV list timeout

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

Patch Review

**Change 1 — `it6505_hdcp_wait_ksv_list` timeout path (line 2241):**

```c
timeout:
	it6505_stop_hdcp(it6505);
```

This is correct. When the KSV list wait times out after 5 seconds, retrying authentication would just repeat the same timeout. Stopping HDCP is the right thing to do. Note that this `timeout` label is also reached when `it6505_hdcp_part2_ksvlist_check()` fails (line 2237-2238), so the KSV list check failure case also now stops instead of retrying — this is also reasonable behavior.

**Change 2 — `it6505_irq_hdcp_fail` (line 2599):**

```c
	it6505->hdcp_status = HDCP_AUTH_IDLE;
	it6505_show_hdcp_info(it6505);
	it6505_stop_hdcp(it6505);
```

This one is more nuanced. The HDCP fail interrupt can fire for various reasons, not just KSV list timeout on problematic converters. Unconditionally stopping HDCP on *any* failure means:

- **Transient failures** (e.g., noise on the link during authentication) will now permanently disable HDCP for the session rather than retrying. The HDCP spec generally expects implementations to be able to retry authentication.
- **Content protection policy**: If userspace has requested HDCP via the `Content Protection` DRM property, failing permanently without re-attempting may violate the expected behavior. Userspace would need to explicitly toggle the property to trigger a new attempt.

**Suggestion**: Consider whether `it6505_irq_hdcp_fail` should use a limited retry count (e.g., retry 2-3 times before giving up) rather than stopping on the first failure. The KSV list timeout path change is clearly correct, but the general HDCP failure path could benefit from a bounded retry strategy. At minimum, the commit message should acknowledge that this also changes behavior for non-KSV-timeout HDCP failures.

**Minor note**: `it6505_stop_hdcp()` calls `cancel_delayed_work(&it6505->hdcp_work)` — calling this from `it6505_irq_hdcp_fail` (which runs in an IRQ/work context) should be fine since `cancel_delayed_work` is safe to call from any context, but it's worth noting that if the hdcp_work is currently running, it won't wait for it to finish (unlike `cancel_delayed_work_sync`). This matches the existing pattern in the driver, so it's not a new concern.

---
Generated by Claude Code Patch Reviewer