Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp6490069ybl; Wed, 15 Jan 2020 05:36:01 -0800 (PST) X-Google-Smtp-Source: APXvYqzXFlk6Wd+Wy+B/vcZl9/l0hDtG8GKx6xmqGHvrDzrmqX4Pn+Qf2pT+scjNpMdJFTzqS0n2 X-Received: by 2002:a9d:67ce:: with SMTP id c14mr2681627otn.106.1579095360907; Wed, 15 Jan 2020 05:36:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579095360; cv=none; d=google.com; s=arc-20160816; b=L54SrE7n1tS1NzabHV1dYfmT96Wk3Pqr0OWvqqMe8JEva+KtwRO5UrGioTdU/t5Twy BB2y+9qXjKCbOiqcElqfbjUxlVIneKOCnQvq1tYuks2lvr/Y8kLPgY9u8cfWaqgoXAFQ ZqQp9eEkjN6oh9AG68KD2MhJfxBuvwP6zCyU4BbM4OEGAJFJWHj2RYvpFcMxKWGW2wjv dI4gua17IJg6KUDRzt23+NRUZScbuIxKRP0MGmNWRC/XkdPCzCcJ6M9y6u0+cGODqQjW oTZSTJNXKMEL14DZuakQFFMYR1y7JvTmK8bWUmXLKaxlnvPWA9IRroYh5VQ+Q0BNVoPK DNBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=U+zx4gXScyllawgjqtzwHFpsgDj3TweStrajWX6U4lk=; b=lPZl0fqYnqyD9DgehgQChHF5DoKY7NtmvQYTv7bBH1kIFM0KRrJC6FrJD4e2FNPGwp tTfddntu2B1l3lWdFbDPKNrJgYx3C6xlKgFdIMyzYMPv35aIWgdS2pXkO1SuUZLNE1zh I6hTEMw06vpr4tT8guaCvJMALXvuMs8JNvt9yU0jGSgyhxUvVQKMGHyrW3WtL331R0KU wR2Y4SQ/cJsbxsiDefRahu2+OaCQ/wIpKZ5e6WS2P35vrM4v9UkLsmjkKlZilxw57wrq 1i6ZoNAZluCXuCslfPEWQPSPbdBfeqjLUc/V3NyL8hXIdnh3f8CWMqKQA51taaQ26dFg VKrQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@st.com header.s=STMicroelectronics header.b=FNDhIYJu; 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=st.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y3si10598272oto.98.2020.01.15.05.35.47; Wed, 15 Jan 2020 05:36:00 -0800 (PST) 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=@st.com header.s=STMicroelectronics header.b=FNDhIYJu; 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=st.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728998AbgAONeq (ORCPT + 99 others); Wed, 15 Jan 2020 08:34:46 -0500 Received: from mx07-00178001.pphosted.com ([62.209.51.94]:44889 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726248AbgAONep (ORCPT ); Wed, 15 Jan 2020 08:34:45 -0500 Received: from pps.filterd (m0046037.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 00FDX6Ud010870; Wed, 15 Jan 2020 14:34:14 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=st.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=STMicroelectronics; bh=U+zx4gXScyllawgjqtzwHFpsgDj3TweStrajWX6U4lk=; b=FNDhIYJuuE0MxSyYk6SryKZVpGcOMC1NWoG+5BzIl3S9TSdO2528VA/8hyITvFNJDlbh l+rWOkFKVorzxRaEp70TzGUTuTLw/UKEFS8+OYAxkXQiuV55BSSFJ06og+nT6u7CFGPT C4ypYsNXRL5bzlAKN0cXoXBLcXpUUAld4M9FYf48BVJApS4anzsScdGaRQvTUs+SNGjY 8RMvy+K7UzRXhmgguBMhCxovYpk5wXdfV2e7yPQ65fWoVxW+5o4S0vCjoRwhwARtcpxk bXC9D/lGIS87QoJPd3faLQBiFhjB5ALRsF2Xd4QGwD8NBsTH26Az8dwTmIM+3x1mKmd7 7A== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com with ESMTP id 2xf7fnuat1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Jan 2020 14:34:14 +0100 Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id AAEFA10002A; Wed, 15 Jan 2020 14:34:12 +0100 (CET) Received: from Webmail-eu.st.com (sfhdag5node3.st.com [10.75.127.15]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 8E66721ECEF; Wed, 15 Jan 2020 14:34:12 +0100 (CET) Received: from [10.48.0.71] (10.75.127.47) by SFHDAG5NODE3.st.com (10.75.127.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 15 Jan 2020 14:34:11 +0100 Subject: Re: [PATCH v2] dt-bindings: iio: adc: stm32-adc: convert bindings to json-schema To: Rob Herring CC: Jonathan Cameron , Alexandre Torgue , Mark Rutland , Maxime Coquelin , Lars-Peter Clausen , Hartmut Knaack , Peter Meerwald , olivier moysan , "open list:IIO SUBSYSTEM AND DRIVERS" , , , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , "linux-kernel@vger.kernel.org" References: <1575649028-10909-1-git-send-email-fabrice.gasnier@st.com> <20191217234345.GA7738@bogus> From: Fabrice Gasnier Message-ID: Date: Wed, 15 Jan 2020 14:34:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.75.127.47] X-ClientProxiedBy: SFHDAG4NODE2.st.com (10.75.127.11) To SFHDAG5NODE3.st.com (10.75.127.15) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138,18.0.572 definitions=2020-01-15_02:2020-01-15,2020-01-15 signatures=0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/14/20 8:20 PM, Rob Herring wrote: > On Tue, Jan 14, 2020 at 10:02 AM Fabrice Gasnier wrote: >> >> On 12/18/19 12:43 AM, Rob Herring wrote: >>> On Fri, Dec 06, 2019 at 05:17:08PM +0100, Fabrice Gasnier wrote: >>>> Convert the STM32 ADC binding to DT schema format using json-schema >>>> >>>> Signed-off-by: Fabrice Gasnier >>>> --- >>>> Note: this applies on top of IIO tree currently (iio-for-5.5c). >>>> >>>> Changes in V2: >>>> - Take almost all of Rob suggestions (removed reg generic description, >>>> added minItems, maxItems, st,max-clk-rate-hz range, drop some pipes, >>>> simplify clock-names, remove unneeded allOfs) >>>> - For now, keep all in one file despite there are lots of if/thens in the >>>> bindings >>>> --- >>>> .../devicetree/bindings/iio/adc/st,stm32-adc.txt | 149 ------- >>>> .../devicetree/bindings/iio/adc/st,stm32-adc.yaml | 454 +++++++++++++++++++++ >>>> 2 files changed, 454 insertions(+), 149 deletions(-) >>>> delete mode 100644 Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt >>>> create mode 100644 Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml >>> >>> >> >> >> [snip] >> >>>> + >>>> + st,adc-channels: >>>> + description: | >>>> + List of single-ended channels muxed for this ADC. It can have up to: >>>> + - 16 channels, numbered from 0 to 15 (for in0..in15) on stm32f4 >>>> + - 20 channels, numbered from 0 to 19 (for in0..in19) on stm32h7 and >>>> + stm32mp1. >>>> + allOf: >>>> + - $ref: /schemas/types.yaml#/definitions/uint32-array >>>> + >> >> [snip] >> >>>> + >>>> + allOf: >>>> + - if: >>>> + properties: >>>> + compatible: >>>> + contains: >>>> + const: st,stm32f4-adc >>>> + >>>> + then: >>>> + properties: >>>> + reg: >>>> + enum: >>>> + - 0x0 >>>> + - 0x100 >>>> + - 0x200 >>>> + >>>> + interrupts: >>>> + minimum: 0 >>>> + maximum: 2 >>>> + >>>> + assigned-resolution-bits: >>>> + enum: [6, 8, 10, 12] >>>> + default: 12 >>>> + >>>> + st,adc-channels: >>>> + minItems: 1 >>>> + maxItems: 16 >>>> + minimum: 0 >>>> + maximum: 15 >>> >>> You are mixing array and scalar constraints here. You need: >>> >>> minItems: 1 >>> maxItems:16 >>> items: >>> minimum: 0 >>> maximum: 15 >>> >>> Update dtschema. It will now catch this. There's a few others too. >> >> Hi Rob, >> >> Sorry for the late reply. I updated dtschema. Now it catches it. >> >> I've tried your suggestion, but when I test it, I don't get any error on >> maxItems. >> >> In the example: "st,adc-channels = <0>, <1>, ... more than 16 items;" >> >> Is it possible I face some other issue with dtschema ? > > The problem is how "<0>, <1>" vs. "<0 1>" gets encoded. While those > are the same in the dtb, in yaml we have "[[0], [1]]" vs. "[[0, 1]]". > Making the brackets significant is helpful for some things like > phandle+args and 'reg' where we have a matrix of values, but for > arrays it just gets in the way. I think as I suggested is the right > form for the binding schema, and we need to either decide what's the > correct way for brackets or improve the tool to accept both ways. Hi Rob, Thanks for the quick answer and clarification. I'll adopt the way you suggest in V3 (the dts files already use <0 1...> syntax). I'll also update the example in the bindings to use it, to point the right form. Thanks, Fabrice > > Rob >