Claude review: drm/bridge: analogix_dp: Add validation for samsung, lane-count property

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

Patch Review

**Status: Concern — potential regression for existing DTs without samsung,lane-count**

The patch changes the `EXYNOS_DP` case from silently tolerating a missing `samsung,lane-count` to hard-failing with `dev_err_probe`:

```c
ret = of_property_read_u32(dp_node, "samsung,lane-count",
			   &video_info->max_lane_count);
if (ret || !drm_dp_lane_count_is_valid(video_info->max_lane_count))
	return dev_err_probe(dp->dev, ret ? ret : -EINVAL,
			     "failed to parse samsung,lane-count\n");
```

**Issue: `max_lane_count` is zero-initialized** (via `devm_drm_bridge_alloc` which zeroes the struct). Previously, if `samsung,lane-count` was missing, `max_lane_count` stayed 0 and the driver would continue (perhaps not ideally, but it wouldn't fail probe). Now it's a hard probe failure. While I confirmed all in-tree Exynos DTs have `samsung,lane-count`, there could be out-of-tree DTs that relied on the old permissive behavior. This is a kernel regression risk.

Additionally, `samsung,link-rate` is NOT validated in the same way — it's still silently read with no error check. This asymmetry is a bit inconsistent. If `samsung,lane-count` is truly mandatory, perhaps both should be validated; if the intent is defensive validation, perhaps a `dev_warn` + fallback to a sane default (like 4 lanes) would be safer than a hard failure.

Consider either:
1. Making this a warning with fallback rather than a hard probe error, or
2. Also validating `samsung,link-rate` for consistency.

---
Generated by Claude Code Patch Reviewer