Re: [PATCH v3 2/2] arm64: zynqmp: Add ifm ZynqMP VHIP6 EvalBoard
From: Marek Vasut
Date: Tue Nov 03 2026 - 08:29:02 EST
On 10/22/26 3:19 PM, Arnd Bergmann wrote:
On Tue, Oct 13, 2026, at 19:54, Laurent Pinchart wrote:Thank you for the clarification.
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.
In general, we definitely want this type of board to have an upstream dts
files, and there is no requirement for public documentation as in
many cases the dts source is the only documentation that is
available.
As platform maintainer, Michal should review the dts file to see if it
follows the general coding style and maintainability standards. If any
of the data in the dts turns out to be wrong in a way that one cannot
tell without access to hardware or documentation, that is Marek's problem
and he gets to fix it.
Michal, is there anything left over to do with these patches ?