Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp761028pxu; Mon, 23 Nov 2020 03:34:06 -0800 (PST) X-Google-Smtp-Source: ABdhPJzstqoQOjfRUcTPkYHfavBhK7Tpu/4z/IMvsJPy9BMlsnDCmQhGIsBaOw7isaPe/8LTj7jz X-Received: by 2002:a05:6402:3089:: with SMTP id de9mr48007702edb.100.1606131246574; Mon, 23 Nov 2020 03:34:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606131246; cv=none; d=google.com; s=arc-20160816; b=n53hObkmjt6sWXJxRgKb1hqj0BboF8lnddD5yIZi5vCx6lb2ZJ6wMajTgKXMbAqqms xgtpTxU63+gb4Yh1wJ7D9KW27D/tyeUloDSboQyzctOHld6qHl2GJ71KU7KCWyS6F9eF cJeMoDvBSixzQz+uhEub8arfjg04dzAcd3NgIvjpRyptjWa4knBT+/4CtCxUtHdzv+SS XzE6EP4qPpQ6bAEw4dV5eQM5Um+LrtCJ11zqMzcm2pxo6dCpzDP9iPs0WziI5H2pZkRw VYwXEAqhof8zqJconh6IrunJj+YVvIblqaLfJssPFQ03Hao60ZOrqMOlTCrICZw+9cPI gbXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:from:cc:to:subject :content-transfer-encoding:mime-version:references:in-reply-to :user-agent:date:dkim-signature:ai-spam-status:dkim-signature; bh=EIvAkk+Eww25cTksdYkesBMBZ4BuG/DufLbSBODdIAo=; b=wkDgpfBfyFHA0Y6rNNR6qSl/ZqUHsIItuW3FSGwsjlCuM7ukD9wygldVUseq7M4d6i M7jqd+vdz10XKcVuF725mp3FwvZHdgvbD6zAWnSKya9HUGq7NI6CGkmtvUsc+T0/HbY9 5JUsTL7L4aYYItQU7yTNCAMINNDbeW2CmxAHL+2ct0sukiEuYcPC6WJLzCBWDTwqLeCA 8UVJzD12ceORu+91XZD5++UyFuWVB57Q4T+TxuPUqaKyIgSONcgD9YwYRz9jwiVNeVJB 86pkmoJL1Ilfa06U0nK1oEXGuvLGK5oKsImvHqq7fDZlvla3kBpVyRRDACRI4llmnNjq 0Dhw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@mymailcheap.com header.s=default header.b=B6vhuMdW; dkim=fail header.i=@aosc.io header.s=default header.b=lyMExo4b; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j11si6365991edy.158.2020.11.23.03.33.44; Mon, 23 Nov 2020 03:34:06 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=fail header.i=@mymailcheap.com header.s=default header.b=B6vhuMdW; dkim=fail header.i=@aosc.io header.s=default header.b=lyMExo4b; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728795AbgKWLcD (ORCPT + 99 others); Mon, 23 Nov 2020 06:32:03 -0500 Received: from relay1.mymailcheap.com ([144.217.248.100]:56180 "EHLO relay1.mymailcheap.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728484AbgKWLcC (ORCPT ); Mon, 23 Nov 2020 06:32:02 -0500 Received: from filter2.mymailcheap.com (filter2.mymailcheap.com [91.134.140.82]) by relay1.mymailcheap.com (Postfix) with ESMTPS id 88CE13F1C5; Mon, 23 Nov 2020 11:31:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by filter2.mymailcheap.com (Postfix) with ESMTP id CF8702A510; Mon, 23 Nov 2020 12:31:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mymailcheap.com; s=default; t=1606131118; bh=z2fP8/PSzCbXQO+A7KEq/k6IkIhE9a9AlAXvgrcy00s=; h=Date:In-Reply-To:References:Subject:To:CC:From:From; b=B6vhuMdWdP9wsSZgmlRQevk04PMtfJ+0OcNiqbivXmtNUCVrU3/w1jxI2RaSHAOoh z16KsiFeUC2tjayKf9NhULxUWkcDFznnnX6TVTBeNNblFFK2W5As2la/uAxyLA8o0u hrQ3uMygN6Fa8ywwIBJM31NjlozjMrEqoSDC2Xzg= X-Virus-Scanned: Debian amavisd-new at filter2.mymailcheap.com Received: from filter2.mymailcheap.com ([127.0.0.1]) by localhost (filter2.mymailcheap.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qH8IYop_XnE2; Mon, 23 Nov 2020 12:31:57 +0100 (CET) Received: from mail20.mymailcheap.com (mail20.mymailcheap.com [51.83.111.147]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by filter2.mymailcheap.com (Postfix) with ESMTPS; Mon, 23 Nov 2020 12:31:57 +0100 (CET) Received: from [148.251.23.173] (ml.mymailcheap.com [148.251.23.173]) by mail20.mymailcheap.com (Postfix) with ESMTP id 98EC341A21; Mon, 23 Nov 2020 11:31:56 +0000 (UTC) Authentication-Results: mail20.mymailcheap.com; dkim=pass (1024-bit key; unprotected) header.d=aosc.io header.i=@aosc.io header.b="lyMExo4b"; dkim-atps=neutral AI-Spam-Status: Not processed Received: from [172.19.0.1] (unknown [64.225.114.122]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail20.mymailcheap.com (Postfix) with ESMTPSA id E2CE941AB7; Mon, 23 Nov 2020 11:31:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aosc.io; s=default; t=1606131105; bh=z2fP8/PSzCbXQO+A7KEq/k6IkIhE9a9AlAXvgrcy00s=; h=Date:In-Reply-To:References:Subject:To:CC:From:From; b=lyMExo4boAj3+Han0w1w36pOh5BCTQ6Ic8ka+eWCL2YpfVX1taurn/y2tS24yu19+ 5aJ34mN7FR75YAXhumOkVg/6Q/5WRGc23sHK49RpNhobwD5/9AknB9He2Suznv+02y P7GuDezxZ6e6gaXZKWlK20Xq/kzjhX+mWXD5jE9M= Date: Mon, 23 Nov 2020 19:25:47 +0800 User-Agent: K-9 Mail for Android In-Reply-To: <20201123111512.y7lbwsipbkcpuleb@gilmour> 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> <38ee5feb-e35d-801f-99a1-65e23618e73b@sholland.org> <20201123111512.y7lbwsipbkcpuleb@gilmour> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample To: Maxime Ripard , Samuel Holland CC: devicetree@vger.kernel.org, Jernej Skrabec , linux-sunxi@googlegroups.com, linux-kernel@vger.kernel.org, Chen-Yu Tsai , Rob Herring , linux-arm-kernel@lists.infradead.org From: Icenowy Zheng Message-ID: <97E2037C-3C3C-4B0B-8462-39B9E38CB3BB@aosc.io> X-Rspamd-Queue-Id: 98EC341A21 X-Spamd-Result: default: False [1.40 / 10.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(0.00)[aosc.io:s=default]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TAGGED_RCPT(0.00)[dt]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[aosc.io]; R_SPF_SOFTFAIL(0.00)[~all]; ML_SERVERS(-3.10)[148.251.23.173]; DKIM_TRACE(0.00)[aosc.io:+]; RCPT_COUNT_SEVEN(0.00)[9]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:148.251.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; SUSPICIOUS_RECIPS(1.50)[]; HFILTER_HELO_BAREIP(3.00)[148.251.23.173,1] X-Rspamd-Server: mail20.mymailcheap.com Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org =E4=BA=8E 2020=E5=B9=B411=E6=9C=8823=E6=97=A5 GMT+08:00 =E4=B8=8B=E5=8D=88= 7:15:12, Maxime Ripard =E5=86=99=E5=88=B0: >Hi! > >On Fri, Nov 20, 2020 at 08:51:48PM -0600, Samuel Holland wrote: >> On 11/20/20 5:30 PM, Icenowy Zheng wrote: >> >>>>>>> +/ { >> >>>>>>> + model =3D "PineTab Developer Sample"; >> >>>>>>> + compatible =3D "pine64,pinetab-dev", "allwinner,sun50i-a64"; >> >>>>>>> +}; >> >>>>>> >> >>>>>> Changing the DT and the compatible half-way through it isn't >ok=2E Please >> >>>>>> add a new DT with the newer revision like we did for the >pinephone >> >>>>> >> >>>>> We did this on Pine H64=2E >> >>>> >> >>>> What are you referring to? I couldn't find a commit where we did >what >> >>>> you suggested in that patch to the pine H64=2E >> >>> >> >>> Oh the situation is complex=2E 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=2E Here >the DT is always >> >>> for the sample=2E >> >>> >> >>> 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"=2E >> >> >> >> 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=2E >This is >>=20 >> I don't think that was the intention at all=2E The DT was submitted for >a >> future product, whatever that future product ends up being at the >time >> of its release=2E Since there are necessarily no users until the >product >> ships, there is no chance of breaking users by modifying the DT=2E > >There was no indication of that in the commit though > >> >> what we (somewhat messily) did for the PineH64, for the pinephone, >or >> >> really any other board that has several revisions >>=20 >> 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=2E Because if there any hardware >> bugs fixed between initial upstreaming and production, the >manufacture >> must come up with a new DT name=2E >>=20 >> 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=2E >>=20 >> Do you want manufacturers to submit their initial board DT as >> "$BOARD-prototype=2Edts", 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=2Edts, since the shipped board is >*not* >> the prototype) submit a "$BOARD=2Edts" to mainline? >>=20 >> 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? > >The first board that is shipped to a user=2E From the wiki, the version >supported here (I guess?) has been shipped to around 100 people, so it >doesn't really qualify for the "non-public prototype"=2E We still have to >support these users, whether we like it or not=2E > >> Without some guidance, or a change in policy, this problem is going >to >> keep coming up again and again=2E > >There's a few things that are interleaved here=2E First, there's two hard >rules: never change the DT name and never change the compatible of a >board=2E > >The former would break any build system, boot script or documentation, >and the latter would break the DT compatibility=2E > >Aside from this, things get a bit blurrier since it's mostly about the >intent=2E I'm fine with having a DT for a non-public prototype if it's >clear from day one that it is=2E In this particular case, the DT just >stated that support for the pinetab was added=2E I guess anyone would >make >the assumption without any context that this would be for the (or a) >final design=2E > >Finally, I'd also advise against submitting the parts that are still >not >finalized though, because this is also fairly bad for the users=2E Let's >take the current situation as the example: from what I understand, the >screen changed half-way through the process, and the first one was >upstreamed=2E This means that any user that would use a kernel with that >bugfix would have the display working, while rolling back to 5=2E9 would >break the display, even though everyone claimed it was supported >out-of-the-box in mainline=2E This is a worse situation than not >supporting the display in the first place here=2E > >> 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=2E > >Yes definitely=2E Pine devices may be worse though because of their >policy >of making their prototypes public=2E I guess most of the issues we had >also were due to poor communication: context on what were the Pine >intentions were missing, and thus we couldn't catch things that turned >out to be bad later on during review=2E > >> It's because they're actively involved in getting their >> boards supported upstream=2E 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=2E > >I mean, it's not black and white either=2E One could very well send the >DT >once the final design is done and that would still be upstreamed way >before reaching the first user=2E > >> I think Pine's behavior is something we want to encourage, not >> penalize=2E > >For the DT in particular, yes > >> > Okay=2E But I'm not satisfied with a non-public sample occupies >> > the pinetab name=2E 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=2E > >I understand where you're coming from, but the point I was making my >previous mail is precisely that it's not really possible=2E > >You want to name the early adopter version _the_ production version=2E >Let's assume the hardware changes again between the early adopter and >mass-production version=2E Which one will be _the_ production version? >The >early-adopter or the mass-produced one? > >There's really no good answer here, and both would suck in their own >way=2E The only way to deal with this is to simply avoid defining one >version as the one true board, and just loading the proper DT in u-boot >based on whatever clue we have of the hardware revision=2E Then will it be okay to rename current pinetab DT to pinetab-sample and then introduce new DTs all with suffixes? > >Maxime