Received: by 2002:ac0:950c:0:0:0:0:0 with SMTP id f12csp1810973imc; Tue, 12 Mar 2019 00:46:14 -0700 (PDT) X-Google-Smtp-Source: APXvYqy8ipeAVDWYoqDD9dEGphQrrp+IrNPfcHObJ4WWaTwhUPkJolCwRrT8hc0ixKMkQU40Xrha X-Received: by 2002:a65:4785:: with SMTP id e5mr13184284pgs.353.1552376774653; Tue, 12 Mar 2019 00:46:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552376774; cv=none; d=google.com; s=arc-20160816; b=qZpEoS0wzQk2qTwAeR0HRERonbI7BU8fL6wbAGkXJNftzcvS5OYPboo1GDMIdWm2Mj M2UeM2aSWNVMa5ECoyq45e8bB33mR+T7Z53Mny32Y1hlmtV3mSDswAok/wx4U33cLWMv e2l5E+AupfxC3vAN7XwlEGPH5wv3mTL28OZJWmJw0aNIn5C+cwbgmSjNVWRAxt71upep ZeesRK8DJSADWSL9ShMTGYfPn64i6xYFUuVh69PXKTihG5zvxYq/tKYfv5AjL6qIG839 WXXulS5xyKwD9NLRkGu9hyuiRIVvq19xJzH950oUej1JhgW99aC61uo+Se+Ia3bPRKqq o9+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=3JgoRiesFvxI9ZpaCSO/CHfPPp7IXn61ax0MXCxcmDY=; b=PaPLvqIWVbbQHLNbj7Pf2FtYuv5Px+PDJKgtfyhaN6E3bTL0Gx33uqmr7r0iSMUz7c esDvLe4sPS8UFByn8y0Iz1AOYF+oXzHl+slOTHDHUSXMRSZ/hWrUWhKB3u9SfAnueE0k 6drJp29GWSeZ3E4Fin0ShOU4HPD4Kj9HW1OLgSFo0s4B0/O+CuemUarTePxMvhhW0llg m1uW9hD03Kc+3Gn5l3/RL8FJZO8WorWGjVVZYv81sT2qTg1E2sW+2E3L5ZOgX/wBqvSV QZqHB4ZxTwEJU3IxeqsdCDSzEapRC99Jd0OFQWZiIdQkyrOmsQQvAotAgPxEFdWREqDi w4XQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x8si7287620pll.101.2019.03.12.00.45.58; Tue, 12 Mar 2019 00:46:14 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727456AbfCLHnj (ORCPT + 99 others); Tue, 12 Mar 2019 03:43:39 -0400 Received: from pony.blueri.se ([163.172.214.9]:6454 "EHLO pony.blueri.se" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726714AbfCLHni (ORCPT ); Tue, 12 Mar 2019 03:43:38 -0400 X-Greylist: delayed 398 seconds by postgrey-1.27 at vger.kernel.org; Tue, 12 Mar 2019 03:43:38 EDT Received: from thor.local (p200300C1C7200A001155894A8088296E.dip0.t-ipconnect.de [IPv6:2003:c1:c720:a00:1155:894a:8088:296e]) by pony.blueri.se (OpenSMTPD) with ESMTPSA id 08f9ce1e (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO); Tue, 12 Mar 2019 08:36:57 +0100 (CET) Date: Tue, 12 Mar 2019 08:36:54 +0100 From: Patrick Wildt To: Stephen Boyd Cc: Abel Vesa , Fabio Estevam , Lucas Stach , Mark Rutland , Rob Herring , Sascha Hauer , Shawn Guo , dl-linux-imx , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Linux Kernel Mailing List Subject: Re: [PATCH] dt-bindings: clock: imx8mq: Fix numbering overlaps and gaps Message-ID: <20190312073654.GA85609@thor.local> References: <1551779342-2640-1-git-send-email-abel.vesa@nxp.com> <155181110921.20095.1641360339603928947@swboyd.mtv.corp.google.com> <20190306130941.dqf3swx66bchm5k2@fsr-ub1664-175> <155205894567.20095.2782332899458282059@swboyd.mtv.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <155205894567.20095.2782332899458282059@swboyd.mtv.corp.google.com> User-Agent: Mutt/1.11.3 (2019-02-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 08, 2019 at 07:29:05AM -0800, Stephen Boyd wrote: > It's mostly about making sure that any existing dtbs don't have their > numbers shifted around. So hopefully any overlapping identifiers aren't > in use yet and then those ids can be changed while leaving the ones that > are in use how they are. In practice I bet no one uses Linux 5.0's i.MX8M device trees since they lack too much support. It's so basic it's not useful. You'd still run your existing non-mainline bindings until it is. Thus I would argue changing the ABI right now would be the only chance there is. If you think that chance is gone, then I guess the reasonable thing is to keep the numbers and only move those (to the end) which overlap. Or put them into that erreneous number gap. Patrick