linux-kernel - Re: [PATCH] ARM: dts: mvebu: Add device tree for RD-AC3X-48G4X2XL board

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <95016967-257b-e715-c907-0ac396e125ee@alliedtelesis.co.nz>
Date:   Mon, 23 Nov 2020 04:43:39 +0000
From:   Chris Packham <Chris.Packham@...iedtelesis.co.nz>
To:     Aryan Srivastava <Aryan.Srivastava@...iedtelesis.co.nz>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "andrew@...n.ch" <andrew@...n.ch>,
        "gregory.clement@...tlin.com" <gregory.clement@...tlin.com>,
        "sebastian.hesselbarth@...il.com" <sebastian.hesselbarth@...il.com>,
        "Chris Packham" <Chris.Packham@...iedtelesis.co.nz>
CC:     "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] ARM: dts: mvebu: Add device tree for RD-AC3X-48G4X2XL
 board

Hi Aryan,

On 23/11/20 4:52 pm, Aryan Srivastava wrote:
> Add device tree for RD-AC3X-48G4X2XL board. This has a Armada 382 SoC on
> a interposer board connected to a baseboard with a Prestera AC3X ASIC
> connected via PCI.
>
> Signed-off-by: Aryan Srivastava <aryan.srivastava@...iedtelesis.co.nz>
Reviewed-by: Chris Packham <chris.packham@...iedtelesis.co.nz>
> ---
>   arch/arm/boot/dts/Makefile                    |   1 +
>   .../boot/dts/armada-382-rd-ac3x-48g4x2xl.dts  | 114 ++++++++++++++++++
>   2 files changed, 115 insertions(+)
>   create mode 100644 arch/arm/boot/dts/armada-382-rd-ac3x-48g4x2xl.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index ce66ffd5a1bb..a60407ad7347 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1319,6 +1319,7 @@ dtb-$(CONFIG_MACH_ARMADA_370) += \
>   dtb-$(CONFIG_MACH_ARMADA_375) += \
>   	armada-375-db.dtb
>   dtb-$(CONFIG_MACH_ARMADA_38X) += \
> +	armada-382-rd-ac3x-48g4x2xl.dtb \
>   	armada-385-clearfog-gtr-s4.dtb \
>   	armada-385-clearfog-gtr-l8.dtb \
>   	armada-385-db-88f6820-amc.dtb \
> diff --git a/arch/arm/boot/dts/armada-382-rd-ac3x-48g4x2xl.dts b/arch/arm/boot/dts/armada-382-rd-ac3x-48g4x2xl.dts
> new file mode 100644
> index 000000000000..b08d662a8519
> --- /dev/null
> +++ b/arch/arm/boot/dts/armada-382-rd-ac3x-48g4x2xl.dts
> @@ -0,0 +1,114 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Device Tree file for Marvell Armada 382 reference board
> + * (RD-AC3X-48G4X2XL)
> + *
> + * Copyright (C) 2020 Allied Telesis Labs
> + */
> +
> +/dts-v1/;
> +#include "armada-385.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +
> +/ {
> +	model = "Marvell Armada 382 RD-AC3X";
> +	compatible = "marvell,rd-ac3x-48g4x2xl", "marvell,rd-ac3x",
> +			 "marvell,armada385", "marvell,armada380";
> +
> +	chosen {
> +		stdout-path = "serial0:115200n8";
> +	};
> +
> +	aliases {
> +		ethernet0 = &eth1;
> +	};
> +
> +	memory {
> +		device_type = "memory";
> +		reg = <0x00000000 0x20000000>; /* 512MB */
> +	};
> +
> +	soc {
> +		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
> +			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000>;
> +	};
> +};
> +
> +&i2c0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c0_pins>;
> +	status = "okay";
> +
> +	eeprom@53{
> +		compatible = "atmel,24c64";
> +		reg = <0x53>;
> +	};
> +//	cpld@3c{
> +//		compatible = "marvell,ac3x-cpld";
> +//		reg = <0x3c>;
> +//	};
> +};

Question for the mvebu maintainers: We know there is a cpld with that 
can be interfaced with over i2c. Other than detecting that it shows up 
on the i2c bus we haven't done anything with it. We believe it 
interfaces with some discrete IO and might mux the i2c interface towards 
the SFP/QSFP cages.

Obviously there isn't a "marvell,ac3x-cpld" driver (yet) so I suggested 
to Aryan that we put it in the dts to document its existence but leave 
it commented out for now. Is this OK?

> +
> +&uart0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart0_pins>;
> +	status = "okay";
> +};
> +
> +&eth1 {
> +	status = "okay";
> +	phy = <&phy0>;
> +	phy-mode = "rgmii-id";
> +};
> +
> +&mdio {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&mdio_pins>;
> +
> +	phy0: ethernet-phy@0 {
> +		reg = <0>;
> +	};
> +};
> +
> +&pciec {
> +	status = "okay";
> +};
> +
> +&pcie1 {
> +	/* Port 0, Lane 0 */
> +	status = "okay";
> +};
> +
> +&nand_controller {
> +	status = "okay";
> +
> +	nand@0 {
> +		reg = <0>;
> +		label = "pxa3xx_nand-0";
> +		nand-rb = <0>;
> +		nand-on-flash-bbt;
> +
> +		partitions {
> +			compatible = "fixed-partitions";
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			partition@0 {
> +				reg = <0x00000000 0x00500000>;
> +				label = "u-boot";
> +			};
> +			partition@...000{
> +				reg = <0x00500000 0x00400000>;
> +				label = "u-boot env";
> +			};
> +			partition@...000{
> +				reg = <0x00900000 0x3F700000>;
> +				label = "user";
> +			};
> +		};
> +	};
> +};
> +
> +&refclk {
> +	clock-frequency = <200000000>;
> +};