Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp2808180pxp; Tue, 8 Mar 2022 02:10:29 -0800 (PST) X-Google-Smtp-Source: ABdhPJz5MDCNmkd4CqOv8va9I34kOSGj2kwyeqG/vzH4Fzvq8NTjQndHU+iWgYBl8Y5zoXWRqDhc X-Received: by 2002:a63:8248:0:b0:37c:94e6:16e7 with SMTP id w69-20020a638248000000b0037c94e616e7mr13446173pgd.194.1646734229479; Tue, 08 Mar 2022 02:10:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646734229; cv=none; d=google.com; s=arc-20160816; b=LcjrO1uE84C3ytrKjQdd/dXlmERXVNuJHUSfbzjisGvI/RHfvJ9zajXz92+rCDiRyK HXd1H5fcoTBDynRUlogveGS7LRFCaIuacm9vycbC3PuXWycTyaVNSYw5MLDBzn38ZCun DYK2BjYUrHV/OdhLa2FyQYTff0qbNrNbozdOP05jSkHp7N7lt0YrUBFer2xF+R/ffWQ+ VqUEHgLRyHeUUeq48D5VBajktcPX7u2Ui+WQ4smI9wBj91VeCoE5tJVTh0IS9Ao0zTK6 vh/ngb+l3Vvgie21hiHCBmEJrkApfGeLac+CW7jAItxGB2CO0hQPEO0jQCPFEWzkoqW5 3iGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=EOwxd04/4/kj/T/nPio4Op2b4/YeB/0jSlIXRERfWek=; b=jp2+kZLWWT2Z/w0IVBQA5a4NEX/fi49+NnIYcbuG1qD3NEn/2aSRxLhRNabzNcsenq kwop+KfuvqxAJNeGfXe9+EzSR7Q78pCCtt2LoMU99SeY4bwvCE2z9KCTmD/EsFBSpZJj ku4xyr8ujNqfWH8fUmDHKebeEJUzfAS9lcFZb9KUyfcsdU9rNoz+B/5sX+NpCy4gGdNh X6HveBoifwQe7QNO6YN9huQqCdz1QAbJlFPrvYFiEb3h6O1nxMXqHxEsFAiOmQJSHdCw UFrtFoQ+E+pXVBkb6JLEmJan5oRDwsMnSD3HH0QWICOn4TEcxgsxwJu6osc45gszCrFh Z+sA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a5-20020a17090a688500b001befe0b2d00si1801400pjd.92.2022.03.08.02.10.14; Tue, 08 Mar 2022 02:10:29 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245733AbiCHIjK (ORCPT + 99 others); Tue, 8 Mar 2022 03:39:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39480 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344998AbiCHIjJ (ORCPT ); Tue, 8 Mar 2022 03:39:09 -0500 Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3D5371D302; Tue, 8 Mar 2022 00:38:13 -0800 (PST) Received: by mail-qk1-f170.google.com with SMTP id q4so14197036qki.11; Tue, 08 Mar 2022 00:38:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EOwxd04/4/kj/T/nPio4Op2b4/YeB/0jSlIXRERfWek=; b=LPvxndiY9l/5RkNBuH8/DoxmR9I6zM7geWY5o6arqTD34v/V5KDky2rPAhCjmE+dvP dW56yazmC+BPHJpPNCp8Sz7hNPMi8ZLr6UocQ+JZG6G9r3QA0ipOFyPSaJMLyY+sQUy4 FdB4tcM8rnptwfG1eUbbaiPTCmg2U2BypC8cZ79XtADYwJJjU24D5I8aOZFEIIWi88Kv TLjpXb+NAgfZYWvUQSb1tpDjb5iBUOlXFi7ih6MJFEYP+DurPORrI1hhFF5v+Pmnacw1 kGn+YER6ZyYYpQqo38VEsElqL+xkG3t5Cn3j41WPA8iXv79uXBtN1cj+tnMgCwrhCmC4 V8jA== X-Gm-Message-State: AOAM532m2ZV0lZMBW6aFgZDpTznrS688j7OTRm0htzNnDdxlFHjKARhP 3FW6kyLLvZlu1TTR699iBMQhyiE86D85/A== X-Received: by 2002:a37:acb:0:b0:67b:15f9:55b8 with SMTP id 194-20020a370acb000000b0067b15f955b8mr6346717qkk.694.1646728691864; Tue, 08 Mar 2022 00:38:11 -0800 (PST) Received: from mail-yb1-f174.google.com (mail-yb1-f174.google.com. [209.85.219.174]) by smtp.gmail.com with ESMTPSA id k125-20020a378883000000b006491db6dbb1sm7568185qkd.84.2022.03.08.00.38.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Mar 2022 00:38:11 -0800 (PST) Received: by mail-yb1-f174.google.com with SMTP id g1so36294662ybe.4; Tue, 08 Mar 2022 00:38:11 -0800 (PST) X-Received: by 2002:a25:bc8f:0:b0:628:8649:5c4b with SMTP id e15-20020a25bc8f000000b0062886495c4bmr10892276ybk.207.1646728690920; Tue, 08 Mar 2022 00:38:10 -0800 (PST) MIME-Version: 1.0 References: <20220303224237.2497570-1-robh@kernel.org> <20220303224237.2497570-3-robh@kernel.org> In-Reply-To: From: Geert Uytterhoeven Date: Tue, 8 Mar 2022 09:37:58 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 2/2] dt-bindings: kbuild: Use DTB files for validation To: Rob Herring Cc: Masahiro Yamada , Krzysztof Kozlowski , Michal Marek , Nick Desaulniers , Frank Rowand , Laurent Pinchart , Maxime Ripard , Linux Kernel Mailing List , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , linux-kbuild Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Rob, On Mon, Mar 7, 2022 at 6:00 PM Rob Herring wrote: > On Mon, Mar 07, 2022 at 01:20:29PM +0100, Geert Uytterhoeven wrote: > > On Thu, Mar 3, 2022 at 11:43 PM Rob Herring wrote: > > > Switch the DT validation to use DTB files directly instead of a DTS to > > > YAML conversion. > > > > > > The original motivation for supporting validation on DTB files was to > > > enable running validation on a running system (e.g. 'dt-validate > > > /sys/firmware/fdt') or other cases where the original source DTS is not > > > available. > > > > > > The YAML format was not without issues. Using DTBs with the schema type > > > information solves some of those problems. The YAML format relies on the > > > DTS source level information including bracketing of properties, size > > > directives, and phandle tags all of which are lost in a DTB file. While > > > standardizing the bracketing is a good thing, it does cause a lot of > > > extra warnings and churn to fix them. > > > > > > Another issue has been signed types are not validated correctly as sign > > > information is not propagated to YAML. Using the schema type information > > > allows for proper handling of signed types. YAML also can't represent > > > the full range of 64-bit integers as numbers are stored as floats by > > > most/all parsers. > > > > > > The DTB validation works by decoding property values using the type > > > information in the schemas themselves. The main corner case this does > > > not work for is matrix types where neither dimension is fixed. For > > > now, checking the dimensions in these cases are skipped. > > > > > > Signed-off-by: Rob Herring > > > > Thanks for your patch! > > > > While investigating why a newly added device node to DTS was not > > instantiated as a platform device, I discovered an issue with this > > patch: "make dtbs" no longer rebuilds DTB files that need a rebuild. > > > > How to reproduce: > > > > $ git checkout next-20220307 > > # apply this series and its dependency: > > # dt-bindings: kbuild: Support partial matches with DT_SCHEMA_FILES > > # dt-bindings: kbuild: Pass DT_SCHEMA_FILES to dt-validate > > # dt-bindings: kbuild: Use DTB files for validation > > $ make ARCH=arm shmobile_defconfig > > $ make ARCH=arm dtbs > > $ touch arch/arm/boot/dts/r8a7791.dtsi > > $ make ARCH=arm dtbs > > # The above command does NOT cause: > > # DTC arch/arm/boot/dts/r8a7791-koelsch.dtb > > # DTC arch/arm/boot/dts/r8a7791-porter.dtb > > > > I don't see anything wrong with this patch at first sight, though. > > Was this a clean tree? The above was a clean tree. > I think I reproduced it, but then couldn't... But then after a 'make > clean', 'make dtbs' would error out. I think the issue in both cases was > processed-schema.json always a dependency when it should be conditional > on 'dtbs_check'. The patch below fixes that. Can you give it a try too. I first saw the issue in my normal work tree. However, I cannot reproduce it in that tree anymore :-( I can reproduce it in the clean tree after following the instructions above, and your patch fixes that, so Tested-by: Geert Uytterhoeven > --- a/scripts/Makefile.lib > +++ b/scripts/Makefile.lib > @@ -349,12 +349,12 @@ $(multi-dtb-y): FORCE > $(call if_changed,fdtoverlay) > $(call multi_depend, $(multi-dtb-y), .dtb, -dtbs) > > +ifneq ($(CHECK_DTBS)$(CHECK_DT_BINDING),) > DT_CHECKER ?= dt-validate > DT_CHECKER_FLAGS ?= $(if $(DT_SCHEMA_FILES),-l $(DT_SCHEMA_FILES),-m) > DT_BINDING_DIR := Documentation/devicetree/bindings > -DT_TMP_SCHEMA ?= $(objtree)/$(DT_BINDING_DIR)/processed-schema.json > +DT_TMP_SCHEMA := $(objtree)/$(DT_BINDING_DIR)/processed-schema.json > > -ifneq ($(CHECK_DTBS)$(CHECK_DT_BINDING),) > quiet_cmd_dtb_check = CHECK $@ > cmd_dtb_check = $(DT_CHECKER) $(DT_CHECKER_FLAGS) -u $(srctree)/$(DT_BINDING_DIR) -p $(DT_TMP_SCHEMA) $@ || true > endif Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds