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=-7.5 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 2F185C433DB for ; Thu, 7 Jan 2021 19:42:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EA680233CF for ; Thu, 7 Jan 2021 19:42:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727215AbhAGTmw (ORCPT ); Thu, 7 Jan 2021 14:42:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48832 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726052AbhAGTmv (ORCPT ); Thu, 7 Jan 2021 14:42:51 -0500 Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C2579C0612F5 for ; Thu, 7 Jan 2021 11:42:11 -0800 (PST) Received: by mail-qt1-x834.google.com with SMTP id v5so5055300qtv.7 for ; Thu, 07 Jan 2021 11:42:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=CLKyO0V7gDngVlGI7pgl0SlpTEPLmQs9Jw8dHDtXgak=; b=ZrGnMcWt5YlDl9xLPUa/NZ2qTa+ZV8kU9SmgDHeQtZcIH3xPBmsNo1pG1z/I4HpNxX ZevcNOde/mrT04xMjFFt9+ZTbAQyRwVqGpPDb7PIQHFoe4MjMqH/U+SqwuAHj27L/KJg 94G2jJFEvmvE1cuX5rTfgKJEYyk89vMLGp6wVC5zAlb2cnH0Qi8QPy2tqpKkqE3WPQBh kpwg/iJcOHOTvYLL1f1FOlTAz+TlVaI+ieFCTAAtWzOXW/CzipP4qsd3Yb6RpRDyX0Ti qORGuRx18TSYalpg5ehKEeuzaR2uTD3zkkADvkjsgJ2USIeHEElgFJMikGSF/0XT5Qng 9Smw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=CLKyO0V7gDngVlGI7pgl0SlpTEPLmQs9Jw8dHDtXgak=; b=ZEGFdexnhpvJhi3jkUkt19ls9kDdmwVAK8V4V4Diva/XBxik6E7mVqZX7/8yOOMW7N RbLQqkUcc/jCrNEq4WDpj6Z75PEIeuo/PeP3IAZFKkj0zZ5ZCldkOxPE+dSobRfzvxrZ WVkmVkzmOrakjersFgAnLH5yh6VwznsOMz6pp7kvjY3aQycoRIVvbFFqqcs9DdeHYu5B nS35mD1UtWl13aTiAfBvHssVmkYe7yndUmwT8LrWBSiOwuUzQzaNvHoHRrFAoY2e4QDC 85wZXOL2CKaX5RyI7b0OfttfRhYAXwdFQFfXiTENtUEEWMIUhHPRjbiTZQG0lybQFUqu 9Hmg== X-Gm-Message-State: AOAM5330YFnIBRBuXVqcgRA94cOk6kq5ZlKFAs4Rz6/z7Tu77K5fu+5D IP6/+GsFIRcBJSiuxxF3D5dwLA== X-Google-Smtp-Source: ABdhPJxOXy6evhdqwl97isTQM5M9r4VhmoGo6e1D+pUsNPYP0PivH0cLY6sWlls2AshSXfoZK/Yn1Q== X-Received: by 2002:ac8:578d:: with SMTP id v13mr170661qta.247.1610048530863; Thu, 07 Jan 2021 11:42:10 -0800 (PST) Received: from ?IPv6:2601:144:4100:fd1:12bf:48ff:fed7:9537? ([2601:144:4100:fd1:12bf:48ff:fed7:9537]) by smtp.gmail.com with ESMTPSA id x49sm3430907qtx.6.2021.01.07.11.42.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Jan 2021 11:42:09 -0800 (PST) Subject: Re: [RFC 0/2] kbuild: Add support to build overlays (%.dtbo) To: Rob Herring , Masahiro Yamada , Viresh Kumar Cc: Arnd Bergmann , Olof Johansson , Pantelis Antoniou , Frank Rowand , Michal Marek , DTML , "linux-kernel@vger.kernel.org" , Linux Kbuild mailing list , Vincent Guittot , tero.kristo@gmail.com References: From: Bill Mills Message-ID: Date: Thu, 7 Jan 2021 14:42:08 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Hello, On 1/7/21 2:02 PM, Rob Herring wrote: > On Wed, Jan 6, 2021 at 10:35 PM Masahiro Yamada wrote: >> >> On Wed, Jan 6, 2021 at 12:21 AM Rob Herring wrote: >>> >>> On Tue, Jan 5, 2021 at 4:24 AM Viresh Kumar wrote: >>>> >>>> Hello, >>>> >>>> Here is an attempt to make some changes in the kernel to allow building >>>> of device tree overlays. >>>> >>>> While at it, I would also like to discuss about how we should mention >>>> the base DT blobs in the Makefiles for the overlays, so they can be >>>> build tested to make sure the overlays apply properly. >>>> >>>> A simple way is to mention that with -base extension, like this: >>>> >>>> $(overlay-file)-base := platform-base.dtb >>>> >>>> Any other preference ? >> >> >> >> Viresh's patch is not enough. >> >> We will need to change .gitignore >> and scripts/Makefile.dtbinst as well. >> >> >> In my understanding, the build rule is completely the same >> between .dtb and .dtbo >> As Rob mentioned, I am not sure if we really need/want >> a separate extension. >> >> >> A counter approach is to use an extension like '.ovl.dtb' >> It clarifies it is an overlay fragment without changing >> anything in our build system or the upstream DTC project. *.dtbo is already a well established defato standard. I see little value in changing it and doing so will likely just bifurcate common usage. >> >> We use chained extension in some places, for example, >> .dt.yaml for schema yaml files. >> >> >> >> dtb-$(CONFIG_ARCH_FOO) += \ >> foo-board.dtb \ >> foo-overlay1.ovl.dtb \ >> foo-overlay2.ovl.dtb >> >> >> Overlay DT source file names must end with '.ovl.dts' > > I like that suggestion as then it's also clear looking at the source > files which ones are overlays. Or we'd need .dtso to be consistent. > I don't think there is much of a problem renaming the source side. Don't know if that helps if the output is still dtbo. "Be consistent on dtso" sounds good to me. Can it be enforced via build time checks? > >>> I think we'll want something similar to how '-objs' works for modules: >>> >>> foo-board-1-dtbs := foo-board.dtb foo-overlay1.dtbo >>> foo-board-2-dtbs := foo-board.dtb foo-overlay2.dtbo >>> foo-board-1-2-dtbs := foo-board.dtb foo-overlay1.dtbo foo-overlay2.dtbo >>> dtbs-y += foo-board-1.dtb foo-board-2.dtb foo-board-1-2.dtb >>> >>> (One difference here is we will want all the intermediate targets >>> unlike .o files.) >>> >>> You wouldn't necessarily have all the above combinations, but you have >>> to allow for them. I'm not sure how we'd handle applying any common >>> overlays where the base and overlay are in different directories. >> >> >> I guess the motivation for supporting -dtbs is to >> add per-board -@ option only when it contains *.dtbo pattern. > > I hadn't thought that far, but yeah, that would be good. Really, I > just want it to be controlled per SoC family at least. > >> But, as you notice, if the overlay files are located >> under drivers/, it is difficult to add -@ per board. > > Generally, they shouldn't be. The exceptions are what we already have > there which are old dt fixups and unittests. > > We want the stripped DT repo (devicetree-rebasing) to have all this > and drivers/ is stripped out. (Which reminds me, the DT repo will need > some work to support all this. It's a different build sys.) > >> Another scenario is, some people may want to compile >> downstream overlay files (i.e. similar concept as external modules), >> then we have no idea which base board should be given with the -@ flag. >> >> >> I'd rather be tempted to add it globally >> >> >> ifdef CONFIG_OF_OVERLAY >> DTC_FLAGS += -@ >> endif > > We've already rejected doing that. Turning on '-@' can grow the dtb > size by a significant amount which could be problematic for some > boards > >>> Another thing here is adding all the above is not really going to >>> scale on arm32 where we have a single dts directory. We need to move >>> things to per vendor/soc family directories. I have the script to do >>> this. We just need to agree on the vendor names and get Arnd/Olof to >>> run it. I also want that so we can enable schema checks by default >>> once a vendor is warning free (the whole tree is going to take >>> forever). >> >> >> If this is a big churn, perhaps we could make it extreme >> to decouple DT and Linux-arch. > > I would be fine with that, but I don't think we'll get agreement > there. With that amount of change, we'll be discussing git submodule > again. > > Rereading the thread on vendor directories[1], we may just move boards > one vendor at a time. We could just make that a prerequisite for > vendor supporting overlays. > >> arch/*/boot/dts/*.dts >> -> dts//*.dts >> >> Documentation/devicetree/bindings >> -> dts/Bindings/ >> >> include/dt-bindings/ >> -> dts/include/dt-bindings/ >> >> >> >> Then, other project can take dts/ >> to reuse for them. > > This is already possible with devicetree-rebasing.git. Though it is > still by arch. > > Rob > > [1] https://lore.kernel.org/linux-devicetree/20181204183649.GA5716@bogus/ > Thanks for digging up this script! Bill