Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp4712090pxa; Mon, 10 Aug 2020 16:32:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz5oxTba7IVG26cOpkWt4SDeKRYgg8zvey9wkEK0creBIo5ihyPJbtkR8Amn5fwLQRpKVPP X-Received: by 2002:a17:906:2717:: with SMTP id z23mr5473755ejc.19.1597102349347; Mon, 10 Aug 2020 16:32:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597102349; cv=none; d=google.com; s=arc-20160816; b=XPbFPEGsAkEvacDqXUQhlJYuvps9trfrEtGIl9pPGySYG6UfKtc0KvOFBQFLiHki+J s3q/ZN6T2F+5xKASxPIBhNqsuj6T/g/NiA8cHeuQClDhwaovX2dvJdWVc5TD+y0hutA2 BIiF+3n+6N1kTINkZ1iYMh2Pn9EZgj8ICtTqK6yHaBel4ym0VS0zirO7eTfNeIni2Thk pXdoo+2Nkot+YNbmjCRer5eEDB31GlDkSHHesKqitOMSrWZpJdXL18iH3QbCTq/a+SOB gOOylbB7cgG0ldji/LIYwzME2q9tHS3mDLtsOz2drooJpP2zQhgyDO3qkUCSnVEEhemD QYag== 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:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=z0r+lCZYPiccixe3QpsKbupOQvldS1z/zwKsOkfGnbY=; b=IHVgbQrcjFmYFJsyGb6lpabc3V1Qk6LRyezQfIZDUgbO0NBblHqPlkN6SYPPda9vEa NATL2MRwZio/jGG9qoXAZKzelSYHFAP3ynbelu4jQjsoFLBoHYVh+4CDvmno93xrSDMU 4q4MZVwHBNdNsxGajdq8isnv7jsnfi/gcorctTN7TWR65+0m8YMYG6kvVexm+cQmFac5 Z5MHPZAEO1fevbHMHdr9XkG/zMWaGfi2wz1UjVG/KJ8k2XEGG20bc6PnGXlfw1PX0aNU jogrBi+Qs92OA4rLbpLg6jrCV9yoJK+N44QFRGurfF1T0jH76KAR5zLOtJYLszxjm4uw Rx/A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=tMtC168B; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bt12si11277886edb.547.2020.08.10.16.32.04; Mon, 10 Aug 2020 16:32:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=tMtC168B; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727848AbgHJX2k (ORCPT + 99 others); Mon, 10 Aug 2020 19:28:40 -0400 Received: from mail.kernel.org ([198.145.29.99]:52408 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726918AbgHJX2k (ORCPT ); Mon, 10 Aug 2020 19:28:40 -0400 Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4117220748; Mon, 10 Aug 2020 23:28:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1597102119; bh=z0r+lCZYPiccixe3QpsKbupOQvldS1z/zwKsOkfGnbY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=tMtC168Bnm85aHCmeS+xFlUQehFiZbUw8MhBWzmR+rX9oXkBTJ9+6sjcAGUs/ol6B VuYqe1fumGkUlr+mxa3T/EuBk1y2t1nTxpQvBKSzP90oJ3cNI5r3pdhOO61Z0m5ri8 b1WJ4rR5P8XSyYq0Q+bD2m2pLDXcvF8KQ7/6ZfEM= Received: by mail-ed1-f50.google.com with SMTP id bs17so7681185edb.1; Mon, 10 Aug 2020 16:28:39 -0700 (PDT) X-Gm-Message-State: AOAM530/Es6M6rZ2sGTxSIK+AELd0zZIKYLiMzuJOHuHbSAxEJKUbWQi siz6uxEYpAKaSwfb0r9gJomCSuMNRDyK8saF2A== X-Received: by 2002:a50:d80b:: with SMTP id o11mr1986679edj.148.1597102117741; Mon, 10 Aug 2020 16:28:37 -0700 (PDT) MIME-Version: 1.0 References: <20200807082754.6790-1-linux@fw-web.de> <20200807082754.6790-2-linux@fw-web.de> In-Reply-To: From: Chun-Kuang Hu Date: Tue, 11 Aug 2020 07:28:25 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/2] arm: dts: mt7623: move more display-related nodes to mt7623n.dtsi To: David Woodhouse Cc: Chun-Kuang Hu , Frank Wunderlich , devicetree@vger.kernel.org, Ryder Lee , Sean Wang , linux-kernel , Rob Herring , "moderated list:ARM/Mediatek SoC support" , Matthias Brugger , Frank Wunderlich , Linux ARM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, David: David Woodhouse =E6=96=BC 2020=E5=B9=B48=E6=9C=8810= =E6=97=A5 =E9=80=B1=E4=B8=80 =E4=B8=8B=E5=8D=883:48=E5=AF=AB=E9=81=93=EF=BC= =9A > > On Sun, 2020-08-09 at 08:16 +0800, Chun-Kuang Hu wrote: > > I would like to put all device in mt7623.dtsi with some device's > > status is "disabled" and change its status in platform dtsi. > > I would like to see all device in mt7623.dtsi because of its name. If > > you move some device to platform dtsi, we would trace all platform > > dtsi to find out how many device in mt7623. One day a new platform > > enable different devices, you would reorganize all these platform > > dtsi? > > No, this isn't "platform dtsi", surely? This is mt7623a and mt7623n > dtsi for the two different SoCs, and platforms then just include > mt7623a.dtsi or mt7623n.dtsi as appropriate for the SoC they are using. > > If you really want *all* the nodes for both MT7623A and MT7623N chips > in a single mt7623.dtsi but disabled, could we still have mt7623a.dtsi > and mt7623n.dtsi for the chips, enabling the nodes that are only-for-A > or only-for-N, so that each platform doesn't have to do that for > itself? > > Although putting those nodes that exist only in one chip or the other > directly into the mt7623[an].dtsi still seems to make more sense to > me. Sorry I does not notice that mt7623a and mt7623n are different SoC. Because they are different SoC, I think the first step is to upstream mt7623a.dtsi and mt7623n.dtsi independently. That means in each dtsi, it include all devices of its SoC. After both dtsi is upsteamed, we could find out what is the common part, then we create a common dtsi these two SoC, for example mt7623a_mt7623n_common.dtsi. (Maybe there is a SoC's name is exactly 'mt7623', so I prefer mt7623.dtsi is reserved for that SoC, and mt7623_common.dtsi is not preferred because I don't know there are how many mt7623 family SoC and mt7623_common.dtsi should be use for all mt7623 family) Regards, Chun-Kuang.