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=-2.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 CED6CC35657 for ; Fri, 21 Feb 2020 17:47:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A1E0B206E2 for ; Fri, 21 Feb 2020 17:47:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="mJFaZOiM" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727656AbgBURrt (ORCPT ); Fri, 21 Feb 2020 12:47:49 -0500 Received: from mail-yb1-f195.google.com ([209.85.219.195]:36542 "EHLO mail-yb1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726150AbgBURrt (ORCPT ); Fri, 21 Feb 2020 12:47:49 -0500 Received: by mail-yb1-f195.google.com with SMTP id u26so1502120ybd.3; Fri, 21 Feb 2020 09:47:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=vJE8mbTg+EqCG56Tu0+ggaMIT/oTLKaNGToyz1VhJn0=; b=mJFaZOiMn4SLJ1LLt01opUO977i2inPUITceDJCxUi2tyWDpllUafj/JvVHC6Zkgrh SYAdUSny0/ThfejOU1q7ZGlney19fmLx6x/cxYdmXwJNe4GyWRNqfLJ+3udZrySRQmED uR+y7mMsElDkCG4AQAUoD5hZCT4uWgXB0ggpQGsr7fqQuhrWuQ+mDtCnfDPnCwHnoH94 g8+CDglEYTdpPuMYEkEuBBslYQnomlBfGBapJMchN6wHIqwktYyJIF8E9tH1ChRkimGp InDPtCUmVlYPYBsrGLDpKL++VjfCrpnr1nPWOlOX3qkv/db6yrfjriPUkKbZZwvw3A5V lfcw== 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=vJE8mbTg+EqCG56Tu0+ggaMIT/oTLKaNGToyz1VhJn0=; b=g41CeF40CiMQg1AfACBRhn9oFREmIlqdtlz4ncdMM9YJ+EHuvgDW/7nL+SuxMCBME8 1EHhzgnQRtuAG5/CxCC9WbyZaGABHoaMDDQK/97r+B3ReQ/Ny6nRchaEo7xOfelrgqws 4dSBYcfQ9a41kfFGOXSjMJglze33+oFKXPXDt3PAVJL2BaadY4bSI90etaa7lKNWoPqt vTyFFAItbpRCnTYieapXMwHFeZVAN1rvq+UIhTMrs+ZbgRp+InTrul5SiKV5spM/Vb+5 O5RYQvqhD9dr8/9+Qv9N46LM4Dh1dbUjTsibxFDWB9tkFtFKtkwr95IRZp8s76Itf3v1 s4jQ== X-Gm-Message-State: APjAAAV0R9dJI+ewI5Gu6SbmKST5sv9vdtVf/Iz9yvb0Ncckt+RFNBiv 2pVbVyce68N9U/oTY3zDK4A= X-Google-Smtp-Source: APXvYqzmo2BtZCVvY3XpIxWiwjd2MXnNDsld7UgNaLBdEQyfuxTBX7rstuL2CwZqHNH+A8pjy6xBBA== X-Received: by 2002:a25:e758:: with SMTP id e85mr37264859ybh.173.1582307266578; Fri, 21 Feb 2020 09:47:46 -0800 (PST) Received: from [192.168.1.46] (c-73-88-245-53.hsd1.tn.comcast.net. [73.88.245.53]) by smtp.gmail.com with ESMTPSA id p2sm1620487ywd.58.2020.02.21.09.47.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Feb 2020 09:47:46 -0800 (PST) Subject: Re: [RFC PATCH v2 0/4] Add device tree build information To: Alexandre Torgue , robh+dt@kernel.org, Masahiro Yamada , Michal Marek , david@gibson.dropbear.id.au, sjg@chromium.org Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org, devicetree-compiler@vger.kernel.org, Ian Lepore References: <20200221161418.20225-1-alexandre.torgue@st.com> From: Frank Rowand Message-ID: <1b946fcf-47a9-012d-1b04-f4bbd2682607@gmail.com> Date: Fri, 21 Feb 2020 11:47:44 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20200221161418.20225-1-alexandre.torgue@st.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 2/21/20 10:14 AM, Alexandre Torgue wrote: > (with title it's better ;) > > Hi, > > The goal of this series is to add device tree build information in dtb. > This information can be dtb build date, where devicetree files come from, > who built the dtb ... Actually, same kind of information that you can find > in the Linux banner which is printout during kernel boot. Having the same > kind of information for device tree is useful for debugging and maintenance. > > A file (dtb-build.txt) containing a string with build information (e.g., >>>From Linux 5.5.0-rc1 by alex the Mon Jan 13 18:25:38 CET 2020) is generated by > "gen_dtb_build_info.sh" script. > > This file has to be included manually in each dts file that would like to use > this build information. In the RFC series, you said: "I gonna prepare a V2 with David proposition (to use overlay format) by keeping in mind not to modify existing dts(i) files." https://lore.kernel.org/linux-devicetree/9d83a36c-78c5-3452-bb48-209d68c46038@st.com/ But here in v2 instead requires including dtb-build.txt. This would require modifying every single main .dts file to get the build info. I would prefer the method that Ian and David came up with (sorry, no lore link, it did not go to lkml). Extract from David's email: Date: Tue, 21 Jan 2020 13:05:25 +1100 From: David Gibson Subject: Re: [RFC PATCH 1/3] dtc: Add dtb build information option > Given that dts files are run through the C preprocessor before being > fed to dtc, the build script could use the '-include' flag to force- > include a fragment containing generated build info without any need to > modify existing dts files. Uh... maybe. -include will essentially prepend the forced file, which is a bit awkward for our purposes. It means that the prepended file would need the /dts-v1/ tag, and we couldn't have it in the main files which would be a bit confusing. I think it would also cause problems with any /memreserve/ tags and means that the main tree could in theory overwrite the build information which we don't necessarily want. I guess we could build things the other way around: have the main .dts file specified with -include and have the dts on the dtc commandline be a fixed one with the build information. It'd be a little weird, though. -Frank > > of/fdt.c is modified to printout "build-info" property during Kernel boot and > scripts/Makefile.lib is modified to call "gen_dtb_build_info.sh" script. > > Patch 1 & 2 script and of/fdt.c updates > Patch 3 is an example of use in stm32mp157c-dk2.dts file. > Patch 4 is a tentative to make it automatic (not yet 100% functional). > > regards > Alex > > Changes since v1; > - Remove modification in dtc (no more -B option) > - Generate a file containing build info which is directly included in dts > file. > > > Regards > Alex > > Alexandre Torgue (4): > scripts: Add script to generate dtb build information > of: fdt: print dtb build information > ARM: dts: stm32: Add dtb build information entry for stm32mp157c-dk2 > script: make automatic dtb build info generation > > arch/arm/boot/dts/stm32mp157c-dk2.dts | 1 + > drivers/of/fdt.c | 9 +++++++++ > scripts/Makefile.lib | 3 +++ > scripts/gen_dtb_build_info.sh | 12 ++++++++++++ > 4 files changed, 25 insertions(+) > create mode 100755 scripts/gen_dtb_build_info.sh >