[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 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.
> 
>> 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