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;
Message-ID: <55dcf917-7ac0-efe9-8531-b77be682125a@linaro.org>
Date:   Wed, 11 May 2022 09:20:41 +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:     Julius Werner <jwerner@chromium.org>
Cc:     Doug Anderson <dianders@chromium.org>,
        =?UTF-8?Q?Krzysztof_Koz=c5=82owski?= <k.kozlowski.k@gmail.com>,
        Mars Chen <chenxiangrui@huaqin.corp-partner.google.com>,
        Andy Gross <agross@kernel.org>,
        Bjorn Andersson <bjorn.andersson@linaro.org>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzk+dt@kernel.org>,
        linux-arm-msm <linux-arm-msm@vger.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>
References: <20220330090947.9100-1-chenxiangrui@huaqin.corp-partner.google.com>
 <a0eb6bf9-256a-29b1-2211-496df710f531@linaro.org>
 <CAD=FV=UjyLofXZqnj=bL89fza5JS6O5Np9W-A4V4WK+na0hdrw@mail.gmail.com>
 <b7ff08b8-60fb-7629-9399-3d5cca46ab9e@linaro.org>
 <CAD=FV=Vx5g_xTRZGc9wW=ZLnfsOcubTYFcnYQRC5jLm+n3en0w@mail.gmail.com>
 <606cc762-a0c2-49a4-3e5d-d2dbd4595bc7@linaro.org>
 <CAD=FV=W_SA-3PfDFi-Gkjk9pew5bchFNjQhXX8MkZyuy5UohEQ@mail.gmail.com>
 <CAJKOXPdt5WTg4VU-TEW3dmPHR76dKg63XVxRQfa7ZSKc_jz6Ag@mail.gmail.com>
 <CAD=FV=XQqQSQDNh-zXqEQkwsrax5Qb3OtfKZoQLkncJj_4mcQw@mail.gmail.com>
 <daf66d41-42ac-50dc-3f8d-c261da8e452d@linaro.org>
 <CAD=FV=WhA=n_=Ys6NfedPtNPddL81HnG6Qws_R+vq9w8Nrsn5A@mail.gmail.com>
 <ce2ea308-b63d-ad27-4cea-7353268f8ebb@linaro.org>
 <CAODwPW857CkH0+ZnBaUeowW4te-hSy6nrdeeX6-OLPOs5TptsQ@mail.gmail.com>
From:   Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
In-Reply-To: <CAODwPW857CkH0+ZnBaUeowW4te-hSy6nrdeeX6-OLPOs5TptsQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 11/05/2022 04:39, Julius Werner wrote:
>> Wait, we agreed that you don't consider them identical, didn't we? If
>> they are identical, you do not need rev4 at all. So they are not
>> identical...
> 
> Well, they are identical until they're not. We intend them to be
> identical. But for practical purposes it does sometimes happen that
> two board revisions which were meant to be indistinguishable by
> software end up needing to be distinguished at a later point, when
> both the hardware and firmware can no longer be changed. We need to
> allow an escape hatch for that case. It does not happen often, so just
> treating them all as separate boards from the start is not a scalable
> solution. DTBs are not free when they all need to be packaged in the
> same kernel image.

You split more important part of my message, ignoring the point.

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.

> 
>> 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.

> 
>> Remember, you do not have to use Devicetree or Linux at all if it causes
>> you some downsides... No one is forced. :) If you choose to use it,
>> sorry, it comes with some requirements like being following Devicetree
>> specification or the binding guidelines.
> 
> Woah... that is maybe a bit extreme, don't you think? 

Yes, it was sarcasting. :) But yeah, using Linux and DTS comes now with
DT schema. Please document the bindings in DT schema. That's the
drawback of using mainline...


Best regards,
Krzysztof