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 3F67AC4332F for ; Wed, 16 Nov 2022 13:57:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To: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=LzSrNaDkwrw7pEQQMyFNwCyL3S4e+AUEAJlJsEaaUhk=; b=n5rzKC69e9HF1O QbN3/W1ol1JvFThylspkTWQvftpiJPsAOw9S+yIVvVYn9pau8kYf+rJm30v73UtiB5a/XA4915MoG aolmG5X2r+4ZNtJg4smKfrOgWi2DtrS5oaLad8BDqKxpvDhOYerls0eMagtnelw0Igaq+kYrLeHbt mXzto+q056ZZ3Js9Nj3iWwRoPW2ex3RTLh2cSm3XE9fOAV4wpwK19J+m3zj06i8t9D4VhTLbVy0vz vZ274E0OzW+2i0CeMTa7rWAMgjKCCOKXzNKoCMhJbLJrBNFHH4YExjVqCCVv+n49exJFDwDCq03sB ASreFlzuR1RrGd71vG0g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ovIt2-004JSx-IL; Wed, 16 Nov 2022 13:55:33 +0000 Received: from relay08.th.seeweb.it ([5.144.164.169]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ovIsk-004JIl-4V for linux-arm-kernel@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-Disposition: inline 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_371653_F0148033 X-CRM114-Status: GOOD ( 25.74 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi N=EDcolas, On 2022-11-02 17:43:00, N=EDcolas 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=EDcolas 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/Docum= entation/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 specif= ic schema file or pattern. > make dt_binding_check DT_SCHEMA_FILES=3D/gpio/ > make dtbs_check DT_SCHEMA_FILES=3Dtrivial-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 w= ith > +the ``CHECK_DTBS`` flag enabled. For example:: > + > + make CHECK_DTBS=3Dy 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=3Darm64 O=3Dout defconfig make ARCH=3Darm64 O=3Dout CHECK_DTBS=3Dy 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-so= ny-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-pdx= 223.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=3Dy` 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=3Dy? 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.b= aryshkov@linaro.org/ Thanks! - Marijn _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel