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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 46C30C4332F for ; Wed, 16 Nov 2022 13:55:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=3B0aPYFWclNI7dY1zcz8xclKs7rKNjYqrUj/lxYdUE0=; b=XyGW54HwmpXKVszr2KEnZq1/wR QNcDlYHzga2r8CqYMbAfWyOn0PshqklZyxliYvHCmftlkACqo4vWqhvkkfi9nu4L40YXyHAyhbWSU rznpRpgM7IOsVtEyC7t8DSABHHP0Zc/8hO7AWQ0OGH8VWjaZkhrVapk7IrYYiS7vVwszacUUu2lPv p+dRC4rrcc4FHirGRXE024j6XPpaLEuRlo3+gJp/r6sYTdJq9WQq4v9p1R9D50UHyySerT50qxCrN M0Yl4bpVM/vVOnnBwYOqU8rm/VLr17Glul5JX62XHX22G2D90UrYUv+z/Xmq4vFSiANDx7BYrxW8T I4fIVpGg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ovItJ-004Jan-3Z; Wed, 16 Nov 2022 13:55:49 +0000 Received: from relay07.th.seeweb.it ([2001:4b7a:2000:18::168]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ovIsk-004JIm-3c for linux-mediatek@lists.infradead.org; Wed, 16 Nov 2022 13:55:17 +0000 Received: from SoMainline.org (94-209-172-39.cable.dynamic.v4.ziggo.nl [94.209.172.39]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by m-r2.th.seeweb.it (Postfix) with ESMTPSA id C320C3EBDC; Wed, 16 Nov 2022 14:55:05 +0100 (CET) Date: Wed, 16 Nov 2022 14:55:04 +0100 From: Marijn Suijten To: =?utf-8?B?TsOtY29sYXMgRi4gUi4gQS4=?= Prado Cc: Rob Herring , AngeloGioacchino Del Regno , kernel@collabora.com, Krzysztof Kozlowski , Matthias Brugger , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org Subject: Re: [PATCH] docs: dt: writing-schema: Document usage of CHECK_DTBS make flag Message-ID: <20221116135504.mdmgm6ce2cynt5yt@SoMainline.org> References: <20221102214300.309347-1-nfraprado@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20221102214300.309347-1-nfraprado@collabora.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221116_055514_403908_11D78520 X-CRM114-Status: GOOD ( 25.04 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org Hi Nícolas, On 2022-11-02 17:43:00, Nícolas F. R. A. Prado wrote: > It is possible to run checks on a Devicetree by passing the CHECK_DTBS > flag when building. This is a useful shortcut to the dtbs_check make > target since it avoids checking unrelated Devicetrees, which can take > some time and is unnecessary if no bindings were modified. Document it. > > Signed-off-by: Nícolas F. R. A. Prado > > --- > > Documentation/devicetree/bindings/writing-schema.rst | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/Documentation/devicetree/bindings/writing-schema.rst b/Documentation/devicetree/bindings/writing-schema.rst > index 4a381d20f2b4..55ad556472b4 100644 > --- a/Documentation/devicetree/bindings/writing-schema.rst > +++ b/Documentation/devicetree/bindings/writing-schema.rst > @@ -167,6 +167,13 @@ setting the ``DT_SCHEMA_FILES`` variable to a specific schema file or pattern. > make dt_binding_check DT_SCHEMA_FILES=/gpio/ > make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml > > +Note that ``make dtbs_check`` will validate every DT source file that is > +enabled. When making changes to a DT but not to the bindings, a possible > +shortcut to validate only the DT in question is to explicitly build it with > +the ``CHECK_DTBS`` flag enabled. For example:: > + > + make CHECK_DTBS=y mediatek/mt8192-evb.dtb I have a bit of trouble getting this to work on a _clean_ out directory (perhaps this should have been reported at the original patch, I had always been using Dmitry's version [1] which didn't suffer from this problem). Consider running with the following: rm out -r make ARCH=arm64 O=out defconfig make ARCH=arm64 O=out CHECK_DTBS=y qcom/sm8450-sony-xperia-nagara-pdx223.dtb After compiling preliminaries, it exits with: make[3]: *** No rule to make target 'arch/arm64/boot/dts/qcom/sm8450-sony-xperia-nagara-pdx223.dtb'. Stop. make[2]: *** [../scripts/Makefile.build:500: arch/arm64/boot/dts/qcom] Error 2 make[1]: *** [/kernel/Makefile:1460: qcom/sm8450-sony-xperia-nagara-pdx223.dtb] Error 2 make[1]: Leaving directory '/kernel/out' make: *** [Makefile:231: __sub-make] Error 2 However, if I lint all DTBs first by running `dtbs_check`, it seems the schema preliminaries are built: LINT Documentation/devicetree/bindings CHKDT Documentation/devicetree/bindings/processed-schema.json ... bunch of warnings SCHEMA Documentation/devicetree/bindings/processed-schema.json And here I ctrl+c the build so that it doesn't run DTC_CHK over every dts. If I now re-run the original command on my .dtb of choice, it completes successfully with the warnings that I expect. Is the logic behind `CHECK_DTBS=y` simply missing a step to make sure SCHEMA is built and up-to-date? Aside from not working in a clean output directly, could this imply schema changes (edits in Documentation/devicetree/bindings) _are not_ propagated when running with `CHECK_DTBS=y? At the same time running this command twice results in no output the second time around, supposedly because the dtb has "already been built". Is that also something we can improve? [1]: https://lore.kernel.org/linux-arm-msm/20220623144357.297252-1-dmitry.baryshkov@linaro.org/ Thanks! - Marijn