Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp1122754iob; Thu, 12 May 2022 11:37:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyZh0z0svn+TRdLPvX6im2Nq+uDRfwcUNecuejMH0D/4ZpiqNjJi4WR1Doo6Fy3s5dLQFDt X-Received: by 2002:aa7:c58e:0:b0:425:b5e3:6c51 with SMTP id g14-20020aa7c58e000000b00425b5e36c51mr37012828edq.99.1652380625968; Thu, 12 May 2022 11:37:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652380625; cv=none; d=google.com; s=arc-20160816; b=PPFIdLHPhRYqZEIYHViMFMjzrdCcBMVUTR9OUU9MMdHMasB1/Xq/SmVZuCnCem9trH vnA6/oxVe6frvKFY1l2TcHqK+ZCIoXF3fd0xHPQLuzH3tcbtciLifC/Jw2pJjXvg7gWw zF/g1S7ZDWx0bfYlSerXLY+uDSig+esIgAHpUYOWtNOAkhJ6eMtuLTd9dj9V/XE03HwQ ZTuiyDMtI4SdS9VZaTFgFznGs+PzD2jZ5NtGgd1DXok3EjdJclAKsO7fZNqN62ILG5Is gPIlC5hNRLrp9V61qONPTseqsXfNGRNuenUEqlQfuz4/5/5r1OdcUNtiWlBmkgsxmOZQ 9CsQ== 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:dkim-signature; bh=jwXHsUB6qUpzl3VRnWjzmQKSgk8cDfdgFA5s7nwGaLI=; b=n6SHjmB5GaFFYgBteHJetGDFptUaoehJ8N6dq6gpJ0qSLtdTME+ZO5yytbgYEDPNSD K11ZS7fN+nC/RoRrgJEk1G7jL7T+Vn0mXZW4Wku8v+YZyt7SaRSrJoSfwU6ILCV68KOW T7UQvTGk+cSaRNW61wcbBEkrciw/WdQ0D4SXEa1jkUefVekRtIJIybMzNMSXbpE9CDbP 2LPHP/ARk2VlUSXbTxgg4o4QarPmKK5see51e6J66LGghQ9kK841t+5/ZNF+/Jmz6haJ 9YOArDw8XGHQKnbgnFf7GsHhf97WgWgaB+jtO90S9n+NNUszGO31RzhZQL/ScBfSAFqz HO9A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=bT22W7fD; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c12-20020a056402158c00b0041cc2ef4536si46661edv.554.2022.05.12.11.36.40; Thu, 12 May 2022 11:37:05 -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; dkim=pass header.i=@linaro.org header.s=google header.b=bT22W7fD; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344360AbiEKRg5 (ORCPT + 99 others); Wed, 11 May 2022 13:36:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34970 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234039AbiEKRg4 (ORCPT ); Wed, 11 May 2022 13:36:56 -0400 Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2289468300 for ; Wed, 11 May 2022 10:36:55 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id g23so3349769edy.13 for ; Wed, 11 May 2022 10:36:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=jwXHsUB6qUpzl3VRnWjzmQKSgk8cDfdgFA5s7nwGaLI=; b=bT22W7fDGAySEG7vBs4hb15DD4bL48uTSAqlVdi3MASn69ux2G7d6N/VKWbxFQeXzu IgyiHQ6LaCd+Jy6MC9n/t37uslzcQJdkPoDj5+cJEJKwpg5f0JFW2jRrHzzzLJkf9iT4 QtQSQUI6LtFE/fIizHPmL1xz0u3XWz12sCguANLoXC7jJDbOFe74dMAP5p6lDhtoGNwH DFbFezBtzeZP0nBg/lmOWq7iZL6At0YQIyWc6fyuUn3CK6qOaU17FXZxe0d/AgEW+9TG J7Jt47UJoYkfeT8yAPruPYcESKHLZfst00coEXtq0vevDQTAQYtBInbCq7t9qf1jIkXW U8mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=jwXHsUB6qUpzl3VRnWjzmQKSgk8cDfdgFA5s7nwGaLI=; b=kKfACVe6vDeYU3RUM9Dmgahks7ZyvTIqXf6R7rCK5h3TXmDarhcufn/zc666odA7FN sGpB0GVgWteXV9OeSKClVFGlCGEzebndKZKOAEW23164kdvDkL62OQ4WIMXsC0/9cLGO S2rACr21z6ypWRjKo0J6lZkJoN8MZTtcc3nqTD4GL6l3GxjFHZC0POiITkK1gD/GusWC Z/PQeiR2w7CkuU7t2HZBPnh3bCi2il6TMmBnzNgdJnCbM9dW472xqgay4DMgyftee6wZ bQ7viQfTUnpKmFhhCl4D1JKXX/IOyS2tg/EUiOpRCNnt1bjdUdiVnvWNUFA/rTLdIJ91 BymQ== X-Gm-Message-State: AOAM531VOe8Drjwnt95SR7T43XRnJgqsgg8gpCIf8vCb6KrwhbezAEGT fUwGiLWDo5HYIRwZe3tuTrrjJg== X-Received: by 2002:a05:6402:2078:b0:428:1071:d9b2 with SMTP id bd24-20020a056402207800b004281071d9b2mr31020035edb.302.1652290613620; Wed, 11 May 2022 10:36:53 -0700 (PDT) Received: from [192.168.0.155] (xdsl-188-155-176-92.adslplus.ch. [188.155.176.92]) by smtp.gmail.com with ESMTPSA id y8-20020a170906524800b006f3ef214d9esm1231008ejm.4.2022.05.11.10.36.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 May 2022 10:36:53 -0700 (PDT) Message-ID: Date: Wed, 11 May 2022 19:36:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH] CHROMIUM: arm64: dts: qcom: Add sc7180-gelarshie Content-Language: en-US To: Doug Anderson , Rob Herring Cc: Julius Werner , =?UTF-8?Q?Krzysztof_Koz=c5=82owski?= , Mars Chen , Andy Gross , Bjorn Andersson , Rob Herring , Krzysztof Kozlowski , linux-arm-msm , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , LKML References: <20220330090947.9100-1-chenxiangrui@huaqin.corp-partner.google.com> <606cc762-a0c2-49a4-3e5d-d2dbd4595bc7@linaro.org> <55dcf917-7ac0-efe9-8531-b77be682125a@linaro.org> From: Krzysztof Kozlowski In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham 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 11/05/2022 18:09, Doug Anderson wrote: >> >> So you choose they are not identical, fine. Why insisting on adding >> fallback compatible while not keeping bindings updated? Just don't add >> the compatible and work on rev3 or rev4. Doug even once wrote "_we don't >> know_ if -rev7 and -rev8 are compatible", so don't make them compatible. >> Don't add fallbacks or some generic unspecified front-compatibles and >> just work on revision. > > Somehow, it seems like we keep talking past each other here and it > feels like folks are getting upset and we're not moving forward. Maybe > the right way to make progress is to find some face-to-face time at a > future conference and sit in front of a white board and hash it out. > That being said: > > * Without changing our bootloader or having a big explosion in the > number of dts files, we really can't change our scheme. The best we > can do is document it. That's reasonable. > > * If we want to change our scheme, we'd need to sit down and come to > an agreement that satisfies everyone, if such a thing is possible. There is open CFP for ELCE 2022 (in Ireland). Maybe we could organize some session there? But we for sure would need Rob, so the arrangements should rather focus on him, not on my availability. > That would only be able to affect future boards. I would like to say that if you had bindings, then obviously we would not break them, but since there are no bindings... :) > We don't want to > change the bootloader dts loading scheme on old boards. Understood. >>>> Right now it's not possible to validate QCOM DTSes against DT bindings >>>> because they throw big fat warnings about undocumented top compatibles. >>>> This is a downside for us. >>> >>> But that's a solvable problem, right? As I understand, what Doug was >>> initially just asking was whether it made _sense_ to document all of >>> these... not that we couldn't do it. Then this whole thread went down >>> a rabbit hole of whether our compatible assignments are allowed in the >>> first place. If we can compromise on this discussion by just doing >>> whatever needs to be done to make the tool happy, I think(?) we can >>> provide that. >> >> None of recent patches from Chromium were doing it, even after >> complaining from my side, so why do you suddenly believe that it is >> "doable"? If yes, please start doing it and fix the DTSes which you >> already submitted without bindings. >> >> To remind - entire discussion started with Doug saying it is pure >> overhead for him. > > I mean, to be fair I said it _seems_ pure overhead and then said that > we could do it if it makes some tools happy. ...but before doing that, > I wanted to make sure it was actually valuable. I still have doubts > about the assertion that the most specific compatible is guaranteed to > uniquely identify hardware. So if the whole reason for doing this is > to make the validation tools happy and there's no other value, then at > least it's plausible to argue that the tools could simply be fixed to > allow this and not shout about it. Instead of adding bindings, you can indeed change/fix the tools. Go ahead. :) > Now, certainly I'm not arguing that > yaml validation in general is useless. I'm in agreement that we want > dts files to be able to be formally validated because it catches > typos, missing properties, and bugs. I am _only_ saying that I still > haven't seen a good argument for why we need to validate the top-level > compatible string. I don't feel expert enough on this topic to give you good answer. Which does not prove that there isn't or there is such good answer. > Since there no properties associated with the > top-level compatible string, it's mostly just checking did some one > copy-paste the compatible string from one file (the dts file) to the > other file (the yaml file) correctly. To me, that does not feel like a > useful check. Still it can detect messing of SoC compatibles or not defining any board-level compatible thus pretending that someone's board is just SC7180. Imagine now user-space or bootloader trying to parse it... BTW, the bindings validation of top-level compatible might actually help you - to be sure that DTSes have proper compatibles matching what bootloader expects. > The other thing I wanted to make sure was that we weren't just going > to get NAKed later if/when we had to adjust compatible strings on > existing dts files. Stable ABI is more of SoC maintainer decision and I see Bjorn responded here. > In any case, I guess I'll make an attempt to document the compatibles > for existing Chromebooks and we'll see what happens. I'm still not > convinced of the value, but as long as we're not going to get NAKed > for documenting reality it's fine. Best regards, Krzysztof