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=-3.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 49669C2BA2B for ; Mon, 6 Apr 2020 19:29:19 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2497E206C3 for ; Mon, 6 Apr 2020 19:29:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="kesdoxmk" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2497E206C3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id A4D436E0E3; Mon, 6 Apr 2020 19:29:18 +0000 (UTC) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by gabe.freedesktop.org (Postfix) with ESMTPS id 358616E0E3 for ; Mon, 6 Apr 2020 19:29:17 +0000 (UTC) Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) (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 3278F2072F for ; Mon, 6 Apr 2020 19:19:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586200793; bh=zdj7yojVhBaB/Gk/gXB9gngRJZ5TCmP70WrifeTeWPo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=kesdoxmkVgj2Dqv1tQt4fCw9H0dMsOgGP9qPRjv6lxpDGHTZFQ1uelps6tnsNLOnV 9nh0Bo+fqKkQzQGZ419+d2v7FAG5G+QsZIATy+uKnjZeOBlQSb+tW7Q+Cgyo0nqrRD y8IuKO4hOpB0d8gYWFzx/ahsF9E58viGQiCokusg= Received: by mail-qt1-f182.google.com with SMTP id b10so714317qtt.9 for ; Mon, 06 Apr 2020 12:19:53 -0700 (PDT) X-Gm-Message-State: AGi0PuZNW4IwPtZBGFwJ8Q8jYAglxNYdejlvPA/p7LjUxt3h48VyxzYI smj9mH7mstOZUCAc4A5TGsFBZyRbWK/FB5NC8g== X-Google-Smtp-Source: APiQypJ1VgDGdNpHhWosDRaYn1Rfz/zEmplt4aAY7f96THP6EXWe5/sr8OVtCQdWt8FkwVCSRsBVmdwCf83I3b/uFa0= X-Received: by 2002:ac8:2668:: with SMTP id v37mr1115420qtv.143.1586200792283; Mon, 06 Apr 2020 12:19:52 -0700 (PDT) MIME-Version: 1.0 References: <20200405232318.26833-1-laurent.pinchart+renesas@ideasonboard.com> <20200405232318.26833-5-laurent.pinchart+renesas@ideasonboard.com> <20200406110924.GB4757@pendragon.ideasonboard.com> In-Reply-To: From: Rob Herring Date: Mon, 6 Apr 2020 13:19:40 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 4/4] dt-bindings: display: bridge: renesas,lvds: Convert binding to YAML To: Geert Uytterhoeven X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Laurent Pinchart , DRI Development , Linux-Renesas , Jacopo Mondi , Laurent Pinchart , Maxime Ripard Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Mon, Apr 6, 2020 at 5:40 AM Geert Uytterhoeven wrote: > > Hi Laurent, > > On Mon, Apr 6, 2020 at 1:09 PM Laurent Pinchart > wrote: > > On Mon, Apr 06, 2020 at 10:47:37AM +0200, Geert Uytterhoeven wrote: > > > On Mon, Apr 6, 2020 at 1:24 AM Laurent Pinchart wrote: > > > > Convert the Renesas R-Car LVDS encoder text binding to YAML. > > > > > > > > Signed-off-by: Laurent Pinchart > > > > > +if: > > > > + properties: > > > > + compatible: > > > > + enum: > > > > + - renesas,r8a774c0-lvds > > > > + - renesas,r8a77990-lvds > > > > + - renesas,r8a77995-lvds > > > > +then: > > > > + properties: > > > > + clocks: > > > > + minItems: 1 > > > > + maxItems: 4 > > > > + items: > > > > + - description: Functional clock > > > > + - description: EXTAL input clock > > > > + - description: DU_DOTCLKIN0 input clock > > > > + - description: DU_DOTCLKIN1 input clock > > > > + > > > > + clock-names: > > > > + minItems: 1 > > > > + maxItems: 4 > > > > + items: > > > > + - const: fck > > > > + # The LVDS encoder can use the EXTAL or DU_DOTCLKINx clocks. > > > > + # These clocks are optional. > > > > + - enum: > > > > + - extal > > > > + - dclkin.0 > > > > + - dclkin.1 > > > > + - enum: > > > > + - extal > > > > + - dclkin.0 > > > > + - dclkin.1 > > > > + - enum: > > > > + - extal > > > > + - dclkin.0 > > > > + - dclkin.1 > > > > > > Can the duplication of the last 3 entries be avoided? > > > Perhaps like in > > > Documentation/devicetree/bindings/serial/renesas,scif.yaml? > > > > I'd love to, if you can tell me how to make sure the fck entry is > > mandatory. The following > > > > minItems: 1 > > maxItems: 4 > > items: > > enum: > > - fck > > - extal > > - dclkin.0 > > - dclkin.1 > > > > passes the checks, but would accept > > > > clock-names = "extal"; > > > > which is not valid. Your > > Documentation/devicetree/bindings/serial/renesas,scif.yaml bindings > > suffer from the same problem :-) > > Hmm.... > > > > > +examples: > > > > + - | > > > > + #include > > > > + #include > > > > + > > > > + lvds@feb90000 { > > > > + compatible = "renesas,r8a7795-lvds"; > > > > + reg = <0 0xfeb90000 0 0x14>; > > > > > > Examples are built with #{address,size}-cells = <1>. > > > > Are they ? I don't get any failure from make dt_binding_check. > > Hmm... And you do have "reg: maxItems: 1"... At first glance I was expecting an error too, but there isn't. As far as the schema is concerned, it's valid because it's a single entry (i.e. one entry in <>). And then dtc can only check that reg is a multiple of 2. The size check does work where we have more constraints like I2C. If we enforce bracketing, then we should be able to check these. Otherwise, knowing both the cell sizes and number of entries is a problem. With bracketing, we can split those checks. I'd been thinking checking cell sizes would be easier in dtc (we're already doing that in lots of cases), but thinking about it some more there is a way to do this with schema: if: properties: '#address-cells': const: 2 '#size-cells': const: 2 required: - '#address-cells' - '#size-cells' then: patternProperties: '@': properties: reg: items: minItems: 4 maxItems: 4 required: - reg ...and copy-n-paste for each size combination. I imagine implementing this will result in another set of fixes. Rob _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel