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.3 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 21B4DC3F2CD for ; Fri, 28 Feb 2020 17:47:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E5C1E246A3 for ; Fri, 28 Feb 2020 17:47:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="n2AiaVXB" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726733AbgB1Rrd (ORCPT ); Fri, 28 Feb 2020 12:47:33 -0500 Received: from mail-yw1-f67.google.com ([209.85.161.67]:36562 "EHLO mail-yw1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726561AbgB1Rrd (ORCPT ); Fri, 28 Feb 2020 12:47:33 -0500 Received: by mail-yw1-f67.google.com with SMTP id y72so4110398ywg.3; Fri, 28 Feb 2020 09:47:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=7PKfOLFLVMzQtUrgljSKPHVUzcIMzVWb/k+R/Aaq3LI=; b=n2AiaVXBDYLpoz5V/ZBhyl+qF/5StswtzLNYPmErW158Ty6klQSVXD2llo7pdzm/Hm qhhetWBn3K8YYTbHAkmvaWUDRMp0op/+waLu7O1uFAJ6AsPJfwx1LQB1Esbdv4sPMlqY GvjvhfCVwb7/sN5GptGaWqExZc1Cxbug7FjvVgNDw/C2nW0KJV3EiG3PKqjWQNLEUzsS mIR7V7FIpUh1wBV+V/SFf/CgHswBY+KXO+yjEscNrodopqRL3yNygp7GyZlNVZmSpNwf 7sm4jdDCJtyKfMTyQztEgHnqhoge+W7TBmtASeNy6+1gXcXCnvtAFkH0tpw9teWZFzZN LhSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7PKfOLFLVMzQtUrgljSKPHVUzcIMzVWb/k+R/Aaq3LI=; b=O5c7lVfEysjk6yeK/xYf95J0Se8f1Qfq/2lvfflPxtKiYpC1dsvFTiWT6EPLteBAsR c2UR2keiJiT98za/Q5UDSnNmlkHyEpTa1IoovsU+Soh2WCDh3G0DN4ntkgNP9g6aIK6k 6yGRLHH58rW+M96OPACwhs1D6Y6aJtjo76MrOECA6O6XBFAWDSfZ9nT5+562f/mXwmdD PBqVhikr4OaXtSMl6nISWiJB7JbZuSU0vqGi/0Emlht1/9CqsSQQJKUKKcNmhcCp4Vrj 3WdX0yCMQuVHN5fzNmVTyQWGF8hhTPnUpWEVCNXyJTqU35U1R1eDmMQfSLra6Ui06ZFr pj8Q== X-Gm-Message-State: APjAAAUt8rVoKyWTsiY/Dv9qjlry6l+FrAtKrmJfvk89YNvzjb773xfE 5U63FGVitLo+Y+e/pal6nrg= X-Google-Smtp-Source: APXvYqxz3qeXwQ1qLGzUQ8u0gRcUv5pYb59pUxz2T0Kgdw4cjm6IxyYBEW2t3+z7u8U2dFMMH62bsw== X-Received: by 2002:a25:384e:: with SMTP id f75mr4926670yba.224.1582912051827; Fri, 28 Feb 2020 09:47:31 -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 x84sm4256114ywg.47.2020.02.28.09.47.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Feb 2020 09:47:31 -0800 (PST) Subject: Re: [RFC PATCH v2 0/4] Add device tree build information From: Frank Rowand 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> <1b946fcf-47a9-012d-1b04-f4bbd2682607@gmail.com> Message-ID: <67d75f0c-7478-23b0-8619-746cf83cedb5@gmail.com> Date: Fri, 28 Feb 2020 11:47:30 -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: <1b946fcf-47a9-012d-1b04-f4bbd2682607@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Alexandred, Ping. -Frank On 2/21/20 11:47 AM, Frank Rowand wrote: > 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 >> > >