Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp6119409ybf; Thu, 5 Mar 2020 13:32:52 -0800 (PST) X-Google-Smtp-Source: ADFU+vuRuuvFQjD7n8ghzuNiKMNNEpqTibSfb0shZYXth4wW6QKD1toHTMSUq8KBM47E6RBK1cA7 X-Received: by 2002:a05:6808:359:: with SMTP id j25mr339006oie.15.1583443971953; Thu, 05 Mar 2020 13:32:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583443971; cv=none; d=google.com; s=arc-20160816; b=wfx7VI0v/nr01SbeMRV8hGyhS56K+bxxNKOl/eK4e0PRI0D+iJBpuyEMOCKd+9ifnJ K6fJF5x5lquU2Xzle/J+Biy/yzlNXoumyMGZthJ6W5aWQJfEYrmQpZrsct3RpzhU+W3N FIJKo+b+h1I7SN4uxharXXlTuIcIUOx9tv5VQ7mgKAIZJZlJxNiNokQZ/0DMkpaGHOJi iHDPfZ0bzX5xHcbwTIYKwc8pNZgj13ydl66yCYFk2SpxlzTFcwO+bVI2PKspBS9zDwKr vIMKVqZ8Oc7risQskel5EcSBFQ9n4vc5NMgGLcRN+mBXvd20PYrZ3S91gpQqlDVB96Hz cOYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=Aaxpv8HBLBTqoRdysQcf6U1WdBa3p8yfLK4V6lIaWc4=; b=GaXZcmM3Ye7KZLkkR86PkDLEMsLb7QXiV7TBOkSN48+pMa6HY4LEpKRN3oslyblpsv L7lQL82u6fswgdFx0il36SstFAT1UvezdeqL4TcvHl6P6CcoaKkOKscxm658vCu+jfPB bE9b3251PegRmyha+GQ6k7yU4lqE9OJMautkm9YkByEZtF0hFDSf0+KnjTffe5lPbc8n LVMll14s/5ruE73RLNIkpzNYFFuixrkjyI7HaFGgxnCvFh4urwtuxMmj+yCgdeA7Edcc tpZkMQUY27h5B89QCknD7k8/cbgAm/zllFD0cXrM4KZSw5WeeBb91oxmXj3W1CzWaxbF SB4w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d125si121294oia.86.2020.03.05.13.32.39; Thu, 05 Mar 2020 13:32:51 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726184AbgCEVcG convert rfc822-to-8bit (ORCPT + 99 others); Thu, 5 Mar 2020 16:32:06 -0500 Received: from gloria.sntech.de ([185.11.138.130]:53744 "EHLO gloria.sntech.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725991AbgCEVcG (ORCPT ); Thu, 5 Mar 2020 16:32:06 -0500 Received: from ip5f5a5d2f.dynamic.kabel-deutschland.de ([95.90.93.47] helo=phil.localnet) by gloria.sntech.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1j9y64-00064u-IE; Thu, 05 Mar 2020 22:32:00 +0100 From: Heiko Stuebner To: Johan Jonker , robh+dt@kernel.org Cc: devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/3] ARM: dts: rockchip: add missing @0 to memory nodenames Date: Thu, 05 Mar 2020 22:31:59 +0100 Message-ID: <1784340.9KJLpVao5L@phil> In-Reply-To: <20200304074051.8742-2-jbx6244@gmail.com> References: <20200304074051.8742-1-jbx6244@gmail.com> <20200304074051.8742-2-jbx6244@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="iso-8859-1" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Johan, Am Mittwoch, 4. M?rz 2020, 08:40:50 CET schrieb Johan Jonker: > A test with the command below gives for example this error: > > arch/arm/boot/dts/rk3288-tinker.dt.yaml: /: memory: > False schema does not allow > {'device_type': ['memory'], 'reg': [[0, 0, 0, 2147483648]]} > > The memory nodes all have a reg property that requires '@' in > the nodename. Fix this error by adding the missing '@0' to > the involved memory nodenames. > > make ARCH=arm dtbs_check > DT_SCHEMA_FILES=~/.local/lib/python3.5/site-packages/dtschema/ > schemas/root-node.yaml changes to memory nodes you sadly cannot do in such an automated fashion. If you read the comment in rk3288-veyron.dtsi you'll see that a previous similar iteration broke all of those machines as their coreboot doesn't copy with memory@0 and would insert another memory node without @0 In the past iteration the consensus then was that memory without @0 is also ok (as it isn't changeable anyway). As I don't really want to repeat that, I'd like actual hardware tests before touching memory nodes. Heiko