From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EB283C63697 for ; Sat, 28 Nov 2020 10:40:32 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8B45B22314 for ; Sat, 28 Nov 2020 10:40:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="EA9yJYdH"; dkim=temperror (0-bit key) header.d=cerno.tech header.i=@cerno.tech header.b="nubncwe+"; dkim=temperror (0-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="IQ6G7L4l" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8B45B22314 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cerno.tech Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=AtrALE7aNlh3LBSl2P2Tl+UWvfrIINyLuzTOvqxhIiM=; b=EA9yJYdHnDyyxT7VCpXuckDWs zygDDTxb1d7mN3N2pWoiHPOa7O+NauC+MlDQ0/vnV3TDwoUV9T2+z9kN8WEpiEETtG7v52t1iLz2E BBLQHpYzQitOhSXHxApd6HmRbssqqnsgF0F00szcdXAud5HyT0XQiR2a13WwK3wScRFb2EHhROD+H /pUSSXih+GyBnajmX2O9GFLhV/8Sbx9TTKPVBwFgo//pmxHDB3+Vxh57W9znO0wl1eCty3JRcjB2F gswkvlSy6ohBlNoBaPuSLezivdDEWSGZs1mnQknyYbN/FbG3WXk/hHTUQicDUEO3xtvlgjthRLV1d 30ntKtDpw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kixcp-0007Z7-Kt; Sat, 28 Nov 2020 10:38:43 +0000 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kixcl-0007Xn-9L for linux-arm-kernel@lists.infradead.org; Sat, 28 Nov 2020 10:38:41 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id DB920C0C; Sat, 28 Nov 2020 05:38:30 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Sat, 28 Nov 2020 05:38:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=a6k8h7G8DbGWnMKaT2VTyNF8NDZ ouXZ50EDpqHXOUU0=; b=nubncwe+PToM4qt1WkE4kZ3UpKtInXR5GXjcTcl1JiZ YsBLwGE7NBlXsBStGoOCmV8ICqLoplLj7GJXU9zU0xNGve/S3ci379avO3qB8SeO N7zk4ZMDfMjksFtzbehisI/gntkZCoTawoRfwD4cT4k7n0rB8ZGmONEh8z9oxvpe 3EUelJ8MKeuGzFH2rdx9uwzAjrgK2sJ7yLYTZR8Dp8tDNqZJQhbqIfEWgIKiZ9VA ZEAGK5hgt/s8intBN5gdpR8Fm7F1GYXRCuqjgNAB92r5iMYq2OOl8sEj/AJIiLKr VeFC3JGSrWgw3ukZNs5PsvE2zCT02XPcREsPVcWpdXw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=a6k8h7 G8DbGWnMKaT2VTyNF8NDZouXZ50EDpqHXOUU0=; b=IQ6G7L4lPz+emL/XcxljQs eK3gnZfkJJR5/CVEbNqTW9zsQsLogokMmoFUMbYBYKaL/8WAP12krwQ1c0sJeaaU UzJrqiHbKKR/hItG9QX4LrDpYdcryZhobt6n8uEBFaRMhorDHCCFOFREmTAFpnmF 83aTiKTVp7zxchkZWEFvblB05ilvO7sndhN9/ZD0J2n16WB/AJut4R0OcXhDq18y K/RsWIH/mZ1SEQPS5zUKfjRxFSjGX7NUV27haVLAutve5WdliQah9HqwMq8i2YS6 EliDJvkFKz0zK1YNqH2uLI9W2N2Cpd5hr2UGilm9k4C7RyRY3cE6WrsY678uThiw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudehiedgudekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpeforgigihhm vgcutfhiphgrrhguuceomhgrgihimhgvsegtvghrnhhordhtvggthheqnecuggftrfgrth htvghrnhepleekgeehhfdutdeljefgleejffehfffgieejhffgueefhfdtveetgeehieeh gedunecukfhppeeltddrkeelrdeikedrjeeinecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepmhgrgihimhgvsegtvghrnhhordhtvggthh X-ME-Proxy: Received: from localhost (lfbn-tou-1-1502-76.w90-89.abo.wanadoo.fr [90.89.68.76]) by mail.messagingengine.com (Postfix) with ESMTPA id 7728E3064AB2; Sat, 28 Nov 2020 05:38:29 -0500 (EST) Date: Sat, 28 Nov 2020 11:38:27 +0100 From: Maxime Ripard To: Icenowy Zheng Subject: Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample Message-ID: <20201128103827.d6sfc2eumli2betx@gilmour> References: <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> <97E2037C-3C3C-4B0B-8462-39B9E38CB3BB@aosc.io> <20201123125332.2p5z3ew7svszvyfs@gilmour> <009A22D9-AF20-45C4-9674-13334B3EFFBA@aosc.io> MIME-Version: 1.0 In-Reply-To: <009A22D9-AF20-45C4-9674-13334B3EFFBA@aosc.io> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201128_053840_038607_8BA830F2 X-CRM114-Status: GOOD ( 21.33 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, Jernej Skrabec , Samuel Holland , linux-sunxi@googlegroups.com, linux-kernel@vger.kernel.org, Chen-Yu Tsai , Rob Herring , linux-arm-kernel@lists.infradead.org Content-Type: multipart/mixed; boundary="===============7469435577382693963==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============7469435577382693963== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rmpcrvovirbkiyir" Content-Disposition: inline --rmpcrvovirbkiyir Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 23, 2020 at 09:10:38PM +0800, Icenowy Zheng wrote: > >> >> > 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. > >> > > >> >I understand where you're coming from, but the point I was making my > >> >previous mail is precisely that it's not really possible. > >> > > >> >You want to name the early adopter version _the_ production > >> >version. Let's assume the hardware changes again between the early > >> >adopter and mass-production version. 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. 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. > > > > > Then will it be okay to rename current pinetab DT to > > > pinetab-sample and then introduce new DTs all with suffixes? > > > > No. From my previous mail: >=20 > It can be seen as dropping the PineTab DT and introduce new DTs with > suffix. >=20 > Do we have rule that we cannot drop boards? Are you really arguing that removing a DT and then adding an identical one under a different name is not renaming it? --rmpcrvovirbkiyir Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCX8IoowAKCRDj7w1vZxhR xUVQAP9w4zKVWYrg14myVhyPLb+tvoKG3yXY0Mm7bfZ1HUpu4gD/Xku3FSK3YUYw azv2bYxaZ+A0ewygD1XDiQwVsLHGsw0= =em7W -----END PGP SIGNATURE----- --rmpcrvovirbkiyir-- --===============7469435577382693963== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============7469435577382693963==--