Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
To:     Icenowy Zheng <icenowy@aosc.io>, Maxime Ripard <maxime@cerno.tech>
Cc:     devicetree@vger.kernel.org,
        Jernej Skrabec <jernej.skrabec@siol.net>,
        linux-sunxi@googlegroups.com, linux-kernel@vger.kernel.org,
        Chen-Yu Tsai <wens@csie.org>, Rob Herring <robh+dt@kernel.org>,
        linux-arm-kernel@lists.infradead.org
References: <20201107124958.2222253-1-icenowy@aosc.io>
 <20201107125332.2223197-1-icenowy@aosc.io>
 <20201110103925.rbej5ueo2fefbmlp@gilmour.lan>
 <6175E674-E8BC-4199-8BE8-A983065C32D5@aosc.io>
 <20201116155508.364dg6ycklwylswe@gilmour.lan>
 <8FFC1A6C-9CA4-4F94-91C4-F111A7519979@aosc.io>
 <20201120155939.3ajmbny2pka2vsnf@gilmour>
 <A8E91BA0-22FD-47F4-A5B2-A80A38FE9A0E@aosc.io>
From:   Samuel Holland <samuel@sholland.org>
Subject: Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT
 for PineTab developer sample
Message-ID: <38ee5feb-e35d-801f-99a1-65e23618e73b@sholland.org>
Date:   Fri, 20 Nov 2020 20:51:48 -0600
User-Agent: Mozilla/5.0 (X11; Linux ppc64; rv:78.0) Gecko/20100101
 Thunderbird/78.4.0
MIME-Version: 1.0
In-Reply-To: <A8E91BA0-22FD-47F4-A5B2-A80A38FE9A0E@aosc.io>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

Maxime,

On 11/20/20 5:30 PM, Icenowy Zheng wrote:
>>>>>>> +/ {
>>>>>>> +	model = "PineTab Developer Sample";
>>>>>>> +	compatible = "pine64,pinetab-dev", "allwinner,sun50i-a64";
>>>>>>> +};
>>>>>>
>>>>>> Changing the DT and the compatible half-way through it isn't ok. Please
>>>>>> add a new DT with the newer revision like we did for the pinephone
>>>>>
>>>>> We did this on Pine H64.
>>>>
>>>> What are you referring to? I couldn't find a commit where we did what
>>>> you suggested in that patch to the pine H64.
>>>
>>> Oh the situation is complex. On Pine H64, we didn't specify anything at
>>> start (which is the same here), the DT is originally version-neutral
>>> but then transitioned to model B, then reverted to model A. Here the DT is always
>>> for the sample.
>>>
>>> However, for Pine H64 there's model A/B names, but for PineTab there's no
>>> any samples that are sold, thus except who got the samples, all PineTab
>>> owners simply owns a "PineTab", not a "PineTab xxx version".
>>
>> It's fairly simple really, we can't really predict the future, so any DT
>> submitted is for the current version of whatever board there is. This is

I don't think that was the intention at all. The DT was submitted for a
future product, whatever that future product ends up being at the time
of its release. Since there are necessarily no users until the product
ships, there is no chance of breaking users by modifying the DT.

>> what we (somewhat messily) did for the PineH64, for the pinephone, or
>> really any other board that has several revisions

Surely a non-public prototype doesn't count as a separate revision! This
sort of policy strongly discourages ever shipping a board with
out-of-the-box mainline Linux support. Because if there any hardware
bugs fixed between initial upstreaming and production, the manufacture
must come up with a new DT name.

This is hostile to the users as well, because the "canonical" DT name no
longer matches the "canonical" (read: the only one ever available)
version of the hardware.

Do you want manufacturers to submit their initial board DT as
"$BOARD-prototype.dts", just in case they have to make a change before
production? And only after the board is shipped (with out-of-tree
patches, of course, to use $BOARD.dts, since the shipped board is *not*
the prototype) submit a "$BOARD.dts" to mainline?

Maxime, can you clarify specifically what the line is where a device
tree is "locked down" and further changes to the hardware require a new
name? First sample leaves the factory? $NUMBER units produced? First
sold to the public for money?

Without some guidance, or a change in policy, this problem is going to
keep coming up again and again.

You'll note that so far it has mostly affected Pine devices, and I don't
think that's because they make more board revisions than other
manufacturers. It's because they're actively involved in getting their
boards supported upstream. For other manufacturers, it's some user
sending in a device tree months after the hardware ships to the public
-- of course the hardware is more stable at that point. I think Pine's
behavior is something we want to encourage, not penalize.

> Okay. But I'm not satisfied with a non-public sample occupies
> the pinetab name. Is rename it to pinetab-dev and add a
> pinetab-retail okay?
To me, naming the production version anything but "pinetab" isn't
satisfying either.

Samuel