[PATCH v3 2/2] arm64: zynqmp: Add ifm ZynqMP VHIP6 EvalBoard

[Laurent Pinchart]

CC'ing missing ARM64 SoC maintainers.

On Tue, Oct 13, 2026 at 03:47:12PM +0200, Michal Simek wrote:
> On 10/13/26 15:26, Laurent Pinchart wrote:
> > On Tue, Oct 13, 2026 at 10:21:26AM +0200, Michal Simek wrote:
> >> On 9/16/26 22:44, Marek Vasut wrote:
> >>> Add support for ifm ZynqMP VHIP6 EvalBoard reference design.
> >>> The board is populated with four ethernet ports, QSPI NOR,
> >>> eMMC, UART and USB host interfaces.
> >>>
> >>> Signed-off-by: Marek Vasut <marex at nabladev.com>
> >>> ---
> >>> Cc: Conor Dooley <conor+dt at kernel.org>
> >>> Cc: Krzysztof Kozlowski <krzk+dt at kernel.org>
> >>> Cc: Michal Simek <michal.simek at amd.com>
> >>> Cc: Rob Herring <robh at kernel.org>
> >>> Cc: devicetree at vger.kernel.org
> >>> Cc: linux-arm-kernel at lists.infradead.org
> >>> Cc: linux-kernel at vger.kernel.org
> >>> ---
> >>> NOTE: Checkpatch complains about ethernet-phy-id2000.a240 being
> >>>         undocumented, but the TI DP83822I is generic C45 PHY that
> >>>         is valided by Documentation/devicetree/bindings/net/ethernet-phy.yaml
> >>> ---
> >>> V2: - Rename lm75 node to sensor@
> >>>       - Use GPIO_ACTIVE_LOW macro
> >>> V3: - Drop bogus clk_ignore_unused bootargs
> >>>       - Drop gpio line names
> >>> ---
> >>>    arch/arm64/boot/dts/xilinx/Makefile           |   1 +
> >>>    .../dts/xilinx/zynqmp-vhip6-evalboard.dts     | 300 ++++++++++++++++++
> >>>    2 files changed, 301 insertions(+)
> >>>    create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-vhip6-evalboard.dts
> >>
> >> I am not able to review or take this board support further without publicly
> >> available hardware documentation for the platform (board-level and relevant
> >> interface details). Please share public documentation links once available, and
> >> I’ll be happy to revisit the patches.
> > 
> > There are plenty of boards that have no public documentation. Pretty
> > much all phones and laptops are like that. We even have a whole
> > architecture that only runs on a few machines in a single person's
> > basement [*] :-) The kernel has never required public schematics for
> > boards, SoCs or IP cores.
> > 
> > [*] A slight exageration possibly, but that's how I heard arch/alpha/
> >      being described at the maintainers summit.
> 
> Pretty much every SOC with programmable logic or FPGA boards have unlimited 
> amount of configurations and make no sense to describe all of them.

As far as I understand, the dts describes the board only, there's no PL
devices in there. The fact that the SoC has programmable logic doesn't
seem relevant, unless I'm missing something. The situation is the same
as with any other SoC. We have lots of device tree sources in upstream
for all kind of boards, with or without schematics available, for
development boards or for boards integrated in products, for easily
available mass-market products or for specialized devices more costly to
source.

Maybe I'm wrong about all this, so I've CC'ed all ARM64 SoC maintainers
on this e-mail to get feedback on the overall mainline policy for
upstreaming device tree sources.

> It means what make sense to describe are boards which people can look, check and 
> compare that configuration against their custom design.
> But if there is no public documentation what you want to use to compare against?
> 
> Can anybody even buy this board? (I expect you can buy that phones and laptops).

-- 
Regards,

Laurent Pinchart