From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7A2AAC433FE for ; Tue, 10 May 2022 12:43:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241910AbiEJMru (ORCPT ); Tue, 10 May 2022 08:47:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44372 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241930AbiEJMrs (ORCPT ); Tue, 10 May 2022 08:47:48 -0400 Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0E7A754FB5 for ; Tue, 10 May 2022 05:43:50 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id e194so18328886iof.11 for ; Tue, 10 May 2022 05:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sartura-hr.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hZCHHeV1vrwaORolvlc++uou2W11D5cQmd9g7J8Duyo=; b=6r3ZTvcJXGB8tEPC11iQZMG1+0uwYhCNX2OEALTbsIShYvYKXO+ujmbx2NoBqkxg1k WACAKpdh9G32mfAQMsWhB8G7kGvN4sMELkFykG97HDSUrZW+1XFhdtB6km5Nq3DfAWTK szrgABXbRPdfJfZCnULIu0zGe5JrKftEhv3ajv76PD7uNNII+0/ZWWzrZI4+KLLfW3ij zJCxmoolia82c46FMh61IQKC6o7SspyCoGq9Er8ojL70p72Z1FVZEhmqM0oHrlpm6H1j nMiJ/I998OtM0Fz7WLzhZVZAoc7Mo3oZqwx6oQZJ2NlwguIvLixltnyOtM/7BrsBrGyF ekiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hZCHHeV1vrwaORolvlc++uou2W11D5cQmd9g7J8Duyo=; b=RsMBQsEtabcm5xaC5YwwDT1AAZRVqcEMqlX/+98yayMuuXKSoWBKUrW20YTUT+O3fT D2cBYdAcXUpC4El1HXTQGPvg9XqE5/e2ZtWI48NBv5TcQcvfg+7Feid807hha9w5Xahh uZUgn0FoVpXYVq/G6zDD+VGapugEuwClNFLV0V6Xi0j07Eiwm3FEjrj5YL32l+Gh1BgP iP10BFHav0aZR/9X/Kk0xlxdNhl78/VQPd1exx/GQBIxvWX5jAIfrH9C5eWgo29KGrSe 619fPvqKOrPheMIs+TctthOOAYZRTkAw0t3zfBKCwABufi71Sa9GxxSyavajOpev9uFH 2O/w== X-Gm-Message-State: AOAM530N2oEXyYiDuNK7+a3A/AZg9glNtXEhcoDFV1Y9ELQCUAQ/6N0X 6lhniRGxwtGRlLU96SW8cH85dWoC6gikQGSXA5vlmA== X-Google-Smtp-Source: ABdhPJzxGsE9e1jC8Gr1xp08AKX2vrG1wP1od8sZP/jQ77AsygZ0FDZToBhxBE3p/zMQL5yqtqmTuuWILEt9xoEE8C8= X-Received: by 2002:a05:6638:34a2:b0:32b:7d4f:8932 with SMTP id t34-20020a05663834a200b0032b7d4f8932mr9877917jal.317.1652186629374; Tue, 10 May 2022 05:43:49 -0700 (PDT) MIME-Version: 1.0 References: <20220509110028.144226-1-robert.marko@sartura.hr> <20220509110028.144226-2-robert.marko@sartura.hr> <8e22cbf7-eee1-0ec7-10f9-3839ec80dfbf@linaro.org> In-Reply-To: From: Robert Marko Date: Tue, 10 May 2022 14:43:38 +0200 Message-ID: Subject: Re: [PATCH 2/2] arm64: dts: marvell: add support for Methode eDPU To: Krzysztof Kozlowski Cc: Rob Herring , krzysztof.kozlowski+dt@linaro.org, Andrew Lunn , gregory.clement@bootlin.com, sebastian.hesselbarth@gmail.com, shawnguo@kernel.org, Linus Walleij , kostap@marvell.com, devicetree , Linux Kernel Mailing List , Linux ARM , =?UTF-8?Q?Pali_Roh=C3=A1r?= , =?UTF-8?B?TWFyZWsgQmVow7pu?= Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 10, 2022 at 1:46 PM Krzysztof Kozlowski wrote: > > On 10/05/2022 13:41, Robert Marko wrote: > > On Tue, May 10, 2022 at 12:20 PM Krzysztof Kozlowski > > wrote: > >> > >> On 09/05/2022 13:00, Robert Marko wrote: > >>> Methode eDPU is an Armada 3720 powered board based on the Methode uDPU. > >>> > >>> They feature the same CPU, RAM, and storage as well as the form factor. > >>> > >>> However, eDPU only has one SFP slot plus a copper G.hn port. > >>> > >>> In order to reduce duplication, split the uDPU DTS into a common one. > >>> > >>> Signed-off-by: Robert Marko > >>> --- > >>> arch/arm64/boot/dts/marvell/Makefile | 1 + > >>> .../boot/dts/marvell/armada-3720-eDPU.dts | 14 ++ > >>> .../boot/dts/marvell/armada-3720-uDPU.dts | 148 +--------------- > >>> .../boot/dts/marvell/armada-3720-uDPU.dtsi | 163 ++++++++++++++++++ > >>> 4 files changed, 179 insertions(+), 147 deletions(-) > >>> create mode 100644 arch/arm64/boot/dts/marvell/armada-3720-eDPU.dts > >>> create mode 100644 arch/arm64/boot/dts/marvell/armada-3720-uDPU.dtsi > >>> > >>> diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile > >>> index 1c794cdcb8e6..104d7d7e8215 100644 > >>> --- a/arch/arm64/boot/dts/marvell/Makefile > >>> +++ b/arch/arm64/boot/dts/marvell/Makefile > >>> @@ -1,6 +1,7 @@ > >>> # SPDX-License-Identifier: GPL-2.0 > >>> # Mvebu SoC Family > >>> dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-db.dtb > >>> +dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-eDPU.dtb > >>> dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin.dtb > >>> dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin-emmc.dtb > >>> dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin-ultra.dtb > >>> diff --git a/arch/arm64/boot/dts/marvell/armada-3720-eDPU.dts b/arch/arm64/boot/dts/marvell/armada-3720-eDPU.dts > >>> new file mode 100644 > >>> index 000000000000..6b573a6854cc > >>> --- /dev/null > >>> +++ b/arch/arm64/boot/dts/marvell/armada-3720-eDPU.dts > >>> @@ -0,0 +1,14 @@ > >>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) > >>> + > >>> +/dts-v1/; > >>> + > >>> +#include "armada-3720-uDPU.dtsi" > >>> + > >>> +/ { > >>> + model = "Methode eDPU Board"; > >>> + compatible = "methode,edpu", "marvell,armada3720"; > >> > >> You need also bindings for the board compatible. Someone should convert > >> the Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt to YAML. > > > > Ok, I can convert the SoC compatibles at least for now. > > Any advice you can give me on how the handle the Espressobin boards > > having multiple board-specific compatibles? > > For example, Espressobin V7 has: > > "globalscale,espressobin-v7", "globalscale,espressobin" > > > > Documentation/devicetree/bindings/arm/fsl.yaml Thanks, now it makes sense. > > >> > >>> +}; > >>> +> + sfp_eth1: sfp-eth1 { > >> > >> Generic node names, please. > > > > Can you give me an example of what would be appropriate here because the SFP > > bindings example utilizes the same naming scheme as used here? > > "sfp" if you have only one sfp node. There are 2 SFP nodes in total, that is why they are named according to the ethernet controller to which they are connected. uDPU has 2 SFP slots while eDPU has 1, so one was moved to uDPU DTS. > > > > >> > >>> + compatible = "sff,sfp"; > >>> + i2c-bus = <&i2c1>; > >>> + los-gpio = <&gpiosb 7 GPIO_ACTIVE_HIGH>; > >>> + mod-def0-gpio = <&gpiosb 8 GPIO_ACTIVE_LOW>; > >>> + tx-disable-gpio = <&gpiosb 9 GPIO_ACTIVE_HIGH>; > >>> + tx-fault-gpio = <&gpiosb 10 GPIO_ACTIVE_HIGH>; > >>> + maximum-power-milliwatt = <3000>; > >>> + }; > >>> +}; > >>> + > >>> +&sdhci0 { > >>> + status = "okay"; > >>> + bus-width = <8>; > >>> + mmc-ddr-1_8v; > >>> + mmc-hs400-1_8v; > >>> + marvell,pad-type = "fixed-1-8v"; > >>> + non-removable; > >>> + no-sd; > >>> + no-sdio; > >>> +}; > >>> + > >>> +&spi0 { > >>> + status = "okay"; > >>> + pinctrl-names = "default"; > >>> + pinctrl-0 = <&spi_quad_pins>; > >>> + > >>> + spi-flash@0 { > >> > >> Run dtbs_check and fix the errors. > > > > Ok, will split the DTSI and eDPU commits and fixup nodes in between. > >> > >>> + compatible = "jedec,spi-nor"; > >>> + reg = <0>; > >>> + spi-max-frequency = <54000000>; > >>> + > >>> + partitions { > >>> + compatible = "fixed-partitions"; > >>> + #address-cells = <1>; > >>> + #size-cells = <1>; > >>> + /* only bootloader is located on the SPI */ > >>> + partition@0 { > >>> + label = "firmware"; > >>> + reg = <0x0 0x180000>; > >>> + }; > >>> + > >>> + partition@180000 { > >>> + label = "u-boot-env"; > >>> + reg = <0x180000 0x10000>; > >>> + }; > >>> + }; > >>> + }; > >>> +}; > >>> + > >>> +&pinctrl_nb { > >>> + i2c2_recovery_pins: i2c2-recovery-pins { > >>> + groups = "i2c2"; > >>> + function = "gpio"; > >>> + }; > >>> +}; > >>> + > >>> +&i2c1 { > >>> + status = "okay"; > >>> + pinctrl-names = "default", "recovery"; > >>> + pinctrl-0 = <&i2c2_pins>; > >>> + pinctrl-1 = <&i2c2_recovery_pins>; > >>> + /delete-property/mrvl,i2c-fast-mode; > >>> + scl-gpios = <&gpionb 2 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; > >>> + sda-gpios = <&gpionb 3 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; > >>> + > >>> + nct375@48 { > >> > >> Generic node names, representing class of a device. > > Ok, will rename in v2. > >> > >>> + status = "okay"; > >> > >> OK status is by default, why do you need it? Also, it goes as last property. > > > > It's not needed, I have not changed any nodes, they are just > > copy/paste during the DTS split. > > Will drop it in v2. > > > > Hm, but the node names were different in original DTS, so this is not a > simple split. In such case better to correct coding styles in one patch > (node names, status etc) and then perform the split. The split should > create the same output DTB, which is not the case here. Understood, I did all of the fixups now before the split to make it clear. Regards, Robert > > Best regards, > Krzysztof -- Robert Marko Staff Embedded Linux Engineer Sartura Ltd. Lendavska ulica 16a 10000 Zagreb, Croatia Email: robert.marko@sartura.hr Web: www.sartura.hr From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C7A0FC433EF for ; Tue, 10 May 2022 12:45:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=aeeC1nJawMkOm1DLHtF8e34dVmTizAd/C99qlKjf6YI=; b=YLTweEOuuku9WL 0+0YZORfrXvYuVb6DkyccVCzV5Fbg5iPMpQcdJWs9bo+mzPJhjNWulzqGcDCDGzHoyegCvhLJ2WWW zssu9pTRb+VQ/E9rKuesaCi3C7cePxkslTBd9A2pJUodMKsH4XTWX0ykDeFYRmu4Wafuyq+BhDFl3 zmKPGmBRdAAFugl5vn+DVcrpxwMrlKbS6vdzLGhNK0sxbsC3hK/0B+uoIavDanbgZ9VEdERFm3yPS BO968Du/y0n9CYuWtnF0fYoDZMj6wi7myliE6pamcnMhcEJTifOvZWTiQ4i5+bGyXP8Q1gPFSHnV5 KePSyDEmyrkAF9aog2Gg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1noPDs-001yCY-9y; Tue, 10 May 2022 12:44:16 +0000 Received: from mail-io1-xd30.google.com ([2607:f8b0:4864:20::d30]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1noPDV-001y2a-8Z for linux-arm-kernel@lists.infradead.org; Tue, 10 May 2022 12:43:55 +0000 Received: by mail-io1-xd30.google.com with SMTP id o190so18353112iof.10 for ; Tue, 10 May 2022 05:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sartura-hr.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hZCHHeV1vrwaORolvlc++uou2W11D5cQmd9g7J8Duyo=; b=6r3ZTvcJXGB8tEPC11iQZMG1+0uwYhCNX2OEALTbsIShYvYKXO+ujmbx2NoBqkxg1k WACAKpdh9G32mfAQMsWhB8G7kGvN4sMELkFykG97HDSUrZW+1XFhdtB6km5Nq3DfAWTK szrgABXbRPdfJfZCnULIu0zGe5JrKftEhv3ajv76PD7uNNII+0/ZWWzrZI4+KLLfW3ij zJCxmoolia82c46FMh61IQKC6o7SspyCoGq9Er8ojL70p72Z1FVZEhmqM0oHrlpm6H1j nMiJ/I998OtM0Fz7WLzhZVZAoc7Mo3oZqwx6oQZJ2NlwguIvLixltnyOtM/7BrsBrGyF ekiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hZCHHeV1vrwaORolvlc++uou2W11D5cQmd9g7J8Duyo=; b=Sv+0rZ17h0h37tCh0WcRoW12gYj79xKA5huNBbbf0QDveQCYwhICTTDSsyuuBEzU/C JQPrLaQGi9CVspwZsaX2aSf/mdkwOHWWX7kTlO+Dp47Mx8BecHCxuNTAIDFaNLYYqtC3 RYzqmzX/CDGyadrHmR/EGKSPkfs09D0lGLEwiL7JNcsip7FlSZWTaGgicV6b8rnmBGYo hZZSTQC1JGyqSXJlcFgJf97VKujI1S3Tf+6hTMx0M9/iRmtfeXKU0nz/cRCdJhmwkwxF 8OkHaG3uuC5T5E9Ha9rCIdBgvZlkwczC8uM13/Y5sHPL0S2b6vr6MMLsnoAuH84vlTXA 3+FQ== X-Gm-Message-State: AOAM5319p87V6WS5SikOtlRxMw7re/0ONVBipNT5Vxe9rBupQctW+cYR IDEYXv1/uTptBrFxbqxqMr4kkG3XDLm81RWmw8DFvA== X-Google-Smtp-Source: ABdhPJzxGsE9e1jC8Gr1xp08AKX2vrG1wP1od8sZP/jQ77AsygZ0FDZToBhxBE3p/zMQL5yqtqmTuuWILEt9xoEE8C8= X-Received: by 2002:a05:6638:34a2:b0:32b:7d4f:8932 with SMTP id t34-20020a05663834a200b0032b7d4f8932mr9877917jal.317.1652186629374; Tue, 10 May 2022 05:43:49 -0700 (PDT) MIME-Version: 1.0 References: <20220509110028.144226-1-robert.marko@sartura.hr> <20220509110028.144226-2-robert.marko@sartura.hr> <8e22cbf7-eee1-0ec7-10f9-3839ec80dfbf@linaro.org> In-Reply-To: From: Robert Marko Date: Tue, 10 May 2022 14:43:38 +0200 Message-ID: Subject: Re: [PATCH 2/2] arm64: dts: marvell: add support for Methode eDPU To: Krzysztof Kozlowski Cc: Rob Herring , krzysztof.kozlowski+dt@linaro.org, Andrew Lunn , gregory.clement@bootlin.com, sebastian.hesselbarth@gmail.com, shawnguo@kernel.org, Linus Walleij , kostap@marvell.com, devicetree , Linux Kernel Mailing List , Linux ARM , =?UTF-8?Q?Pali_Roh=C3=A1r?= , =?UTF-8?B?TWFyZWsgQmVow7pu?= X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220510_054353_595123_06D290B0 X-CRM114-Status: GOOD ( 35.26 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, May 10, 2022 at 1:46 PM Krzysztof Kozlowski wrote: > > On 10/05/2022 13:41, Robert Marko wrote: > > On Tue, May 10, 2022 at 12:20 PM Krzysztof Kozlowski > > wrote: > >> > >> On 09/05/2022 13:00, Robert Marko wrote: > >>> Methode eDPU is an Armada 3720 powered board based on the Methode uDPU. > >>> > >>> They feature the same CPU, RAM, and storage as well as the form factor. > >>> > >>> However, eDPU only has one SFP slot plus a copper G.hn port. > >>> > >>> In order to reduce duplication, split the uDPU DTS into a common one. > >>> > >>> Signed-off-by: Robert Marko > >>> --- > >>> arch/arm64/boot/dts/marvell/Makefile | 1 + > >>> .../boot/dts/marvell/armada-3720-eDPU.dts | 14 ++ > >>> .../boot/dts/marvell/armada-3720-uDPU.dts | 148 +--------------- > >>> .../boot/dts/marvell/armada-3720-uDPU.dtsi | 163 ++++++++++++++++++ > >>> 4 files changed, 179 insertions(+), 147 deletions(-) > >>> create mode 100644 arch/arm64/boot/dts/marvell/armada-3720-eDPU.dts > >>> create mode 100644 arch/arm64/boot/dts/marvell/armada-3720-uDPU.dtsi > >>> > >>> diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile > >>> index 1c794cdcb8e6..104d7d7e8215 100644 > >>> --- a/arch/arm64/boot/dts/marvell/Makefile > >>> +++ b/arch/arm64/boot/dts/marvell/Makefile > >>> @@ -1,6 +1,7 @@ > >>> # SPDX-License-Identifier: GPL-2.0 > >>> # Mvebu SoC Family > >>> dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-db.dtb > >>> +dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-eDPU.dtb > >>> dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin.dtb > >>> dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin-emmc.dtb > >>> dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin-ultra.dtb > >>> diff --git a/arch/arm64/boot/dts/marvell/armada-3720-eDPU.dts b/arch/arm64/boot/dts/marvell/armada-3720-eDPU.dts > >>> new file mode 100644 > >>> index 000000000000..6b573a6854cc > >>> --- /dev/null > >>> +++ b/arch/arm64/boot/dts/marvell/armada-3720-eDPU.dts > >>> @@ -0,0 +1,14 @@ > >>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) > >>> + > >>> +/dts-v1/; > >>> + > >>> +#include "armada-3720-uDPU.dtsi" > >>> + > >>> +/ { > >>> + model = "Methode eDPU Board"; > >>> + compatible = "methode,edpu", "marvell,armada3720"; > >> > >> You need also bindings for the board compatible. Someone should convert > >> the Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt to YAML. > > > > Ok, I can convert the SoC compatibles at least for now. > > Any advice you can give me on how the handle the Espressobin boards > > having multiple board-specific compatibles? > > For example, Espressobin V7 has: > > "globalscale,espressobin-v7", "globalscale,espressobin" > > > > Documentation/devicetree/bindings/arm/fsl.yaml Thanks, now it makes sense. > > >> > >>> +}; > >>> +> + sfp_eth1: sfp-eth1 { > >> > >> Generic node names, please. > > > > Can you give me an example of what would be appropriate here because the SFP > > bindings example utilizes the same naming scheme as used here? > > "sfp" if you have only one sfp node. There are 2 SFP nodes in total, that is why they are named according to the ethernet controller to which they are connected. uDPU has 2 SFP slots while eDPU has 1, so one was moved to uDPU DTS. > > > > >> > >>> + compatible = "sff,sfp"; > >>> + i2c-bus = <&i2c1>; > >>> + los-gpio = <&gpiosb 7 GPIO_ACTIVE_HIGH>; > >>> + mod-def0-gpio = <&gpiosb 8 GPIO_ACTIVE_LOW>; > >>> + tx-disable-gpio = <&gpiosb 9 GPIO_ACTIVE_HIGH>; > >>> + tx-fault-gpio = <&gpiosb 10 GPIO_ACTIVE_HIGH>; > >>> + maximum-power-milliwatt = <3000>; > >>> + }; > >>> +}; > >>> + > >>> +&sdhci0 { > >>> + status = "okay"; > >>> + bus-width = <8>; > >>> + mmc-ddr-1_8v; > >>> + mmc-hs400-1_8v; > >>> + marvell,pad-type = "fixed-1-8v"; > >>> + non-removable; > >>> + no-sd; > >>> + no-sdio; > >>> +}; > >>> + > >>> +&spi0 { > >>> + status = "okay"; > >>> + pinctrl-names = "default"; > >>> + pinctrl-0 = <&spi_quad_pins>; > >>> + > >>> + spi-flash@0 { > >> > >> Run dtbs_check and fix the errors. > > > > Ok, will split the DTSI and eDPU commits and fixup nodes in between. > >> > >>> + compatible = "jedec,spi-nor"; > >>> + reg = <0>; > >>> + spi-max-frequency = <54000000>; > >>> + > >>> + partitions { > >>> + compatible = "fixed-partitions"; > >>> + #address-cells = <1>; > >>> + #size-cells = <1>; > >>> + /* only bootloader is located on the SPI */ > >>> + partition@0 { > >>> + label = "firmware"; > >>> + reg = <0x0 0x180000>; > >>> + }; > >>> + > >>> + partition@180000 { > >>> + label = "u-boot-env"; > >>> + reg = <0x180000 0x10000>; > >>> + }; > >>> + }; > >>> + }; > >>> +}; > >>> + > >>> +&pinctrl_nb { > >>> + i2c2_recovery_pins: i2c2-recovery-pins { > >>> + groups = "i2c2"; > >>> + function = "gpio"; > >>> + }; > >>> +}; > >>> + > >>> +&i2c1 { > >>> + status = "okay"; > >>> + pinctrl-names = "default", "recovery"; > >>> + pinctrl-0 = <&i2c2_pins>; > >>> + pinctrl-1 = <&i2c2_recovery_pins>; > >>> + /delete-property/mrvl,i2c-fast-mode; > >>> + scl-gpios = <&gpionb 2 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; > >>> + sda-gpios = <&gpionb 3 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; > >>> + > >>> + nct375@48 { > >> > >> Generic node names, representing class of a device. > > Ok, will rename in v2. > >> > >>> + status = "okay"; > >> > >> OK status is by default, why do you need it? Also, it goes as last property. > > > > It's not needed, I have not changed any nodes, they are just > > copy/paste during the DTS split. > > Will drop it in v2. > > > > Hm, but the node names were different in original DTS, so this is not a > simple split. In such case better to correct coding styles in one patch > (node names, status etc) and then perform the split. The split should > create the same output DTB, which is not the case here. Understood, I did all of the fixups now before the split to make it clear. Regards, Robert > > Best regards, > Krzysztof -- Robert Marko Staff Embedded Linux Engineer Sartura Ltd. Lendavska ulica 16a 10000 Zagreb, Croatia Email: robert.marko@sartura.hr Web: www.sartura.hr _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel