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

["Arnd Bergmann" <arnd@arndb.de>]

On Tue, Oct 13, 2026, at 19:54, Laurent Pinchart wrote:
> 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.

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.

       Arnd