Subject: Re: [PATCH 0/2] arm64: dts: a7k: add COM Express boards

From: Gregory CLEMENT <[email-masked]>
Date: Fri, 23 Jan 2026 10:10:55 +0100

Hello,

> On Thu, 22 Jan 2026 18:59:20 +0200, Elad Nachman wrote:
>> From: Elad Nachman <[email-masked]>
>> 
>> Add support for Armada 7020 Express Type 7 CPU module board by Marvell.
>> Add device tree bindings for this board.
>> Define this COM Express CPU module as dtsi and provide a dtsi file for
>> the carrier board (Marvell DB-98CX85x0 COM Express type 7 carrier board).
>> Add the Falcon DB to the MAINTAINERS list
>> 
>> Since memory is soldered on CPU module, memory node is on CPU module
>> dtsi file.
>> 
>> This Carrier board only utilizes the PCIe link, hence no special device
>> or driver support is provided by this dtsi file.
>> Devise a dts file for the combined com express carrier and CPU module.
>> 
>> The Aramda 7020 CPU COM Express board offers the following features:
>> 
>> 1.  Armada 7020 CPU, with dual ARM A72 cores
>> 2.  DDR4 memory, 8GB, on board soldered
>> 3.  1Gbit Out of Band Ethernet via RGMII to PHY and RJ45 connector,
>>     all are present on A7K CPU module (none on the carrier)
>> 4.  Optional 10G KR Ethernet going via the COM Express type 7 connector
>> 5.  On-board 8 Gbit, 8-bit bus width NAND flash
>> 6.  On-board 512 Mbit SPI flash
>> 7.  PCIe Root Complex, 4 lanes PCIe gen3 connectivity, going via the
>>     COM Express type 7 connector
>> 8.  m.2 SATA connector
>> 9.  Micro-SD card connector
>> 10. USB 2.0 via COM Express type 7 connector
>> 11. Two i2c interfaces - one to the CPU module, and one to the
>>     carrier board via the COM Express type 7 connector
>> 12. UART (mini USB connector by virtue of FT2232D UART to USB
>>     converter, connected to the Armada 7020 UART0)
>> 
>> Elad Nachman (3):
>>   dt-bindings: arm64: add Marvell 7k COMe boards
>>   arm64: dts: a7k: add COM Express boards
>>   MAINTAINERS: Add Falcon DB
>> 
>>  .../bindings/arm/marvell/armada-7k-8k.yaml    |  11 ++
>>  MAINTAINERS                                   |   1 +
>>  arch/arm64/boot/dts/marvell/Makefile          |   1 +
>>  .../dts/marvell/armada-7020-comexpress.dtsi   | 161 ++++++++++++++++++
>>  arch/arm64/boot/dts/marvell/armada-70x0.dtsi  |   7 +
>>  .../boot/dts/marvell/armada-ap806-dual.dtsi   |   4 +-
>>  .../dts/marvell/db-falcon-carrier-a7k.dts     |  27 +++
>>  .../boot/dts/marvell/db-falcon-carrier.dtsi   |  22 +++
>>  8 files changed, 232 insertions(+), 2 deletions(-)
>>  create mode 100644 arch/arm64/boot/dts/marvell/armada-7020-comexpress.dtsi
>>  create mode 100644 arch/arm64/boot/dts/marvell/db-falcon-carrier-a7k.dts
>>  create mode 100644 arch/arm64/boot/dts/marvell/db-falcon-carrier.dtsi
>> 
>> --
>> 2.25.1
>> 
>> 
>> 
>
>
> My bot found new DTB warnings on the .dts files added or changed in this
> series.
>
> Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
> are fixed by another series. Ultimately, it is up to the platform
> maintainer whether these warnings are acceptable or not. No need to reply
> unless the platform maintainer has comments.
>
> If you already ran DT checks and didn't see these error(s), then
> make sure dt-schema is up to date:
>
>   pip3 install dtschema --upgrade
>
>
> This patch series was applied (using b4) to base:
>  Base: attempting to guess base-commit...
>  Base: tags/next-20260121 (exact match)
>  Base: tags/next-20260121 (use --merge-base to override)
>
> If this is not the correct base, please add 'base-commit' tag
> (or use b4 which does this automatically)
>
>
> New warnings running 'make CHECK_DTBS=y for arch/arm64/boot/dts/marvell/' for [email-masked]:
>
> arch/arm64/boot/dts/marvell/db-falcon-carrier-a7k.dtb: ethernet@0 (marvell,armada-7k-pp22): ethernet-port@0:phy-mode:0: '10gbase-kr' is not one of ['gmii', 'sgmii', 'rgmii-id', '1000base-x', '2500base-x', '5gbase-r', 'rxaui', '10gbase-r']
> 	from schema $id:
> http://devicetree.org/schemas/net/marvell,pp2.yaml

Does this mean we should add 10gbase-kr to the phy-mode enum list in
Documentation/devicetree/bindings/net/marvell?

Adding it would likely resolve the warning, but I’m not sure if it’s the
correct approach from the driver’s perspective. That’s why I’ve included
Andrew in the To field and added Maxime as well.

Regards,

Gregory

-- 
Grégory CLEMENT, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com