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

[Marek Vasut]

On 10/13/26 7:54 PM, Laurent Pinchart wrote:
> CC'ing missing ARM64 SoC maintainers.

Has there been any input from the maintainers ?

Thank you for your help !

> 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@xxxxxxxxxxxx>
> > > > > ---
> > > > > Cc: Conor Dooley <conor+dt@xxxxxxxxxx>
> > > > > Cc: Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx>
> > > > > Cc: Michal Simek <michal.simek@xxxxxxx>
> > > > > Cc: Rob Herring <robh@xxxxxxxxxx>
> > > > > Cc: devicetree@xxxxxxxxxxxxxxx
> > > > > Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
> > > > > Cc: linux-kernel@xxxxxxxxxxxxxxx
> > > > > ---
> > > > > 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).


--
Best regards,
Marek Vasut