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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0DB6EC433FE for ; Fri, 21 Oct 2022 14:45:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229987AbiJUOpV (ORCPT ); Fri, 21 Oct 2022 10:45:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36966 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229961AbiJUOpB (ORCPT ); Fri, 21 Oct 2022 10:45:01 -0400 Received: from lelv0142.ext.ti.com (lelv0142.ext.ti.com [198.47.23.249]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 261D5816A2; Fri, 21 Oct 2022 07:44:55 -0700 (PDT) Received: from fllv0034.itg.ti.com ([10.64.40.246]) by lelv0142.ext.ti.com (8.15.2/8.15.2) with ESMTP id 29LEiZKD036346; Fri, 21 Oct 2022 09:44:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1666363475; bh=zhUQ/gRdkp8LxqXF4f6PJGmUgaZpmB9M36LtuE30bQk=; h=Date:Subject:To:CC:References:From:In-Reply-To; b=KGul0+0UUsKtDPgazav4OzDdU8Y93bXzMm2sIJAJ2mtV980IX8dJcORWvP4cX2Aww yqCu3yjdlcJxmhsXqoOKQYSkeArBfpYh5Xcjo5kkPEfOSF9DkdlJ0NFj5sv/bLNqUp 6v3xE+FlguHsJgeJSln12l45hI6u0F6qf727FZKo= Received: from DLEE108.ent.ti.com (dlee108.ent.ti.com [157.170.170.38]) by fllv0034.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 29LEiZHk013182 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 21 Oct 2022 09:44:35 -0500 Received: from DLEE102.ent.ti.com (157.170.170.32) by DLEE108.ent.ti.com (157.170.170.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.6; Fri, 21 Oct 2022 09:44:34 -0500 Received: from fllv0040.itg.ti.com (10.64.41.20) by DLEE102.ent.ti.com (157.170.170.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.6 via Frontend Transport; Fri, 21 Oct 2022 09:44:35 -0500 Received: from [10.250.33.68] (ileaxei01-snat.itg.ti.com [10.180.69.5]) by fllv0040.itg.ti.com (8.15.2/8.15.2) with ESMTP id 29LEiYFU015889; Fri, 21 Oct 2022 09:44:34 -0500 Message-ID: Date: Fri, 21 Oct 2022 09:44:34 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [PATCH] kbuild: Allow DTB overlays to built from .dtso named source files Content-Language: en-US To: Geert Uytterhoeven , Rob Herring CC: Geert Uytterhoeven , Nishanth Menon , Vignesh Raghavendra , Masahiro Yamada , Michal Marek , Nick Desaulniers , , , , Frank Rowand References: <20221014151302.27641-1-afd@ti.com> From: Andrew Davis In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Precedence: bulk List-ID: X-Mailing-List: linux-kbuild@vger.kernel.org On 10/21/22 1:52 AM, Geert Uytterhoeven wrote: > Hi Rob, > > On Fri, Oct 21, 2022 at 12:47 AM Rob Herring wrote: >> On Fri, Oct 14, 2022 at 10:13 AM Andrew Davis wrote: >>> Currently DTB Overlays (.dtbo) are build from source files with the same >>> extension (.dts) as the base DTs (.dtb). This may become confusing and >>> even lead to wrong results. For example, a composite DTB (created from a >>> base DTB and a set of overlays) might have the same name as one of the >>> overlays that create it. >>> >>> Different files should be generated from differently named sources. >>> .dtb <-> .dts >>> .dtbo <-> .dtso >>> >>> We do not remove the ability to compile DTBO files from .dts files here, >>> only add a new rule allowing the .dtso file name. The current .dts named >>> overlays can be renamed with time. After all have been renamed we can >>> remove the other rule. >> >> There was a patch from Geert converting everything. I'd rather not >> support both ways. > > Actually that was a patch from Frank? > That series looks to have stalled? It won't be easy to convert all the files in one go, especially with series in-flight with both names, not sure how we avoid having both extensions for at least one cycle. Plus having both allowed lets rename the existing files in a more granular/bisectable way. Thanks, Andrew