Claude review: drm/xlnx/zynqmp-dpsub: Fix dependencies for COMPILE_TEST

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

Patch Review

**Correctness: Good**

I verified the actual build-time dependencies in the driver source:

1. `zynqmp_dp.c` includes `<linux/phy/phy.h>` and calls `devm_phy_get()`, `phy_init()`, `phy_power_on()`, `phy_configure()`, `phy_exit()`. These are all generic PHY framework functions that are available when `GENERIC_PHY` is set — and the Kconfig already has `select GENERIC_PHY`. There is no direct include of or dependency on any `PHY_XILINX_ZYNQMP`-specific header.

2. `zynqmp_disp.c` includes `<linux/dma/xilinx_dpdma.h>` — but this header is just a trivial struct definition (`struct xilinx_dpdma_peripheral_config`) with no conditional compilation or dependency on `XILINX_ZYNQMP_DPDMA`. The actual DMA calls (`dma_request_chan()`, `dmaengine_prep_interleaved_dma()`, etc.) come from `<linux/dmaengine.h>`, which is provided by `DMA_ENGINE` (already selected).

So both `PHY_XILINX_ZYNQMP` and `XILINX_ZYNQMP_DPDMA` are indeed runtime-only dependencies — they ensure the specific hardware drivers are present so that `devm_phy_get()` and `dma_request_chan()` find their providers at probe time. They are not needed for compilation.

**The Kconfig logic:**

```kconfig
-	depends on ARCH_ZYNQMP || COMPILE_TEST
+	depends on (ARCH_ZYNQMP && PHY_XILINX_ZYNQMP && XILINX_ZYNQMP_DPDMA) || COMPILE_TEST
```

This correctly:
- Preserves the full dependency chain for real `ARCH_ZYNQMP` builds (PHY + DMA drivers must be enabled)
- Relaxes only for `COMPILE_TEST`, where those specific drivers aren't needed to compile

**Minor observation:** The author notes in the cover message that the two driver dependencies "could be removed altogether" (i.e., not required even for `ARCH_ZYNQMP` builds). This is technically true — the driver would just fail at probe with `-ENODEV`/`-EPROBE_DEFER` — but keeping them as hard dependencies for real hardware builds is a reasonable user-experience choice, preventing users from building a kernel that would silently fail to bring up the display. The current conservative approach is the right call.

**No issues found.** 

Reviewed-by worthy.

---
Generated by Claude Code Patch Reviewer