Claude review: drm/bridge: analogix_dp: Add support for optional data-lanes mapping

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

Patch Review

**Status: Mostly good, a few observations**

The overall implementation is correct. The parsing logic properly validates lane values and checks for duplicates. The fill-in logic for unused lanes when fewer than 4 data-lanes are specified is reasonable:

```c
for (i = 0; i < LANE_COUNT4 && num_lanes < LANE_COUNT4; i++) {
	if (!used[i])
		map[num_lanes++] = i;
}
```

The `analogix_dp_lane_mapping()` register write using shift constants is cleaner than the old hardcoded approach.

**Observations:**

1. **Double endpoint lookup**: `analogix_dp_dt_parse_lanes_map()` first calls `drm_of_get_data_lanes_count_ep()` to get the count, then calls `of_graph_get_endpoint_by_regs()` + `of_property_read_u32_array()` to read the values. `drm_of_get_data_lanes_count_ep` already looks up the endpoint internally and reads `data-lanes`. Consider whether it's possible to just do a single endpoint lookup and read `data-lanes` directly, getting both count and values in one pass. This would also avoid the subtle inconsistency that `drm_of_get_data_lanes_count_ep` uses port_reg=1,reg=0 while `of_graph_get_endpoint_by_regs` uses port=1,reg=-1 (first endpoint).

2. **Error return on missing data-lanes**: `drm_of_get_data_lanes_count_ep` returns a negative error when no `data-lanes` property exists. The function returns `-EINVAL` in this case, which is then silently caught by the caller:
   ```c
   if (analogix_dp_dt_parse_lanes_map(dp))
       dev_dbg(dp->dev, "No valid data-lanes found, using default lane map\n");
   ```
   The initial `memcpy(video_info->lane_map, map, sizeof(map))` at the top of the function ensures the default `{0, 1, 2, 3}` is always set, which is correct.

3. **Parentheses in shift defines**: Minor style nit — the new defines use unnecessary parentheses around the values:
   ```c
   #define LANE3_MAP_SHIFT				(6)
   #define LANE2_MAP_SHIFT				(4)
   ```
   While not wrong, this is inconsistent with many other shift defines in the same file that don't use parentheses (e.g., the existing `LANE*_MAP_LOGIC_LANE_*` defines use `(0x1 << 6)` syntax where the parens wrap the expression, not bare integers). Very minor.

4. **`LANE_COUNT4` as array size**: Using the enum value `LANE_COUNT4 = 4` as an array dimension and loop bound works since its value is 4, but it mixes enum semantics (a lane-count option) with "number of DP lanes total." A named constant like `DP_MAX_LANES` or `ANALOGIX_DP_MAX_LANES` would be self-documenting, though this is a pre-existing pattern in the codebase.

The register-level change from `analogix_dp_lane_swap()` to `analogix_dp_lane_mapping()` is clean — the old hardcoded swap/no-swap is replaced by a generic mapping write that produces the same result for the default `{0,1,2,3}` map.

---
Generated by Claude Code Patch Reviewer