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

[Marek Vasut]

On 10/22/26 3:19 PM, Arnd Bergmann wrote:
> 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 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.
> 
> 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.
Thank you for the clarification.

Michal, is there anything left over to do with these patches ?