[PATCH v3 1/2] dt-bindings: soc: xilinx: Document ifm ZynqMP VHIP6 EvalBoard

[PATCH v3 1/2] dt-bindings: soc: xilinx: Document ifm ZynqMP VHIP6 EvalBoard

[Marek Vasut]

Document ifm ZynqMP VHIP6 EvalBoard reference design binding.
The board is populated with four ethernet ports, QSPI NOR,
eMMC, UART and USB host interfaces.

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Marek Vasut <marex@nabladev.com>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Michal Simek <michal.simek@amd.com>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
V2: No change
V3: Add AB from Krzysztof
---
 Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml b/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml
index c9f99e0df2b35..49ef4e0c68501 100644
--- a/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml
+++ b/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml
@@ -44,6 +44,11 @@ properties:
           - const: xlnx,zynq-zed
           - const: xlnx,zynq-7000
 
+      - items:
+          - const: ifm,zynqmp-vhip6-evalboard
+          - const: ifm,zynqmp-vhip6
+          - const: xlnx,zynqmp
+
       - items:
           - enum:
               - xlnx,zynqmp-zc1751
-- 
2.53.0

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

[Marek Vasut]

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@nabladev.com>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Michal Simek <michal.simek@amd.com>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@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

diff --git a/arch/arm64/boot/dts/xilinx/Makefile b/arch/arm64/boot/dts/xilinx/Makefile
index 70fac0b276df0..936ddf6eb80a6 100644
--- a/arch/arm64/boot/dts/xilinx/Makefile
+++ b/arch/arm64/boot/dts/xilinx/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 dtb-$(CONFIG_ARCH_ZYNQMP) += avnet-ultra96-rev1.dtb
+dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-vhip6-evalboard.dtb
 dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zc1232-revA.dtb
 dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zc1254-revA.dtb
 dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zc1751-xm015-dc1.dtb
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-vhip6-evalboard.dts b/arch/arm64/boot/dts/xilinx/zynqmp-vhip6-evalboard.dts
new file mode 100644
index 0000000000000..ed2c6d170426d
--- /dev/null
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-vhip6-evalboard.dts
@@ -0,0 +1,300 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * ifm Zynq UltraScale+ MPSoC VHIP6 Evaluation Board
+ *
+ * Copyright (C) 2022-2026 Fedor Ross, ifm ecomatic gmbh
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/phy/phy.h>
+
+#include "zynqmp.dtsi"
+#include "zynqmp-clk-ccf.dtsi"
+
+/ {
+	model = "ifm ZynqMP VHIP6 Evaluation Board";
+	compatible = "ifm,zynqmp-vhip6-evalboard", "ifm,zynqmp-vhip6", "xlnx,zynqmp";
+
+	aliases {
+		ethernet0 = &gem0;
+		ethernet1 = &gem1;
+		ethernet2 = &gem2;
+		ethernet3 = &gem3;
+		gpio0 = &gpio;
+		i2c0 = &i2c0;
+		i2c1 = &i2c1;
+		rtc0 = &i2crtc;
+		serial0 = &uart0;
+		spi0 = &qspi;
+		usb0 = &usb0;
+		usb1 = &usb1;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	memory@0 {
+		device_type = "memory";
+		reg = <0x0 0x0 0x0 0x40000000>;
+	};
+};
+
+&dwc3_1 {
+	dr_mode = "host";
+	maximum-speed = "high-speed";
+	status = "okay";
+};
+
+&gem0 {
+	phy-handle = <&phy0>;
+	phy-mode = "mii";
+	status = "okay";
+
+	mdio0: mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		phy0: phy@1 {	/* TI DP83822I */
+			compatible = "ethernet-phy-id2000.a240",
+				     "ethernet-phy-ieee802.3-c45";
+			reg = <1>;
+			reset-gpios = <&gpio 78 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <10>;
+			reset-deassert-us = <10>;
+		};
+	};
+};
+
+&gem1 {
+	phy-handle = <&phy1>;
+	phy-mode = "rgmii-rxid";
+	status = "okay";
+
+	mdio1: mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		phy1: phy@1 {	/* TI DP83822I */
+			compatible = "ethernet-phy-id2000.a240",
+				     "ethernet-phy-ieee802.3-c45";
+			reg = <1>;
+			max-speed = <100>;
+			reset-gpios = <&gpio 8 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <10>;
+			reset-deassert-us = <10>;
+			tx-internal-delay-ps = <1>;
+		};
+	};
+};
+
+&gem2 {
+	phy-handle = <&phy2>;
+	phy-mode = "mii";
+	status = "okay";
+
+	mdio2: mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		phy2: phy@1 {	/* TI DP83822I */
+			compatible = "ethernet-phy-id2000.a240",
+				     "ethernet-phy-ieee802.3-c45";
+			reg = <1>;
+			reset-gpios = <&gpio 79 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <10>;
+			reset-deassert-us = <10>;
+		};
+	};
+};
+
+&gem3 {
+	phy-handle = <&phy3>;
+	phy-mode = "mii";
+	status = "okay";
+
+	mdio3: mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		phy3: phy@1 {	/* TI DP83822I */
+			compatible = "ethernet-phy-id2000.a240",
+				     "ethernet-phy-ieee802.3-c45";
+			reg = <1>;
+			reset-gpios = <&gpio 80 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <10>;
+			reset-deassert-us = <10>;
+		};
+	};
+};
+
+&i2c0 {
+	clock-frequency = <400000>;
+	status = "okay";
+
+	sensor@48 {
+		compatible = "national,lm75";
+		reg = <0x48>;
+	};
+
+	eeprom@50 {
+		compatible = "atmel,24c128";
+		reg = <0x50>;
+		label = "ifm-logging";
+		wp-gpios = <&gpio 36 GPIO_ACTIVE_HIGH>;
+	};
+};
+
+&i2c1 {
+	clock-frequency = <400000>;
+	status = "okay";
+
+	eeprom@51 {
+		compatible = "atmel,24c128";
+		reg = <0x51>;
+		label = "ifm-deviceinfo";
+		wp-gpios = <&gpio 37 GPIO_ACTIVE_HIGH>;
+
+		nvmem-layout {
+			compatible = "fixed-layout";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			vhip-signature@0 {
+				reg = <0x0 0x4>;
+			};
+
+			vhip-version@4 {
+				reg = <0x4 0x4>;
+			};
+
+			vhip-size@8 {
+				reg = <0x8 0x4>;
+			};
+
+			device-serial@c {
+				reg = <0xc 0x10>;
+			};
+
+			order-number@1c {
+				reg = <0x1c 0x20>;
+			};
+
+			article-name@3c {
+				reg = <0x3c 0x20>;
+			};
+
+			article-rev@5c {
+				reg = <0x5c 0x4>;
+			};
+
+			hardware-rev@60 {
+				reg = <0x60 0x4>;
+			};
+
+			product-type@64 {
+				reg = <0x64 0x20>;
+			};
+
+			software-compatibility@84 {
+				reg = <0x84 0x4>;
+			};
+
+			manufacturing-date@88 {
+				reg = <0x88 0x20>;
+			};
+
+			production-order-number@a8 {
+				reg = <0xa8 0x20>;
+			};
+
+			/* Each MAC address is padded to 8 Bytes */
+			cfg_eeprom_mac1: mac-address-1@c8 {
+				reg = <0xc8 0x8>;
+			};
+
+			cfg_eeprom_mac2: mac-address-2@d0 {
+				reg = <0xd0 0x8>;
+			};
+
+			cfg_eeprom_mac3: mac-address-3@d8 {
+				reg = <0xd8 0x8>;
+			};
+
+			cfg_eeprom_mac4: mac-address-4@e0 {
+				reg = <0xe0 0x8>;
+			};
+
+			cfg_eeprom_mac5: mac-address-5@e8 {
+				reg = <0xe8 0x8>;
+			};
+
+			cfg_eeprom_mac6: mac-address-6@f0 {
+				reg = <0xf0 0x8>;
+			};
+
+			cfg_eeprom_mac7: mac-address-7@f8 {
+				reg = <0xf8 0x8>;
+			};
+
+			cfg_eeprom_mac8: mac-address-8@100 {
+				reg = <0x100 0x8>;
+			};
+
+			next-block-offset@108 {
+				reg = <0x108 0x4>;
+			};
+
+			section-crc@10c {
+				reg = <0x10c 0x4>;
+			};
+		};
+	};
+
+	i2crtc: rtc@52 {
+		compatible = "microcrystal,rv3028";
+		reg = <0x52>;
+	};
+};
+
+&qspi {
+	status = "okay";
+
+	flash@0 {
+		compatible = "jedec,spi-nor";
+		reg = <0x0>;
+		spi-max-frequency = <80000000>;
+		spi-tx-bus-width = <1>;
+		spi-rx-bus-width = <4>;
+	};
+};
+
+&sdhci0 {
+	xlnx,mio-bank = <0x0>;
+	status = "okay";
+};
+
+&spi0 {
+	status = "okay";
+
+	eeprom@0 {
+		compatible = "atmel,at25";
+		reg = <0x0>;
+		address-width = <16>;
+		pagesize = <64>;
+		size = <32768>;
+		spi-max-frequency = <60000000>;
+	};
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&usb1 {
+	reset-gpios = <&gpio 77 GPIO_ACTIVE_LOW>;
+	status = "okay";
+};
-- 
2.53.0

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
- [High] net: dt-bindings: Incorrect Clause 45 compatible string forces incompatible MDIO probe on C22 PHY
- [High] net: dt-bindings: Insufficient reset deassert delay for DP83822I PHY
- [Medium] net: dt-bindings: Contradictory RGMII internal delay configuration on gem1
- [Medium] mmc: dt-bindings: eMMC node lacks 'non-removable' and 'bus-width' properties
- [Medium] nvmem: dt-bindings: 8-byte NVMEM MAC address cells will be rejected by the kernel
- [Low] dt-bindings: Dangling alias to disabled usb0 node
--

commit 2e2a25c7bccf2c438229b39299b352c4fb573831
Author: Marek Vasut <marex@nabladev.com>

arm64: zynqmp: Add ifm ZynqMP VHIP6 EvalBoard

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.

> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-vhip6-evalboard.dts b/arch/arm64/boot/dts/xilinx/zynqmp-vhip6-evalboard.dts
> new file mode 100644
> index 0000000000000..ed2c6d170426d
> --- /dev/null
> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-vhip6-evalboard.dts

[ ... ]

> +	aliases {
> +		ethernet0 = &gem0;
> +		ethernet1 = &gem1;
> +		ethernet2 = &gem2;
> +		ethernet3 = &gem3;
> +		gpio0 = &gpio;
> +		i2c0 = &i2c0;
> +		i2c1 = &i2c1;
> +		rtc0 = &i2crtc;
> +		serial0 = &uart0;
> +		spi0 = &qspi;
> +		usb0 = &usb0;
> +		usb1 = &usb1;

[Severity: Low]
Does this map usb0 to a disabled node? In the base zynqmp.dtsi, usb0 defaults
to disabled and it is never enabled here, which might cause confusion for
bootloaders or userspace indexing.

> +	};

[ ... ]

> +&gem0 {
> +	phy-handle = <&phy0>;
> +	phy-mode = "mii";
> +	status = "okay";
> +
> +	mdio0: mdio {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		phy0: phy@1 {	/* TI DP83822I */
> +			compatible = "ethernet-phy-id2000.a240",
> +				     "ethernet-phy-ieee802.3-c45";

[Severity: High]
Does declaring "ethernet-phy-ieee802.3-c45" force an incompatible MDIO probe
on this C22 PHY? The fwnode_mdiobus_register_phy() function sets is_c45 = true
when it sees this compatible string. This forces the Cadence MACB MDIO
controller to send Clause 45 MDIO frames (Start Code 00). 

Since the TI DP83822I is a Clause 22 PHY (expecting Start Code 01), will it
ignore the frames and cause get_phy_device() to fail with -ENODEV?

This same compatible string is used for phy1, phy2, and phy3 below.

> +			reg = <1>;
> +			reset-gpios = <&gpio 78 GPIO_ACTIVE_LOW>;
> +			reset-assert-us = <10>;
> +			reset-deassert-us = <10>;

[Severity: High]
Is a 10 us deassert delay sufficient for the DP83822I PHY? Section 8.4.1.2 of
the TI DP83822I datasheet strictly requires a minimum of 150 us before MDIO
access. Accessing the PHY before its internal state machine has initialized
could cause the MDIO probe to fail or read garbage.

This same deassert delay is also used for phy1, phy2, and phy3 below.

> +		};
> +	};
> +};
> +
> +&gem1 {
> +	phy-handle = <&phy1>;
> +	phy-mode = "rgmii-rxid";
> +	status = "okay";
> +
> +	mdio1: mdio {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		phy1: phy@1 {	/* TI DP83822I */
> +			compatible = "ethernet-phy-id2000.a240",
> +				     "ethernet-phy-ieee802.3-c45";
> +			reg = <1>;
> +			max-speed = <100>;
> +			reset-gpios = <&gpio 8 GPIO_ACTIVE_LOW>;
> +			reset-assert-us = <10>;
> +			reset-deassert-us = <10>;
> +			tx-internal-delay-ps = <1>;

[Severity: Medium]
Does specifying tx-internal-delay-ps = <1> contradict the "rgmii-rxid"
phy-mode requested by gem1?

The dp83822 driver's DP83822_TX_CLK_SHIFT logic disables the TX delay only if
tx_int_delay <= 0. Because 1 > 0, the TX delay appears to be erroneously
enabled here, violating the RGMII-RXID contract and potentially causing packet
loss or link instability.

> +		};
> +	};
> +};

[ ... ]

> +&i2c1 {
> +	clock-frequency = <400000>;
> +	status = "okay";
> +
> +	eeprom@51 {
> +		compatible = "atmel,24c128";
> +		reg = <0x51>;
> +		label = "ifm-deviceinfo";
> +		wp-gpios = <&gpio 37 GPIO_ACTIVE_HIGH>;
> +
> +		nvmem-layout {
> +			compatible = "fixed-layout";
> +			#address-cells = <1>;
> +			#size-cells = <1>;

[ ... ]

> +			/* Each MAC address is padded to 8 Bytes */
> +			cfg_eeprom_mac1: mac-address-1@c8 {
> +				reg = <0xc8 0x8>;

[Severity: Medium]
Will this 8-byte NVMEM cell be rejected by the kernel? nvmem_get_mac_address()
in net/ethernet/eth.c strictly verifies that the read cell length is exactly
ETH_ALEN (6). Because the reg length is defined as 8 bytes, the
if (len != ETH_ALEN) check will fail and return -EINVAL, causing the
programmed MAC addresses to be ignored.

This also applies to mac-address-2 through mac-address-8 below.

> +			};

[ ... ]

> +&qspi {
> +	status = "okay";
> +
> +	flash@0 {
> +		compatible = "jedec,spi-nor";
> +		reg = <0x0>;
> +		spi-max-frequency = <80000000>;
> +		spi-tx-bus-width = <1>;
> +		spi-rx-bus-width = <4>;
> +	};
> +};
> +
> +&sdhci0 {
> +	xlnx,mio-bank = <0x0>;
> +	status = "okay";
> +};

[Severity: Medium]
Since this is an eMMC controller, is it missing the mandatory 'non-removable'
and 'bus-width = <8>' properties?

Without these, the sdhci driver will initialize the device using default
properties meant for hot-pluggable SD cards, which might cause the eMMC to
fail probing, operate at degraded speeds, or erroneously poll for a card
detect signal.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260916204509.166633-1-marex@nabladev.com?part=2

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

[Michal Simek]

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@nabladev.com>
> ---
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Michal Simek <michal.simek@amd.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@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.

Thanks,
Michal

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

[Laurent Pinchart]

Hi Michal,

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@nabladev.com>
> > ---
> > Cc: Conor Dooley <conor+dt@kernel.org>
> > Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> > Cc: Michal Simek <michal.simek@amd.com>
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: devicetree@vger.kernel.org
> > Cc: linux-arm-kernel@lists.infradead.org
> > Cc: linux-kernel@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.

-- 
Regards,

Laurent Pinchart

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

[Michal Simek]

On 10/13/26 15:26, Laurent Pinchart wrote:
> Hi Michal,
> 
> 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@nabladev.com>
>>> ---
>>> Cc: Conor Dooley <conor+dt@kernel.org>
>>> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
>>> Cc: Michal Simek <michal.simek@amd.com>
>>> Cc: Rob Herring <robh@kernel.org>
>>> Cc: devicetree@vger.kernel.org
>>> Cc: linux-arm-kernel@lists.infradead.org
>>> Cc: linux-kernel@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.
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).

Thanks,
Michal

Re: [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@nabladev.com>
> >>> ---
> >>> Cc: Conor Dooley <conor+dt@kernel.org>
> >>> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> >>> Cc: Michal Simek <michal.simek@amd.com>
> >>> Cc: Rob Herring <robh@kernel.org>
> >>> Cc: devicetree@vger.kernel.org
> >>> Cc: linux-arm-kernel@lists.infradead.org
> >>> Cc: linux-kernel@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