Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp4963635iog; Wed, 22 Jun 2022 09:09:14 -0700 (PDT) X-Google-Smtp-Source: AGRyM1s9Z8ttnr2GTCcHOfh3SvTX3MOUI4orkjD6wuCojMfE8f69HELFDRneFsu5uNKJH+tGoiT5 X-Received: by 2002:a17:907:720e:b0:722:df77:f24e with SMTP id dr14-20020a170907720e00b00722df77f24emr3732119ejc.165.1655914154570; Wed, 22 Jun 2022 09:09:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655914154; cv=none; d=google.com; s=arc-20160816; b=IXnnVzVwcu977I7aeWgCkmFQ5PwIoQfrUnCF96JjnjsDgcSnu9sbQKAKs3WJuEN5tQ Y/EoaOpfZOgZq1zorWTvq1cUoi4DL2thdTQiITkTq+IE+gEjMTfoa/tD25sQcbSoXEUL +XLRVqd4n8ff71i0sdBe3tvsPNim0Fp+RhWDKXbU6upY8cMf37wBjqwujHcF9E68mwtl GFGmXQvA2PPNne+7XHybDmJyZPBmImmYw/uWtEt+IQfeoNgekpEtZgnbt9e7xumqxtvp 73RWDWWlQ7IH3kX8TGgMunREK2k265Y8ZIsJCFWxgjOT2gLLyDlWMaTwvBY2b/f3KY/1 8IpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=8qXxlUwZsjjgwlV20kK/hqdL6iYGhNVVKv3wVbRZPYU=; b=L6vRwos6wFK13c1HUqYw8arPAspwVg6zM8nVyiWp4vu4tc9WUO65qjWxDvTC/VyiGy HL9uOY7c8c/z+4w53+iC9+lrDZnBkbRCG5WuSueLM3QYQf6/DWGFKLiAdXgvP1vm/t4R +/pRJfkEA9fKYtg37DjCroLmURUIprldmK+XHJWdLJUd417/nJG9p+qSpNGHfHgL+Zm6 462hivBYYC1Ym8Xn3Qau5oe2VIdIStLNxsClCOcBx9wMK0hhYd4jDENP0yvPLOpOjC42 dpFzRw4CjbvrdpM9oSoVTg1fiFzDuglDYNCp2aEdYeAhEh1lvzP8nKi14Bgp8HqYr9XD 4jIQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d18-20020a056402401200b004357dc75c7esi11036653eda.455.2022.06.22.09.08.47; Wed, 22 Jun 2022 09:09:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357869AbiFVPj1 (ORCPT + 99 others); Wed, 22 Jun 2022 11:39:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39862 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357795AbiFVPj0 (ORCPT ); Wed, 22 Jun 2022 11:39:26 -0400 Received: from relay04.th.seeweb.it (relay04.th.seeweb.it [5.144.164.165]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 01FE42E0BE for ; Wed, 22 Jun 2022 08:39:24 -0700 (PDT) Received: from [192.168.1.101] (abxi223.neoplus.adsl.tpnet.pl [83.9.2.223]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by m-r1.th.seeweb.it (Postfix) with ESMTPSA id DE60B1FFEA; Wed, 22 Jun 2022 17:39:22 +0200 (CEST) Message-ID: <5158fe83-88b1-1081-df7f-4118ce6f5ec0@somainline.org> Date: Wed, 22 Jun 2022 17:39:22 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH v2 4/6] arm64: dts: qcom: sc8280xp: Add reference device Content-Language: en-US To: Johan Hovold Cc: Krzysztof Kozlowski , Bjorn Andersson , Andy Gross , Krzysztof Kozlowski , Rob Herring , Manivannan Sadhasivam , Jassi Brar , linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org References: <20220622041224.627803-1-bjorn.andersson@linaro.org> <20220622041224.627803-5-bjorn.andersson@linaro.org> <099cc82f-d52f-315f-189d-bcc40c1afd49@somainline.org> <9d0c1897-195f-0548-ea5d-ffc35768f518@somainline.org> <51965fa3-d146-70f1-2ad8-db6197989348@somainline.org> From: Konrad Dybcio In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 22.06.2022 17:37, Johan Hovold wrote: > On Wed, Jun 22, 2022 at 05:30:24PM +0200, Konrad Dybcio wrote: >> On 22.06.2022 17:26, Johan Hovold wrote: >>> On Wed, Jun 22, 2022 at 05:10:50PM +0200, Konrad Dybcio wrote: >>>> On 22.06.2022 16:48, Krzysztof Kozlowski wrote: >>>>> On 22/06/2022 16:36, Konrad Dybcio wrote: >>>>>> On 22.06.2022 15:43, Johan Hovold wrote: > >>>>>>> No, quite the opposite, status go at the end. >>>>>> Then all other device DTs should be updated, as in dts/qcom/ >>>>>> everybody keeps it first in non-SoC/PMIC files. >>>>> >>>>> The word "should" is a bit too much here, but I agree, we can update all >>>>> of them to match one, chosen approach. >>>>> >>>>> However the location for "status" property is more important for the >>>>> definition of nodes in DTSI, because it's the least important piece >>>>> there and also kind of expected - here go properties + I disable it. For >>>>> me this is more important. >>> >>> Right, and this is the argument for keeping status last, something which >>> is well defined. >>> >>> If you look at some of the qcom dtsi it's hard to determine whether a >>> node is disabled or not because the status property does not actually go >>> "first" but is rather typically mixed up somewhere in the middle (or >>> upper part) of nodes. >>> >>>>> For node redefinition in DTS, I see benefits in two approaches: >>>>> 1. Let me first enable the node and then configure it. >>>>> 2. Let me configure the node and enable it. >>> >>> So for consistency, just put status last everywhere (dtsi and dts) and >>> be done with it. >> That works. > > Actually, it looks like a lot of the qcom dtsi already do this too (i.e. > put status last). The dts may be more inconsistent on this matter > judging from a quick look. Yes, as I mentioned this concerns the device-specific trees, as the includable ones are (or well, should have been made) fine. Konrad > >>>> I looked around non-qcom device trees and it looks like the common >>>> consensus is 2. Although I personally visually prefer 1. and it's >>>> been used in all qcom arm64 DTs to date, I don't think there are any >>>> blockers for us to switch to 1. going forward to keep it consistent. >>> >>> You mean inconsistent with the majority of dts? ;) >> Not like anything involving Qualcomm was ever consistent or compliant >> with the majority :D > > Heh. :) > > Johan