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=-4.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS 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 358DAC55183 for ; Tue, 21 Apr 2020 19:03:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1DF6A206D4 for ; Tue, 21 Apr 2020 19:03:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587495792; bh=zzuxna0xb8Q1TdC2MB2c2yaiRdzpJ1eGR8Ub8HY5Gd8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=TyZYvulDRXP8+IfpUKAnPOsJubn24aNR1MKwDQh3TEh9MeXYapRWPr6ykPfzsyq91 i0MKmLUhAjsD97E9iClOdh1LuIwHLnjNvOEOBEmFAt5yhyGZuF5VAYKE3bWpiy4HaF UEMvP48vj4qSupt02xesmDa/9VCA7zT0WTbwjbps= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726115AbgDUTDL (ORCPT ); Tue, 21 Apr 2020 15:03:11 -0400 Received: from mail.kernel.org ([198.145.29.99]:51464 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725994AbgDUTDK (ORCPT ); Tue, 21 Apr 2020 15:03:10 -0400 Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D923420753; Tue, 21 Apr 2020 19:03:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587495790; bh=zzuxna0xb8Q1TdC2MB2c2yaiRdzpJ1eGR8Ub8HY5Gd8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=dlSItZt7NEZM/Xhn8o9UdDSbcwlgfVb8ydhF3rGtNtQmdEl+H3O9net1gHmR12AQ3 G+nGtdiWxr7TRRdz25FX0gFyjfRRj2d0d3nAZzfKyyacT1RN+gE1xH2EmseDfJahAO HBJFoVO2yOmbas1tl76zAhDEBOt9TVZISj3h9NsE= Received: by mail-qk1-f169.google.com with SMTP id l25so15718509qkk.3; Tue, 21 Apr 2020 12:03:09 -0700 (PDT) X-Gm-Message-State: AGi0PuacIsmUZho1o70AvfX0rBBGkgdjDNcYBytD0JGVg92mxT1rhlx1 JVWrR/FalrYZSI+ymleR1fTX6X+E/AAiRVNhRg== X-Google-Smtp-Source: APiQypK4Yv9pvWyQXJx3JdeSn124hpxtt1JLCDuQWjVYKhF0tbCsvIrqP7V2PBuV1TcfREEdndVuo0ZBbnynFvkhgvg= X-Received: by 2002:a37:4a85:: with SMTP id x127mr23060837qka.152.1587495788872; Tue, 21 Apr 2020 12:03:08 -0700 (PDT) MIME-Version: 1.0 References: <06fb6569259bb9183d0a0d0fe70ec4f3033b8aab.1586939718.git.hns@goldelico.com> <20200416204158.GA1006@bogus> In-Reply-To: From: Rob Herring Date: Tue, 21 Apr 2020 14:02:56 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v6 01/12] dt-bindings: add img, pvrsgx.yaml for Imagination GPUs To: "H. Nikolaus Schaller" Cc: devicetree@vger.kernel.org, Thomas Bogendoerfer , Philipp Rossak , David Airlie , OpenPVRSGX Linux Driver Group , "linux-kernel@vger.kernel.org" , dri-devel , "open list:MIPS" , Chen-Yu Tsai , linux-samsung-soc , Daniel Vetter , kernel@pyra-handheld.com, Discussions about the Letux Kernel , linux-omap , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 17, 2020 at 7:16 AM H. Nikolaus Schaller wrote: > > Hi Rob, > > > Am 16.04.2020 um 22:41 schrieb Rob Herring : > > > > On Wed, 15 Apr 2020 10:35:08 +0200, "H. Nikolaus Schaller" wrote: > >> The Imagination PVR/SGX GPU is part of several SoC from > >> multiple vendors, e.g. TI OMAP, Ingenic JZ4780, Intel Poulsbo, > >> Allwinner A83 and others. > >> > >> With this binding, we describe how the SGX processor is > >> interfaced to the SoC (registers, interrupt etc.). > >> > >> In most cases, Clock, Reset and power management is handled > >> by a parent node or elsewhere (e.g. code in the driver). > >> > >> Tested by make dt_binding_check dtbs_check > >> > >> Signed-off-by: H. Nikolaus Schaller > >> --- > >> .../devicetree/bindings/gpu/img,pvrsgx.yaml | 122 ++++++++++++++++++ > >> 1 file changed, 122 insertions(+) > >> create mode 100644 Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml > >> > > > > My bot found errors running 'make dt_binding_check' on your patch: > > > > Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml: while parsing a block mapping > > in "", line 74, column 13 > > It turned out that there was a stray " in line 74 from the last editing phase. > Will be fixed in v7. > > Would it be possible to make dt_binding_check not only report line/column but the > contents of the line instead of ""? This comes from ruamel.yaml module. I believe "" is supposed to be the type of the data, not what it is. However, it is possible to get something a bit more helpful, but it depends on which parser is used. By default we use the C based parser (aka 'safe'). If we use the round trip parser, we get this: ruamel.yaml.scanner.ScannerError: while scanning a simple key in "", line 84, column 5: maxItems ^ (line: 84) This can be enabled by passing '-n' (line numbers) to dt-doc-validate. Currently, you have have to edit the Makefile to do this. The C parser is a big difference in speed, so I don't want to change the default. I can probably work around this and dump the erroring line, but I'm not sure that's always useful. Many errors are indentation related and those need some context. Plus just dumping the line can be done easily with sed: sed -n ${LINE}p Rob