mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Julius Werner <jwerner@chromium.org>
Cc: "Doug Anderson" <dianders@chromium.org>,
	"Krzysztof Kozłowski" <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>
Subject: Re: [PATCH] CHROMIUM: arm64: dts: qcom: Add sc7180-gelarshie
Date: Wed, 11 May 2022 09:20:41 +0200	[thread overview]
Message-ID: <55dcf917-7ac0-efe9-8531-b77be682125a@linaro.org> (raw)
In-Reply-To: <CAODwPW857CkH0+ZnBaUeowW4te-hSy6nrdeeX6-OLPOs5TptsQ@mail.gmail.com>

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

  reply	other threads:[~2022-05-11  7:21 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-30  9:09 Mars Chen
2022-03-30 14:21 ` kernel test robot
2022-03-30 17:16 ` Matthias Kaehlcke
2022-03-30 17:23   ` Krzysztof Kozlowski
2022-03-30 22:57   ` Rob Clark
2022-03-30 17:25 ` Krzysztof Kozlowski
2022-04-13 21:48   ` Doug Anderson
2022-04-14  7:10     ` Krzysztof Kozlowski
2022-04-14 17:36       ` Doug Anderson
2022-04-19 15:47         ` Krzysztof Kozlowski
2022-04-19 16:55           ` Doug Anderson
2022-05-03 15:53             ` Krzysztof Kozłowski
2022-05-03 16:13               ` Doug Anderson
2022-05-04  7:04                 ` Krzysztof Kozlowski
2022-05-04 23:56                   ` Julius Werner
2022-05-06 21:33                   ` Doug Anderson
2022-05-07 17:04                     ` Krzysztof Kozlowski
2022-05-07 17:11                       ` Krzysztof Kozlowski
2022-05-11  2:39                       ` Julius Werner
2022-05-11  7:20                         ` Krzysztof Kozlowski [this message]
2022-05-11 16:09                           ` Doug Anderson
2022-05-11 16:57                             ` Bjorn Andersson
2022-05-11 17:36                             ` Krzysztof Kozlowski
2022-05-11 17:49                               ` Doug Anderson
2022-05-12 16:08                                 ` Doug Anderson
2022-03-30 19:17 ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55dcf917-7ac0-efe9-8531-b77be682125a@linaro.org \
    --to=krzysztof.kozlowski@linaro.org \
    --cc=agross@kernel.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=chenxiangrui@huaqin.corp-partner.google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=jwerner@chromium.org \
    --cc=k.kozlowski.k@gmail.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®