Received: by 10.192.165.148 with SMTP id m20csp591275imm; Fri, 20 Apr 2018 11:48:50 -0700 (PDT) X-Google-Smtp-Source: AIpwx49lgsJtW2+kP3h4zXCaD462MGV5O5Y3LQ5LtvRznbjVf2/x3QRF7snwpTaTgJuA1LRhoevx X-Received: by 10.99.174.73 with SMTP id e9mr9245132pgp.38.1524250130720; Fri, 20 Apr 2018 11:48:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524250130; cv=none; d=google.com; s=arc-20160816; b=xZemh/tcjnMmjUqYqRBYmOX9JzHYM7Mlgoi9ITMfg1N3+/bEyIKhh30CPjjONoq4a5 k43XL2UuxuJMQvc+u39JmnUtP+2aSaeIbTkFnmy4NFarlBKzZWfV4/A8Xqtna+wcVQo4 BCsgB9PhwtIbDh38GIFwv+c5FYIFjvWSR+hi192k5p8VzWxU0uU6kjX4Ya/tX3Qk7FfS JEvTq5X3o/CzunJHuoh2Vs/nviSPQG4wINvE4k8zYBylBOueWMweYUe3u/fzZGVzoUuD hgFoKCGx1tzVuvkuVrRw+bpD0ia/SCZ19phZ66bd5iqoFopvo+SE4IxVvsdq0+won5sC iJTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dmarc-filter :arc-authentication-results; bh=EyaRvpnMcnvlBkfryU4F1wNZiPc5QT/lCgAhCXS98Bs=; b=iMnQWZvtwRxXnFqHuZNtR7ztov5XF/91BgnoZs1kFMxHE5zCX2DGr2FPXiB8bk0ctZ k6hAFP70vL/6GqE2EYxO+cqVAJaWVk8vI/G3M22tTiWp5dqb2XyojFPs5JcFoGUPyGz8 pEz/imxY5nUKuWPZxTwEyTbo+YQtr7BumNdfEGoy6zeqYgMNC2T5WHTcMJodk5mvSysD UXidvM+duRjp9mBHHbLt2ZNLWT8uPuiV9Ulh4AEfc/v/fU8e+k1zazAkz/iKQIAkKXcF +8eufYkTosGqsRKTiGahE7A7vgcA7m/lwMABZkWlnhrUC+aHUhW7VwvLdP8SiIMlMl/i CBkw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 17si5350287pgh.114.2018.04.20.11.48.35; Fri, 20 Apr 2018 11:48:50 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751169AbeDTSr1 (ORCPT + 99 others); Fri, 20 Apr 2018 14:47:27 -0400 Received: from mail.kernel.org ([198.145.29.99]:44584 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750745AbeDTSrZ (ORCPT ); Fri, 20 Apr 2018 14:47:25 -0400 Received: from mail-qk0-f169.google.com (mail-qk0-f169.google.com [209.85.220.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 1BE7F217D5; Fri, 20 Apr 2018 18:47:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1BE7F217D5 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=robh@kernel.org Received: by mail-qk0-f169.google.com with SMTP id o64so9651588qkl.7; Fri, 20 Apr 2018 11:47:25 -0700 (PDT) X-Gm-Message-State: ALQs6tAIQUMuEvGzbn/V6cNRQsXQNGfuMZVZLhx2SN7B9zOKs4/N06f/ 6qYIv8VYRTMNy2ls8lQ86am1bkADsWFiRR4PJQ== X-Received: by 10.55.153.133 with SMTP id b127mr5706303qke.43.1524250044208; Fri, 20 Apr 2018 11:47:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.163.228 with HTTP; Fri, 20 Apr 2018 11:47:03 -0700 (PDT) In-Reply-To: <20180420165921.GD22369@sirena.org.uk> References: <20180418222905.10414-1-robh@kernel.org> <20180420165921.GD22369@sirena.org.uk> From: Rob Herring Date: Fri, 20 Apr 2018 13:47:03 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH] dt-bindings: add a jsonschema binding example To: Mark Brown Cc: devicetree@vger.kernel.org, devicetree-spec@vger.kernel.org, "linux-kernel@vger.kernel.org" , Grant Likely , Frank Rowand , Mark Rutland , Geert Uytterhoeven , Linus Walleij , Thierry Reding , Shawn Guo , Bjorn Andersson , Arnd Bergmann , Stephen Boyd , Jonathan Cameron 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 20, 2018 at 11:59 AM, Mark Brown wrote: > On Wed, Apr 18, 2018 at 05:29:05PM -0500, Rob Herring wrote: >> The current DT binding documentation format of freeform text is painful >> to write, review, validate and maintain. >> >> This is just an example of what a binding in the schema format looks >> like. It's using jsonschema vocabulary in a YAML encoded document. Using >> jsonschema gives us access to existing tooling. A YAML encoding gives us >> something easy to edit. > > It'd be useful to see some examples of how things like including by > reference other schema work. It feels like something we should be able > to use more in a schema based thing but perhaps that's not viable with > realistic tooling. In general this looks OK, especially with all the > meta comments about the language stripped out. There are several examples in the meta-schema and some of the core schema as references are used there quite a bit. It gets quite fun to follow with recursion. :) I think the need for references in device bindings should be pretty minimal. We'd probably mainly need references for some vendor specific properties which will need to reference some of our compound types. So we'd have something like this: vendor,a-string-array-prop: $ref: "dt-core.yaml#/definitions/proptypes/stringarray" For common bindings, we don't have to reference them in device bindings (which should save lots of boilerplate). We can select and apply them based on presence of properties and that happens independent of the device binding. The device binding only needs define what the common binding cannot which is typically how many elements and what are they. > >> + description: | >> + A variable number of interrupts warrants a description of what conditions > > Like Stephen said the | looks odd. That's just how literal blocks in yaml are done. >> + interrupt-names: >> + # minItems must be specified here because the default would be 2 >> + minItems: 1 >> + items: >> + - const: "tx irq" >> + - const: "rx irq" > > Any way to relate this to the interrupts property in the schema > language (eg, must have the less or equal number of elements)? I've wanted something like that, but there isn't any way that I've come up with. Generally, the "jsonschema way" is each schema is supposed to be independent of each other. There's some discussion about adding data dependent schema which might help in this case. > >> + # Property names starting with '#' must be quoted > > That's awkward :/ Perhaps just by convention quote all property names > for simplicity? Yes, perhaps we should. I have a formatting tool, I'll look into whether i can make it do that. Thanks for taking a look. Rob