Message-ID: <CAODwPW857CkH0+ZnBaUeowW4te-hSy6nrdeeX6-OLPOs5TptsQ@mail.gmail.com>
Date:   Tue, 10 May 2022 19:39:41 -0700
From:   Julius Werner <jwerner@...omium.org>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     Doug Anderson <dianders@...omium.org>,
        Krzysztof Kozłowski <k.kozlowski.k@...il.com>,
        Mars Chen <chenxiangrui@...qin.corp-partner.google.com>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
        Julius Werner <jwerner@...omium.org>
Subject: Re: [PATCH] CHROMIUM: arm64: dts: qcom: Add sc7180-gelarshie

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

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

> 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? My understanding
was that Linux tries to support a wide variety of platforms and
devices and can make the necessary compromises where needed to stay
practical. I'm sure you are aware of the numerous hacks, workarounds
and special cases throughout the kernel that enthusiasts put in there
to get their favorite platform working, even if the original
manufacturer never bothered to test with anything but Windows and
blatantly violates common standards. Or how the USB stack has a file
listing custom quirks for hundreds of individual device IDs just to
make hardware work that didn't put any effort into following the spec.

We're not even asking for any of that -- we're here, engaging with you
and trying to find the best way for our platforms to fit cleanly into
your model. All we're asking is to please offer some way that makes
accommodations for the necessary practical concerns that come up when
building devices at our scale. We're open for new suggestions, but
they need to stay within the realm of what we can practically do (e.g.
not ship a wholly separate DTB for each board revision, because that
would grow the kernel image beyond what can fit in the kernel
partitions on our platforms, and would create a notable extra cost in
boot time for our users).

Besides, I don't actually see how this violates the Device Tree
specification? All I see it say about the toplevel compatible property
is that it

> Specifies a list of platform architectures with which this platform is compatible. This property can be used by operating systems in selecting platform specific code.

It doesn't say anything about having to uniquely identify the platform
architecture even if a more generic identifier is good enough to make
all necessary platform-specific code choices for the operating system.
In fact, about compatible properties in general the specification says

> The property value consists of a concatenated list of null terminated strings, from most specific to most general. They allow a device to express its compatibility with a family of similar devices, potentially allowing a single device driver to match against several devices.

Which implies that using a more generic string to cover multiple cases
at once is an intentionally allowed use case.

Powered by blists - more mailing lists