From patchwork Fri Nov 18 09:38:32 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gregory CLEMENT X-Patchwork-Id: 9436099 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 6D34A60469 for ; Fri, 18 Nov 2016 09:41:09 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6FD572985E for ; Fri, 18 Nov 2016 09:41:09 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 6490529860; Fri, 18 Nov 2016 09:41:09 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id BFC6D29861 for ; Fri, 18 Nov 2016 09:41:08 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.85_2 #1 (Red Hat Linux)) id 1c7fdU-0006Mf-Vc; Fri, 18 Nov 2016 09:39:08 +0000 Received: from mail.free-electrons.com ([62.4.15.54]) by bombadil.infradead.org with esmtp (Exim 4.85_2 #1 (Red Hat Linux)) id 1c7fdP-0006K2-GY for linux-arm-kernel@lists.infradead.org; Fri, 18 Nov 2016 09:39:04 +0000 Received: by mail.free-electrons.com (Postfix, from userid 110) id CB961207C0; Fri, 18 Nov 2016 10:38:41 +0100 (CET) Received: from localhost (83.146.29.93.rev.sfr.net [93.29.146.83]) by mail.free-electrons.com (Postfix) with ESMTPSA id 9D184207BF; Fri, 18 Nov 2016 10:38:31 +0100 (CET) From: Gregory CLEMENT To: Thomas Petazzoni Subject: Re: [PATCH v3 09/13] ARM: dts: armada-375: Fixup soc DT warning References: <20161117230830.31047-1-gregory.clement@free-electrons.com> <20161117230830.31047-10-gregory.clement@free-electrons.com> <20161118095455.00bfe007@free-electrons.com> <87d1htb1qr.fsf@free-electrons.com> <20161118101248.784eff2b@free-electrons.com> Date: Fri, 18 Nov 2016 10:38:32 +0100 In-Reply-To: <20161118101248.784eff2b@free-electrons.com> (Thomas Petazzoni's message of "Fri, 18 Nov 2016 10:12:48 +0100") Message-ID: <877f81b013.fsf@free-electrons.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20161118_013903_728422_77DD52A8 X-CRM114-Status: GOOD ( 19.17 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Andrew Lunn , Jason Cooper , devicetree@vger.kernel.org, Rob Herring , linux-arm-kernel@lists.infradead.org, Sebastian Hesselbarth Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP Hi Thomas, On ven., nov. 18 2016, Thomas Petazzoni wrote: > Hello, > > On Fri, 18 Nov 2016 10:01:32 +0100, Gregory CLEMENT wrote: > >> >> + soc@f00100000000 { >> > >> > Where is this value coming from? Why does the soc node needs to have a >> >> It cames from the dts files. > > Where? MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000 MBUS_ID(0x09, 0x09) 0 0xf1100000 0x10000 > >> > unit address? It doesn't have a 'reg' property if I remember >> > correctly. >> >> But it has a range property. > > And? There are multiple ranges, and you randomly took the first one for > the unit address of the soc node? Not randomly I followed the same rules that for the regs mentioned in the ePAPR paragraph 2.2.1.1: "The unit-address should match the first address specified in the reg property of the node." > > You realize that the ranges property is a list of ranges, and they > could be in any order? Why would you pick the base address of one of > the ranges rather than any of the others? It is the same for the regs so as explained I followed the same rules. > > I believe there is simply no unit address for the soc {} node. There is > definitely one for the internal-regs {} node, but not for the soc {} > node. It is not the interpretation of the DTC: "Warning (unit_address_vs_reg): Node /soc has a reg or ranges property, but no unit name" Gregory > > Best regards, > > Thomas > -- > Thomas Petazzoni, CTO, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com --- a/arch/arm/boot/dts/armada-375-db.dts +++ b/arch/arm/boot/dts/armada-375-db.dts @@ -63,7 +63,11 @@ reg = <0x00000000 0x40000000>; /* 1 GB */ }; - soc { + /* The following unit address is composed of the target + * value (bit [40-47]), attributes value (bits [32-39], + * and the address value in the window memory: [0-31]. + */ + soc@f00100000000 { ranges =