linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Samuel Holland <samuel@sholland.org>
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
Subject: Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample
Date: Fri, 20 Nov 2020 20:51:48 -0600	[thread overview]
Message-ID: <38ee5feb-e35d-801f-99a1-65e23618e73b@sholland.org> (raw)
In-Reply-To: <A8E91BA0-22FD-47F4-A5B2-A80A38FE9A0E@aosc.io>

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-11-21  2:53 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-07 12:49 [PATCH 0/3] Switch PineTab DT LCD panel to retail one Icenowy Zheng
2020-11-07 12:50 ` [PATCH 1/3] arm64: allwinner: dts: a64: pinetab: switch LCD panel to production one Icenowy Zheng
2020-11-07 12:52 ` [PATCH 2/3] dt-bindings: arm: sunxi: add PineTab developer sample DT binding Icenowy Zheng
2020-11-09 22:02   ` Rob Herring
2020-11-07 12:53 ` [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample Icenowy Zheng
2020-11-10 10:39   ` Maxime Ripard
2020-11-10 10:41     ` Icenowy Zheng
2020-11-16 15:55       ` Maxime Ripard
2020-11-16 18:36         ` [linux-sunxi] " Icenowy Zheng
2020-11-20 15:59           ` Maxime Ripard
2020-11-20 23:30             ` Icenowy Zheng
2020-11-21  2:51               ` Samuel Holland [this message]
2020-11-23 11:15                 ` Maxime Ripard
2020-11-23 11:25                   ` Icenowy Zheng
2020-11-23 12:53                     ` Maxime Ripard
2020-11-23 13:10                       ` Icenowy Zheng
2020-11-28 10:38                         ` Maxime Ripard
2020-11-28 11:28                           ` Icenowy Zheng
2020-11-28 11:54                             ` Clément Péron
2020-11-28 11:59                               ` Icenowy Zheng
2020-11-28 21:07                                 ` Clément Péron
2020-12-01 10:35                                   ` Maxime Ripard
2020-12-06 21:03                                     ` Clément Péron
2020-12-07 10:07                                       ` Maxime Ripard

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=38ee5feb-e35d-801f-99a1-65e23618e73b@sholland.org \
    --to=samuel@sholland.org \
    --cc=devicetree@vger.kernel.org \
    --cc=icenowy@aosc.io \
    --cc=jernej.skrabec@siol.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sunxi@googlegroups.com \
    --cc=maxime@cerno.tech \
    --cc=robh+dt@kernel.org \
    --cc=wens@csie.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;
as well as URLs for NNTP newsgroup(s).