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=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 1A336C4741F for ; Fri, 2 Oct 2020 10:36:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B1B42206A1 for ; Fri, 2 Oct 2020 10:36:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1601634983; bh=ZMeifx5F9dGyH+DIPFpumywg9Om9FjyKpFqPIYbHNAo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=upOayVP30k7fLEkR9OHAYR0ic0hJjcA66DXNZIjMMR1DFTEUu/9bu+B7ocYJWy9We Zv8Y4LveXWJPvyy00D7Cbi5hOsVzq7CLGv8xFzpP6LdSosIV9bli9/2+GcCXgSb0d3 O/688H40TpxS11fUb/k69y8/Pmxn+q2mf39sVSfw= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387762AbgJBKgW (ORCPT ); Fri, 2 Oct 2020 06:36:22 -0400 Received: from mail-ej1-f68.google.com ([209.85.218.68]:36136 "EHLO mail-ej1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725993AbgJBKgU (ORCPT ); Fri, 2 Oct 2020 06:36:20 -0400 Received: by mail-ej1-f68.google.com with SMTP id qp15so1279510ejb.3; Fri, 02 Oct 2020 03:36:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=dDy3qtZ35E/i8OLAIFoon1SpiK0GJwYbZILAywJ7tHg=; b=Z4Lv3nIFkRvbKWD0AKXLJua5U8/HC9PWxCRgaZbT7OAMOjnajj9YtvwCWQ30A6blGg IG+1yLDv7U8iwqzO9IwWLbm/Mc/pPhdZwsndXxM8HLUkMcmdSVTK6y1dU8Y+FZetuvoD WTGWDP9m5RtxiiALqNXOXCE9UM+nLhza2DznJY2Gj3JgAeexLwdbq5U5asAFuq6YePj7 7GX21O9061bd1IvMtN/ddg+94K5/TQx0oPPJmBZXcxnAcO5XFX4hbwJkpxBe4JZ2z+10 BFoQBnVw+2SurGOy4LliiJs7eeatutovmNROXrAfIr3u/x7qOb9i407mxZ0x1h+F0oVY FRkA== X-Gm-Message-State: AOAM533TfxnPD7WY7tWKA5gGsATymNXeXkLIz/CdTl0F2HoWa4MrizjD AyzfzoilzzZxgrBs89isOLs= X-Google-Smtp-Source: ABdhPJynUB3EUlaUojOp94UErSVj4RC3gp7IQD83k4BxVOVgrM8ah9xebaojRtUnTHKkKotrmKs3cg== X-Received: by 2002:a17:906:2cc1:: with SMTP id r1mr1488416ejr.305.1601634977959; Fri, 02 Oct 2020 03:36:17 -0700 (PDT) Received: from pi3 ([194.230.155.194]) by smtp.googlemail.com with ESMTPSA id q13sm874130edr.27.2020.10.02.03.36.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Oct 2020 03:36:16 -0700 (PDT) Date: Fri, 2 Oct 2020 12:36:14 +0200 From: Krzysztof Kozlowski To: Marco Felsch Cc: Ahmad Fatoum , devicetree@vger.kernel.org, Robert Jones , Stefan Riedmueller , Anson Huang , Shawn Guo , Sascha Hauer , linux-kernel@vger.kernel.org, Li Yang , Rob Herring , NXP Linux Team , Pengutronix Kernel Team , Andreas Kemnade , Fabio Estevam , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 08/12] ARM: dts: imx6dl-pico: fix board compatibles Message-ID: <20201002103614.GA6799@pi3> References: <20200930190143.27032-1-krzk@kernel.org> <20200930190143.27032-9-krzk@kernel.org> <0a0afea6-8cbb-3e89-5a4f-89660c942ca3@pengutronix.de> <20201001073208.GA5208@kozik-lap> <027fd826-6822-9e92-0c6c-2ebed63f4a07@pengutronix.de> <20201001103704.GA26287@kozik-lap> <7fcea21d-4651-9ba7-5331-86530296a847@pengutronix.de> <20201002082012.GA6605@pi3> <20201002084119.buc6z7hpesoahmg2@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20201002084119.buc6z7hpesoahmg2@pengutronix.de> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 02, 2020 at 10:41:19AM +0200, Marco Felsch wrote: > Hi, > > sorry for jumping in. > > On 20-10-02 10:20, Krzysztof Kozlowski wrote: > > On Fri, Oct 02, 2020 at 09:41:28AM +0200, Ahmad Fatoum wrote: > > > Hello, > > > > > > On 10/1/20 12:37 PM, Krzysztof Kozlowski wrote: > > > >> The existing binding doesn't cover these boards then and needs to be > > > >> extended, no? How about following patch? > > > > > > > > What do you mean it doesn't cover? It was added exactly to handle them: > > > > + - technexion,imx6q-pico-dwarf # TechNexion i.MX6Q Pico-Dwarf > > > > + - technexion,imx6q-pico-hobbit # TechNexion i.MX6Q Pico-Hobbit > > > > + - technexion,imx6q-pico-nymph # TechNexion i.MX6Q Pico-Nymph > > > > + - technexion,imx6q-pico-pi # TechNexion i.MX6Q Pico-Pi > > > > > > > > > > Still they are unused. So I'd think these boards should be handled like boards > > > that predated bindings: a binding is written that doesn't break existing users. > > > > OK, let's assume the binding is not correct and DTSes are good. > > > > > > > > >> [I guess we need to keep the two-compatible list they were originally > > > >> in for compatibility even if it's unused among upstream device trees?] > > > > > > > > You want to change both the binding (thus breaking the ABI) and update > > > > the DTS to reflect new ABI. Then why having a binding at all? > > > > > > If we leave the old two-compatible enumeration intact, there is no ABI broken. > > > > Just to clarify, because I don't get here the "no ABI broken" part: > > ABI is the binding, not the DTS. We can change intree DTS as we like, > > replace compatibles, add nodes, remove nodes. There is no stability > > requirement for DTS contents. > > > > If we leave two-compatible binding intact, it is a broken binding since > > beginning. Removing non-working, fake ABI is not breaking it because it > > could never work. > > The problem here is that it wasn't covered by the review and now we have > the mess. I see the DTB and the Bootloader as Firmware. Now imagine if > the bootloader for these boards had some dt-fixup logic which won't > apply anymore or if the bootloader board init won't get called anymore > since the bootloader folks used the compatible found in the DTS. This > can cause a regression if the old Bootloader tries to boot the new > Kernel+DTS. Good points. It's nice to have a binding documented but it is more likely that bootloader guys were depending on actual contents of DTS. > > > > > I would assume that either binding is correct or DTS. You propose that > > > > both are wrong and both need changes... in such case this is clearly > > > > broken. > > > > > > IMO the DTS is the correct one. If you want to honor the author's intention > > > that each base board has a different compatible, it should be an extra > > > compatible and not replace the existing one that may be already in use. > > Question is what was the author's intention? @Fabio do you have any > comments here? > > > OK, we can go with DTS approach. I fixed few of such cases as well, > > assuming that DTS was intended and binding was incorrect. In such case > > all boards will be documented under one compatible technexion,imx6q-pico > > and DTS will not be changed. > > Or keep the exisiting bindings and adding the new one. Therefore the > yaml needs to handle two cases for each imx6[qdl]: > compatible = "technexion,imx6dl-pico-dwarf", "technexion,imx6dl-pico", "fsl,imx6dl"; > and > compatible = "technexion,imx6dl-pico", "fsl,imx6dl"; This is the combination I wanted to avoid because it kind of proofs that both (binding and DTS) were incorrect or insufficient. If both are incorrect, then there might be no point to keep it stable. Few other i.MX boards use one compatible for multiple DTS. Usually it is a module's compatible and boards just do not add their own. Best regards, Krzysztof 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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 5BEC5C4363D for ; Fri, 2 Oct 2020 10:37:55 +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 DD713206CD for ; Fri, 2 Oct 2020 10:37:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="CJZrJUBk" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DD713206CD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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-Transfer-Encoding: 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-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=6rOMS9Lhe4I/ZnZZ6AtyvlU6pZyVsoMqsXTcaY8lltc=; b=CJZrJUBkVy6r345kGcfH5tS78 HTwYNMTrbTkNBXDXi6knsCLWKSyCoygEYZ8BZ1SxXh1bltWjjX3t48qkqyDYnaw0rvh+zCJK7c1dd pWPcmovEZDWphrz4cAFxMhJjoD46sZ/laFvFgqqPowhhfk5qQvEXnlJRKo3SFumwKjEJHo79nET2I dyUsQflmxDdhKf3XMeShxX8bwL5lyKm+sfX7KYe7c2FpyY9SsiJfbAIlIfUWly8i/OhGYmG2JytCP /Aw+G8phvioGvxpHcocz24Cdk1tMoQzqc7+IBnMtO0iHMPofOPDUem9yw0BSl9S9UGIshWzXdNSFA RUFBTqbgg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kOIQJ-0004b3-9k; Fri, 02 Oct 2020 10:36:23 +0000 Received: from mail-ej1-f67.google.com ([209.85.218.67]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kOIQG-0004aO-5n for linux-arm-kernel@lists.infradead.org; Fri, 02 Oct 2020 10:36:21 +0000 Received: by mail-ej1-f67.google.com with SMTP id u21so1280626eja.2 for ; Fri, 02 Oct 2020 03:36:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=dDy3qtZ35E/i8OLAIFoon1SpiK0GJwYbZILAywJ7tHg=; b=GpzN3n+8FeZSBoWiVwN20T89+xZ5Uf3QgPujnGFmpYqH+KEfHoHPDKffS9t4+p8pcF QZD89jocFXDqtuQG2BDhOv53hh8gi/99sP6Llhk37+to82Nxa0QqgYJIXDUWG7Q4f4FN aFtSUgpC2wmCqkamqY48D44DXnkCZys2a2EwkH5Qu3sAZoaK2cx0mskI9bkaO75dKxsO jiQX0Cb8F5RVRcRGezDDX6gAuGYNoNwcTbTSsnPNuJdPsabm9VYbh6yZ9Z0mFbCui2fF jLyM/f23UaREmaj14WPHVCHftdcBmu+6O+Ib6pr89OaKhtQiNaOM6cLdSzrhC6/UzYGI LSuw== X-Gm-Message-State: AOAM5314Ot6GvTquEKcBfa/IKnjgGx3gMVzKn4BEdHjXRVnJQfo+Ssph imYKBJmmWhW2fok6vAxOZrH8KKjuBFI= X-Google-Smtp-Source: ABdhPJynUB3EUlaUojOp94UErSVj4RC3gp7IQD83k4BxVOVgrM8ah9xebaojRtUnTHKkKotrmKs3cg== X-Received: by 2002:a17:906:2cc1:: with SMTP id r1mr1488416ejr.305.1601634977959; Fri, 02 Oct 2020 03:36:17 -0700 (PDT) Received: from pi3 ([194.230.155.194]) by smtp.googlemail.com with ESMTPSA id q13sm874130edr.27.2020.10.02.03.36.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Oct 2020 03:36:16 -0700 (PDT) Date: Fri, 2 Oct 2020 12:36:14 +0200 From: Krzysztof Kozlowski To: Marco Felsch Subject: Re: [PATCH v2 08/12] ARM: dts: imx6dl-pico: fix board compatibles Message-ID: <20201002103614.GA6799@pi3> References: <20200930190143.27032-1-krzk@kernel.org> <20200930190143.27032-9-krzk@kernel.org> <0a0afea6-8cbb-3e89-5a4f-89660c942ca3@pengutronix.de> <20201001073208.GA5208@kozik-lap> <027fd826-6822-9e92-0c6c-2ebed63f4a07@pengutronix.de> <20201001103704.GA26287@kozik-lap> <7fcea21d-4651-9ba7-5331-86530296a847@pengutronix.de> <20201002082012.GA6605@pi3> <20201002084119.buc6z7hpesoahmg2@pengutronix.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201002084119.buc6z7hpesoahmg2@pengutronix.de> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201002_063620_251115_0EF3C0EB X-CRM114-Status: GOOD ( 34.75 ) 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, Robert Jones , Ahmad Fatoum , Stefan Riedmueller , Anson Huang , Fabio Estevam , Sascha Hauer , linux-kernel@vger.kernel.org, Li Yang , Rob Herring , NXP Linux Team , Pengutronix Kernel Team , Andreas Kemnade , Shawn Guo , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Oct 02, 2020 at 10:41:19AM +0200, Marco Felsch wrote: > Hi, > > sorry for jumping in. > > On 20-10-02 10:20, Krzysztof Kozlowski wrote: > > On Fri, Oct 02, 2020 at 09:41:28AM +0200, Ahmad Fatoum wrote: > > > Hello, > > > > > > On 10/1/20 12:37 PM, Krzysztof Kozlowski wrote: > > > >> The existing binding doesn't cover these boards then and needs to be > > > >> extended, no? How about following patch? > > > > > > > > What do you mean it doesn't cover? It was added exactly to handle them: > > > > + - technexion,imx6q-pico-dwarf # TechNexion i.MX6Q Pico-Dwarf > > > > + - technexion,imx6q-pico-hobbit # TechNexion i.MX6Q Pico-Hobbit > > > > + - technexion,imx6q-pico-nymph # TechNexion i.MX6Q Pico-Nymph > > > > + - technexion,imx6q-pico-pi # TechNexion i.MX6Q Pico-Pi > > > > > > > > > > Still they are unused. So I'd think these boards should be handled like boards > > > that predated bindings: a binding is written that doesn't break existing users. > > > > OK, let's assume the binding is not correct and DTSes are good. > > > > > > > > >> [I guess we need to keep the two-compatible list they were originally > > > >> in for compatibility even if it's unused among upstream device trees?] > > > > > > > > You want to change both the binding (thus breaking the ABI) and update > > > > the DTS to reflect new ABI. Then why having a binding at all? > > > > > > If we leave the old two-compatible enumeration intact, there is no ABI broken. > > > > Just to clarify, because I don't get here the "no ABI broken" part: > > ABI is the binding, not the DTS. We can change intree DTS as we like, > > replace compatibles, add nodes, remove nodes. There is no stability > > requirement for DTS contents. > > > > If we leave two-compatible binding intact, it is a broken binding since > > beginning. Removing non-working, fake ABI is not breaking it because it > > could never work. > > The problem here is that it wasn't covered by the review and now we have > the mess. I see the DTB and the Bootloader as Firmware. Now imagine if > the bootloader for these boards had some dt-fixup logic which won't > apply anymore or if the bootloader board init won't get called anymore > since the bootloader folks used the compatible found in the DTS. This > can cause a regression if the old Bootloader tries to boot the new > Kernel+DTS. Good points. It's nice to have a binding documented but it is more likely that bootloader guys were depending on actual contents of DTS. > > > > > I would assume that either binding is correct or DTS. You propose that > > > > both are wrong and both need changes... in such case this is clearly > > > > broken. > > > > > > IMO the DTS is the correct one. If you want to honor the author's intention > > > that each base board has a different compatible, it should be an extra > > > compatible and not replace the existing one that may be already in use. > > Question is what was the author's intention? @Fabio do you have any > comments here? > > > OK, we can go with DTS approach. I fixed few of such cases as well, > > assuming that DTS was intended and binding was incorrect. In such case > > all boards will be documented under one compatible technexion,imx6q-pico > > and DTS will not be changed. > > Or keep the exisiting bindings and adding the new one. Therefore the > yaml needs to handle two cases for each imx6[qdl]: > compatible = "technexion,imx6dl-pico-dwarf", "technexion,imx6dl-pico", "fsl,imx6dl"; > and > compatible = "technexion,imx6dl-pico", "fsl,imx6dl"; This is the combination I wanted to avoid because it kind of proofs that both (binding and DTS) were incorrect or insufficient. If both are incorrect, then there might be no point to keep it stable. Few other i.MX boards use one compatible for multiple DTS. Usually it is a module's compatible and boards just do not add their own. Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel