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=-0.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 2217CC00307 for ; Fri, 6 Sep 2019 17:15:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EC017218AC for ; Fri, 6 Sep 2019 17:15:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=goldelico.com header.i=@goldelico.com header.b="gvGNNYDM" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404311AbfIFRPX (ORCPT ); Fri, 6 Sep 2019 13:15:23 -0400 Received: from mo4-p02-ob.smtp.rzone.de ([85.215.255.82]:21650 "EHLO mo4-p02-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391025AbfIFRPW (ORCPT ); Fri, 6 Sep 2019 13:15:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1567790117; s=strato-dkim-0002; d=goldelico.com; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=buKu5hjInnzvyOfqmb2TKwkajlRXIz+/+dwMu1dYtdI=; b=gvGNNYDM7OqBA/fDLh2AEI0mrpwjWaGb27FiVrX/9t4apz96jJVq/is3Yqbn0rYnCI ccIw14IVpYjDUeV7si/GmkeJj0O1UYPise8Zjt28NQlB6q3j/phKZnR0PZSi+jMRBf6/ 9OC/8TBaceJQStHg5MgaCCjFyiF0o3xKnQMRTXP6ZAesEVuwfo4efkR69jedPrgDTv0b gGvDl19qR75U0Uuq7A32rBFz2NhfgS3jha2VpRo0Vj/3oAFBDs7OCrQ6m5FUlx2WbJ33 iSXrWSru2OPPo6sQPorc1vAS0FuCfeLM5Z3g22Jhhxw8pYPBNl/iMLj/rXNJEVYg5CVy zGUg== X-RZG-AUTH: ":JGIXVUS7cutRB/49FwqZ7WcJeFKiMgPgp8VKxflSZ1P34KBj7wpz8NMGH/PqwDqp5w==" X-RZG-CLASS-ID: mo00 Received: from imac.fritz.box by smtp.strato.de (RZmta 44.27.0 DYNA|AUTH) with ESMTPSA id u036f9v86HF9pfI (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Fri, 6 Sep 2019 19:15:09 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [RFC v2 3/3] ARM: dts: omap3: bulk convert compatible to be explicitly ti,omap3430 or ti,omap36xx From: "H. Nikolaus Schaller" In-Reply-To: <8C8644AC-FA12-4D26-B96A-76B78798612A@goldelico.com> Date: Fri, 6 Sep 2019 19:15:09 +0200 Cc: Viresh Kumar , =?utf-8?Q?Beno=C3=AEt_Cousson?= , Rob Herring , Adam Ford , =?utf-8?Q?Andr=C3=A9_Roth?= , Mark Rutland , "Rafael J. Wysocki" , Linux-OMAP , devicetree , Linux Kernel Mailing List , linux-pm@vger.kernel.org, Discussions about the Letux Kernel , kernel@pyra-handheld.com Content-Transfer-Encoding: quoted-printable Message-Id: <2BA36283-F867-44C0-8AAA-B7CCFA616C8D@goldelico.com> References: <20190905142734.GV52127@atomide.com> <4BC39938-D63E-4BDC-BA28-5132F77F602D@goldelico.com> <20190906154732.GC52127@atomide.com> <8C8644AC-FA12-4D26-B96A-76B78798612A@goldelico.com> To: Tony Lindgren X-Mailer: Apple Mail (2.3124) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Am 06.09.2019 um 19:08 schrieb H. Nikolaus Schaller = : >=20 > Hi Tony, >=20 >> Am 06.09.2019 um 17:47 schrieb Tony Lindgren : >>=20 >> * H. Nikolaus Schaller [190906 07:53]: >>>> Am 05.09.2019 um 16:27 schrieb Tony Lindgren : >>>> compatible =3D "ti,omap3-ldp", "ti,omap3430", "ti,omap34xx", = "ti,omap3"; >>>=20 >>> After thinking a little about the whole topic the main rule of this = change must be: >>>=20 >>> * do not break any existing in-tree DTS >>> =3D> only *add* to compatible what we need to distinguish = between omap34 and omap36 >>>=20 >>> * additions shall only follow new scheme >>> =3D> we only add "ti,omap34xx" or "ti,omap36xx" >>> but neither "ti,omap3630" nor "ti,omap3430" >>=20 >> Sorry I don't follow you on this one.. We should always add = "ti,omap3630" >> where "ti,omap36xx" is currently used so we can eventually get rid of >> "ti,omap36xx". And the same for 34xx. >=20 > Ah, ok now I see. >=20 > You want to make the "ti,omap3630" the official one and "ti,omap36xx" = legacy. > It is probably an arbitrary choice if we want to get rid of the xx or = the 30. >=20 > I had thought to do it the other way round because I had done this = statistics: >=20 > for i in 3430 34xx 3630 36xx; do echo $i $(fgrep '"'ti,omap$i'"' = arch/arm/boot/dts/*.dts* | wc -l); done >=20 > 3430 12 > 34xx 28 > 3630 3 > 36xx 23 sorry, here is the correct result. I had some .bak files sitting around: 3430 12 34xx 5 3630 3 36xx 23 > which would indicate that 34xx and 36xx are more common. >=20 >>> * cover some out-of-tree DTS >>> =3D> make the ti-cpufreq driver still match "ti,omap3430" or = "ti,omap3630" >>> even if this duplicates compatibility >>>=20 >>> This would mean that the logicpd-som-lv-37xx-devkit.dts gets the = additional "ti,omap36xx" >>> while the omap3-ldp.dts would only get an "ti,omap34xx" but no = "ti,omap3430" (since we >>> do not use it anywhere). >>>=20 >>> Could you agree on this approach? >>=20 >> Yeah sounds like logicpd-som-lv-37xx-devkit.dts currently still needs >> "ti,omap36xx" for now. >>=20 >> If modifying omap3-ldp.dts, also add "ti,omap3430" in additon to >> "ti,omap34xx" that it already has. >>=20 >> So basically let's assume the following: >>=20 >> "ti,omap3430" =3D=3D "ti,omap34xx" >> "ti,omap3630" =3D=3D "ti,omap36xx" >>=20 >> This means code needs to parse both. >=20 > Yes, it already does everywhere. >=20 > BTW there is also some code that does special SoC detection based on > soc_device_match(), mainly in omapdrm/dss. >=20 > If we were to use this mechanism in the ti-cpufreq driver we could > match it to ti,omap3 and could avoid all these changes. >=20 > But make it less maintainable and code more complex. >=20 >>=20 >> And eventually we just drop the "xx" variants. >=20 >>=20 >> So while patching compatibles, let's also update for this to >> avoid multiple patches churning the same compatibles over and >> over. >=20 > Ok. I'll rework the patch so that we never add "ti,34xx" or "ti,36xx" > but add "ti,3430" or "ti,3630" if missing. >=20 > I'll also take a look at omap.txt bindings since that likely needs > an update as well to better describe what the official ones are > and which are legacy. >=20 > BR and thanks, > Nikolaus >=20