Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp1966819ybe; Tue, 3 Sep 2019 06:14:20 -0700 (PDT) X-Google-Smtp-Source: APXvYqzlls1sDkp1VbiRulNunUqVqZyTSKP3TwJfN9w/U1TCUtpSlDVS8FeBmPwVm2HBcM/Y0BaH X-Received: by 2002:a17:902:6b4c:: with SMTP id g12mr34552061plt.118.1567516460634; Tue, 03 Sep 2019 06:14:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567516460; cv=none; d=google.com; s=arc-20160816; b=Od+dA/sB/XeTAYJ2FfRcuA7Wq10gs0E0hI0vRzqSGPxBQ6lrc1FLes7Vq+bQJmpC8+ IDnCRequYAKjWSYvpmzQpmoLsUsgEf08Qud94fPOX6fX2zyhVee+/YTuG8tni2uWES7Z 9huhkp7XPR6TESJX0BFLI1DpoUWQ5fBHI8J9GnKf2DoBfFrIdZbVYCVLywXCt76Z7Fi/ fvbec14iYE33RUwaz2tOxfmdCFbQLXTSM7MLNjJGpnay1x8H63uC9enl+utbzupqGigB kNgTNtTZIZZhWXR4LcuNJW7w1PiLwVTw3KIR3sHFMeNMcDtxuniZwc70pSbTm0eft4+L 8KNQ== 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 :in-reply-to:references:mime-version:dkim-signature; bh=cHD5kuk38evzx+UsD4UkDpYcfEY3/IPMV8n4WfnfyfM=; b=nHiB/gzUYAZVwuaGE3tsR/mR1yS9uCse1RYq1bttvEKzz+IbxnmGlMMFoMeIui4ZET mIIzeF4qxC3iKGmQp0rOdbj6e5vpEZg6N4rchha0GgCJoU5IBEJVj+LnRP34Hp1hgCiG QIlYbknjEtL1g+xxPkL6+KCmhuECScaUe6jLm43NcblmzM61mieMjc/dVHGsraUEsvcf HSgxh4/KBPG5vtwNNsZsy6sGn2woH/ct6A8FYoJqS35e0PjrJZRvrCSAKzCTEY9sQ9Wp UqG6MRUyUO9C+ej9u/kZSGiM+hObWtoSsQ9K0oNvHQwA96NBnbtrIvAl5F/mks+FGlDf xHQw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=1JvYMpco; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g21si4956400pfk.72.2019.09.03.06.13.58; Tue, 03 Sep 2019 06:14:20 -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; dkim=pass header.i=@kernel.org header.s=default header.b=1JvYMpco; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729121AbfICNMz (ORCPT + 99 others); Tue, 3 Sep 2019 09:12:55 -0400 Received: from mail.kernel.org ([198.145.29.99]:52630 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728854AbfICNMz (ORCPT ); Tue, 3 Sep 2019 09:12:55 -0400 Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) (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 3FD152341E; Tue, 3 Sep 2019 13:12:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1567516373; bh=jqh61ZRENXFNnkp2fk/aJ+y/O3Jn9kv3bLoy/qT+bqg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=1JvYMpcor86uiFMCT8PbHaSUcLfTmZZeism41iD+N3okBf2BPcF9BCbTn1OK7W7/P gjkCFKJfRA2pXq9G0VSfhE2ORc4CG8pTFbJ4RWjgovTdbRbNo0wT3tulerFAlV3ejY 1OC4odW3zt77QAPPe1xkfoChFbKXNNSR5+/nKzNI= Received: by mail-qt1-f178.google.com with SMTP id j10so2149719qtp.8; Tue, 03 Sep 2019 06:12:53 -0700 (PDT) X-Gm-Message-State: APjAAAWSedJWg0MQZ+uwW3OlEJMQuw4HlR84Gu6VF1arTRu/xYVlaUo/ c/5u3xRWQXyM+64Rs6lG5PMY8GPOa4F7lDoeDg== X-Received: by 2002:ac8:468c:: with SMTP id g12mr11929246qto.110.1567516372423; Tue, 03 Sep 2019 06:12:52 -0700 (PDT) MIME-Version: 1.0 References: <20190902150336.3600-1-krzk@kernel.org> In-Reply-To: From: Rob Herring Date: Tue, 3 Sep 2019 14:12:40 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/2] dt-bindings: power: syscon-reboot: Convert bindings to json-schema To: Krzysztof Kozlowski Cc: Sebastian Reichel , Mark Rutland , "open list:THERMAL" , devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" 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 Tue, Sep 3, 2019 at 12:44 PM Krzysztof Kozlowski wrote: > > On Tue, 3 Sep 2019 at 11:00, Rob Herring wrote: > > > > On Tue, Sep 3, 2019 at 8:47 AM Krzysztof Kozlowski wrote: > > > > > > On Tue, 3 Sep 2019 at 09:14, Rob Herring wrote: > > > > > > > > On Mon, Sep 2, 2019 at 4:03 PM Krzysztof Kozlowski wrote: > > > > > > > > > > Convert the Syscon reboot bindings to DT schema format using > > > > > json-schema. > > > > > > > > > > Signed-off-by: Krzysztof Kozlowski > > > > > --- > > > > > .../bindings/power/reset/syscon-reboot.txt | 30 -------- > > > > > .../bindings/power/reset/syscon-reboot.yaml | 68 +++++++++++++++++++ > > > > > 2 files changed, 68 insertions(+), 30 deletions(-) > > > > > delete mode 100644 Documentation/devicetree/bindings/power/reset/syscon-reboot.txt > > > > > create mode 100644 Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml > > > > > > > > > diff --git a/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml b/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml > > > > > new file mode 100644 > > > > > index 000000000000..a583f3dc8ef4 > > > > > --- /dev/null > > > > > +++ b/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml > > > > > @@ -0,0 +1,68 @@ > > > > > +# SPDX-License-Identifier: GPL-2.0 > > > > > +%YAML 1.2 > > > > > +--- > > > > > +$id: http://devicetree.org/schemas/power/reset/syscon-reboot.yaml# > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > > + > > > > > +title: Generic SYSCON mapped register reset driver > > > > > + > > > > > +maintainers: > > > > > + - Sebastian Reichel > > > > > + > > > > > +description: |+ > > > > > + This is a generic reset driver using syscon to map the reset register. > > > > > + The reset is generally performed with a write to the reset register > > > > > + defined by the register map pointed by syscon reference plus the offset > > > > > + with the value and mask defined in the reboot node. > > > > > + Default will be little endian mode, 32 bit access only. > > > > > + > > > > > +properties: > > > > > + compatible: > > > > > + const: syscon-reboot > > > > > + > > > > > + mask: > > > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > > > > + description: Update only the register bits defined by the mask (32 bit). > > > > > + maxItems: 1 > > > > > > > > Drop this as that is already defined for uint32. > > > > > > > > It also doesn't actually work. The $ref has to be under an 'allOf' if > > > > you have additional schemas. A quirk of json-schema... > > > > > > > > > + > > > > > + offset: > > > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > > > > + description: Offset in the register map for the reboot register (in bytes). > > > > > + maxItems: 1 > > > > > + > > > > > + regmap: > > > > > + $ref: /schemas/types.yaml#/definitions/phandle > > > > > + description: Phandle to the register map node. > > > > > + maxItems: 1 > > > > > + > > > > > + value: > > > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > > > > + description: The reset value written to the reboot register (32 bit access). > > > > > + maxItems: 1 > > > > > + > > > > > +required: > > > > > + - compatible > > > > > + - regmap > > > > > + - offset > > > > > + > > > > > +allOf: > > > > > + - if: > > > > > + properties: > > > > > + value: > > > > > + not: > > > > > + type: array > > > > > > > > I think you could make this a bit more readable with: > > > > > > > > if: > > > > not: > > > > required: > > > > - value > > > > > > I do not understand how does it work (value is not mentioned in the > > > required fields so why checking of it?)... but it works fine. > > > > What's under required doesn't have to be listed as a property. > > > > > > However, if the tree is free of legacy usage, then you could just drop all this. > > > > > > One of them - mask or value - has to be provided. > > > > Or both, right? > > > > Actually, a better way to express it is probably this: > > > > oneOf: > > - required: [ value ] > > - required: [ mask ] > > - required: [ value, mask ] > > This does not work mask+value would be valid everywhere: > > arch/arm/boot/dts/exynos3250-artik5-eval.dt.yaml: syscon-reboot: > {'regmap': [[9]], 'mask': [[1]], '$nodename': ['syscon-reboot'], > 'value': [[1]], 'offset': [[1024]], 'compatible': ['syscon-reboot']} > is valid under each of {'required': ['mask']}, {'required': ['value', > 'mask']}, {'required': ['value']} Ahh, right. 'anyOf' is what we want: anyOf: - required: [ value ] - required: [ mask ]