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=-16.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 3FEC8C433FE for ; Tue, 7 Sep 2021 14:45:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2984F610FE for ; Tue, 7 Sep 2021 14:45:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234290AbhIGOqF (ORCPT ); Tue, 7 Sep 2021 10:46:05 -0400 Received: from mail.kernel.org ([198.145.29.99]:44784 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235028AbhIGOqD (ORCPT ); Tue, 7 Sep 2021 10:46:03 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 2D721610F8; Tue, 7 Sep 2021 14:44:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1631025897; bh=pb6uQnkJOj7jZan0UZ5W50IT54400yv6W78lHUUCqDA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=GuVHmRa9F+YxsE7/VqZYKEPDBHgnctH14+lDJxav5wg4mIWlsd4XSaT0FeBdXyY2E Mqty3aIwOvW9OIjveu64e2UvY3NILsfErPO0daYvljrNmkPls+cmqnm+LzDIUSARCI vz5RS0+z+Rk9fAwc85Q7JzaC+oPYJJ9N5QckUU+HzkGBY3zpFl/UrFcQvkYsQVhZDj KQ7aczAbXcRK8GoMUgmaofQYXHnxTM3YaI95CoxIw+20VV6f/iq/+vtje+rvaKLNS9 yYx70IBlL6juOSsJSg/UYadyELkCfKl9pKE93kavxUbf3PSG4KT0WRhKHBnCcHsgbO 4cT0Y1d+YXqxw== Received: by mail-ed1-f46.google.com with SMTP id z19so14245098edi.9; Tue, 07 Sep 2021 07:44:57 -0700 (PDT) X-Gm-Message-State: AOAM53393YKW31UvSuC2XXZCpV6IbRTWCfksOTL8gVaqkYcza7FgOGcu SXwAb9Ua96BusGZYCXAQuKfrsH/nBZ838dmcpg== X-Google-Smtp-Source: ABdhPJz35+eT13PtjAMyE1Cn8up0MviN8dZ3s6bQ7mHM7z/iu5075VVR/KfUXFoatJy0IhBX3jK0MFw2F/aL12TBWMA= X-Received: by 2002:a50:ed09:: with SMTP id j9mr19082569eds.164.1631025895705; Tue, 07 Sep 2021 07:44:55 -0700 (PDT) MIME-Version: 1.0 References: <20210901053951.60952-1-samuel@sholland.org> <20210901053951.60952-2-samuel@sholland.org> <53d6d018-93bf-9bfc-e296-a232105306de@sholland.org> In-Reply-To: <53d6d018-93bf-9bfc-e296-a232105306de@sholland.org> From: Rob Herring Date: Tue, 7 Sep 2021 09:44:43 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 1/7] dt-bindings: rtc: sun6i: Add H616 and R329 compatibles To: Samuel Holland Cc: Maxime Ripard , Chen-Yu Tsai , Jernej Skrabec , Michael Turquette , Stephen Boyd , devicetree@vger.kernel.org, linux-arm-kernel , linux-clk , linux-sunxi@lists.linux.dev, "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 3, 2021 at 10:36 AM Samuel Holland wrote: > > On 9/2/21 10:27 AM, Rob Herring wrote: > > On Wed, Sep 01, 2021 at 12:39:45AM -0500, Samuel Holland wrote: > >> For these new SoCs, start requiring a complete list of input clocks. > >> > >> For H616, this means bus, hosc, and pll-32k. For R329, this means ahb, > >> bus, and hosc; and optionally ext-osc32k. > >> > >> I'm not sure how to best represent this in the binding... > >> > >> Signed-off-by: Samuel Holland > >> --- > >> .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 55 +++++++++++++++++-- > >> include/dt-bindings/clock/sun50i-rtc.h | 12 ++++ > >> 2 files changed, 61 insertions(+), 6 deletions(-) > >> create mode 100644 include/dt-bindings/clock/sun50i-rtc.h > >> > >> diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > >> index beeb90e55727..3e085db1294f 100644 > >> --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > >> +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > >> @@ -26,6 +26,8 @@ properties: > >> - const: allwinner,sun50i-a64-rtc > >> - const: allwinner,sun8i-h3-rtc > >> - const: allwinner,sun50i-h6-rtc > >> + - const: allwinner,sun50i-h616-rtc > >> + - const: allwinner,sun50i-r329-rtc > > > > Can you please make all the single entry cases a single 'enum'. > > > >> > >> reg: > >> maxItems: 1 > >> @@ -37,7 +39,24 @@ properties: > >> - description: RTC Alarm 1 > >> > >> clocks: > >> - maxItems: 1 > >> + minItems: 1 > >> + maxItems: 4 > >> + > >> + clock-names: > >> + minItems: 1 > >> + maxItems: 4 > >> + items: > >> + - anyOf: > > > > This says the first entry is any of these. What about the rest of them? > > Oh, right. The list below is the list of all possible clocks. > > >> + - const: ahb > >> + description: AHB parent for SPI bus clock > > > > The description should go in 'clocks'. > > Will do for v2. > > > The order should be defined as well with the first clock being the > > one that existed previously. > > The only way I know how to further refine the list is with > minItems/maxItems. My problem is that 1) some clocks are only valid for > certain SoCs, and 2) some clocks are optional, depending on how the > board is wired. So there is no single order where the "valid" > combinations are prefixes of the "possible" combinations of clocks. > > Or in other words, how can I say "clocks #1 and #2 from this list are > required, and #4 is optional, but #3 is not allowed"? This says you have up to 4 clocks, but only defines the 1st 2: maxItems: 4 items: - description: 1st clock - description: 2nd clock But I think you will be better off with just defining the range (minItems/maxItems) at the top level and then use if/then schemas. > > Some concrete examples, with the always-required clocks moved to the > beginning: > > H6: > - bus: required > - hosc: required > - ahb: not allowed > - ext-osc32k: optional > - pll-32k: not allowed Is this really 2 different 32k clock inputs to the h/w block? Doesn't seem like it given both are never valid. > > H616: > - bus: required > - hosc: required > - ahb: not allowed > - ext-osc32k: not allowed > - pll-32k: required > > R329: > - bus: required > - hosc: required > - ahb: required > - ext-osc32k: optional > - pll-32k: not allowed > > Should I just move the entire clocks/clock-items properties to if/then > blocks based on the compatible? Probably so. Rob From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BF8E372 for ; Tue, 7 Sep 2021 14:44:57 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 37B0661106 for ; Tue, 7 Sep 2021 14:44:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1631025897; bh=pb6uQnkJOj7jZan0UZ5W50IT54400yv6W78lHUUCqDA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=GuVHmRa9F+YxsE7/VqZYKEPDBHgnctH14+lDJxav5wg4mIWlsd4XSaT0FeBdXyY2E Mqty3aIwOvW9OIjveu64e2UvY3NILsfErPO0daYvljrNmkPls+cmqnm+LzDIUSARCI vz5RS0+z+Rk9fAwc85Q7JzaC+oPYJJ9N5QckUU+HzkGBY3zpFl/UrFcQvkYsQVhZDj KQ7aczAbXcRK8GoMUgmaofQYXHnxTM3YaI95CoxIw+20VV6f/iq/+vtje+rvaKLNS9 yYx70IBlL6juOSsJSg/UYadyELkCfKl9pKE93kavxUbf3PSG4KT0WRhKHBnCcHsgbO 4cT0Y1d+YXqxw== Received: by mail-ed1-f54.google.com with SMTP id g8so13019590edt.7 for ; Tue, 07 Sep 2021 07:44:57 -0700 (PDT) X-Gm-Message-State: AOAM532wJ6YVwFoywQFDLSsriYUoouCRTKOOJs9IFeYHHpFKamNGOWew MqK03QZ8sOrAMOw32EbmBVylczaPvv6CjWamDA== X-Google-Smtp-Source: ABdhPJz35+eT13PtjAMyE1Cn8up0MviN8dZ3s6bQ7mHM7z/iu5075VVR/KfUXFoatJy0IhBX3jK0MFw2F/aL12TBWMA= X-Received: by 2002:a50:ed09:: with SMTP id j9mr19082569eds.164.1631025895705; Tue, 07 Sep 2021 07:44:55 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20210901053951.60952-1-samuel@sholland.org> <20210901053951.60952-2-samuel@sholland.org> <53d6d018-93bf-9bfc-e296-a232105306de@sholland.org> In-Reply-To: <53d6d018-93bf-9bfc-e296-a232105306de@sholland.org> From: Rob Herring Date: Tue, 7 Sep 2021 09:44:43 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 1/7] dt-bindings: rtc: sun6i: Add H616 and R329 compatibles To: Samuel Holland Cc: Maxime Ripard , Chen-Yu Tsai , Jernej Skrabec , Michael Turquette , Stephen Boyd , devicetree@vger.kernel.org, linux-arm-kernel , linux-clk , linux-sunxi@lists.linux.dev, "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" On Fri, Sep 3, 2021 at 10:36 AM Samuel Holland wrote: > > On 9/2/21 10:27 AM, Rob Herring wrote: > > On Wed, Sep 01, 2021 at 12:39:45AM -0500, Samuel Holland wrote: > >> For these new SoCs, start requiring a complete list of input clocks. > >> > >> For H616, this means bus, hosc, and pll-32k. For R329, this means ahb, > >> bus, and hosc; and optionally ext-osc32k. > >> > >> I'm not sure how to best represent this in the binding... > >> > >> Signed-off-by: Samuel Holland > >> --- > >> .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 55 +++++++++++++++++-- > >> include/dt-bindings/clock/sun50i-rtc.h | 12 ++++ > >> 2 files changed, 61 insertions(+), 6 deletions(-) > >> create mode 100644 include/dt-bindings/clock/sun50i-rtc.h > >> > >> diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > >> index beeb90e55727..3e085db1294f 100644 > >> --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > >> +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > >> @@ -26,6 +26,8 @@ properties: > >> - const: allwinner,sun50i-a64-rtc > >> - const: allwinner,sun8i-h3-rtc > >> - const: allwinner,sun50i-h6-rtc > >> + - const: allwinner,sun50i-h616-rtc > >> + - const: allwinner,sun50i-r329-rtc > > > > Can you please make all the single entry cases a single 'enum'. > > > >> > >> reg: > >> maxItems: 1 > >> @@ -37,7 +39,24 @@ properties: > >> - description: RTC Alarm 1 > >> > >> clocks: > >> - maxItems: 1 > >> + minItems: 1 > >> + maxItems: 4 > >> + > >> + clock-names: > >> + minItems: 1 > >> + maxItems: 4 > >> + items: > >> + - anyOf: > > > > This says the first entry is any of these. What about the rest of them? > > Oh, right. The list below is the list of all possible clocks. > > >> + - const: ahb > >> + description: AHB parent for SPI bus clock > > > > The description should go in 'clocks'. > > Will do for v2. > > > The order should be defined as well with the first clock being the > > one that existed previously. > > The only way I know how to further refine the list is with > minItems/maxItems. My problem is that 1) some clocks are only valid for > certain SoCs, and 2) some clocks are optional, depending on how the > board is wired. So there is no single order where the "valid" > combinations are prefixes of the "possible" combinations of clocks. > > Or in other words, how can I say "clocks #1 and #2 from this list are > required, and #4 is optional, but #3 is not allowed"? This says you have up to 4 clocks, but only defines the 1st 2: maxItems: 4 items: - description: 1st clock - description: 2nd clock But I think you will be better off with just defining the range (minItems/maxItems) at the top level and then use if/then schemas. > > Some concrete examples, with the always-required clocks moved to the > beginning: > > H6: > - bus: required > - hosc: required > - ahb: not allowed > - ext-osc32k: optional > - pll-32k: not allowed Is this really 2 different 32k clock inputs to the h/w block? Doesn't seem like it given both are never valid. > > H616: > - bus: required > - hosc: required > - ahb: not allowed > - ext-osc32k: not allowed > - pll-32k: required > > R329: > - bus: required > - hosc: required > - ahb: required > - ext-osc32k: optional > - pll-32k: not allowed > > Should I just move the entire clocks/clock-items properties to if/then > blocks based on the compatible? Probably so. Rob 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=-14.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 E4F1AC433EF for ; Tue, 7 Sep 2021 14:47:07 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 AE6476109F for ; Tue, 7 Sep 2021 14:47:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org AE6476109F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=HPnXPksC8Rfvm+JDVjGiEIySPCGYnUzi4e+GgjSweOs=; b=NCY/kIAJFa0ule RNKQk/lfpeW7PlI2KNQVxEVLP+qFJtPCJ76vzbBpp9xnBG0aRktjURuGbD6uQZDTik4alviAl3Huo iWERv8rB4m12Tp5VRuFd2V0TraX6pbJOgegnR+agK+qXjk/opFYm50/meoMNU1S2hUDdlwgBih9wJ Qw12l5Qcjosfnb9GvMrShW3kSjgqGQN+jDDLo9fwbnF8Be4F6D1RhdkiaYmKkDwvF0SARwqxHwMB1 Q7JlxJBVseXhoHFaXDoa6+y9KNytv8DPbMq237MAONJ2ypOfhvvCsubXKYZ2f3hoYKmvszedPuuJm twgJOiu7ag3A0sE5vacA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mNcLO-003uMC-G5; Tue, 07 Sep 2021 14:45:02 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mNcLJ-003uL8-Mf for linux-arm-kernel@lists.infradead.org; Tue, 07 Sep 2021 14:44:59 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 31C6F61104 for ; Tue, 7 Sep 2021 14:44:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1631025897; bh=pb6uQnkJOj7jZan0UZ5W50IT54400yv6W78lHUUCqDA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=GuVHmRa9F+YxsE7/VqZYKEPDBHgnctH14+lDJxav5wg4mIWlsd4XSaT0FeBdXyY2E Mqty3aIwOvW9OIjveu64e2UvY3NILsfErPO0daYvljrNmkPls+cmqnm+LzDIUSARCI vz5RS0+z+Rk9fAwc85Q7JzaC+oPYJJ9N5QckUU+HzkGBY3zpFl/UrFcQvkYsQVhZDj KQ7aczAbXcRK8GoMUgmaofQYXHnxTM3YaI95CoxIw+20VV6f/iq/+vtje+rvaKLNS9 yYx70IBlL6juOSsJSg/UYadyELkCfKl9pKE93kavxUbf3PSG4KT0WRhKHBnCcHsgbO 4cT0Y1d+YXqxw== Received: by mail-ed1-f49.google.com with SMTP id q3so14291609edt.5 for ; Tue, 07 Sep 2021 07:44:57 -0700 (PDT) X-Gm-Message-State: AOAM530ppHXFRfjSW/s9xhsjSF6lZTCGOAcVcUsHYMD6uHnTP1RkB1Ub 96sTLPthbjnRFIsUj4OTMdG5MEuiOFjarb8tig== X-Google-Smtp-Source: ABdhPJz35+eT13PtjAMyE1Cn8up0MviN8dZ3s6bQ7mHM7z/iu5075VVR/KfUXFoatJy0IhBX3jK0MFw2F/aL12TBWMA= X-Received: by 2002:a50:ed09:: with SMTP id j9mr19082569eds.164.1631025895705; Tue, 07 Sep 2021 07:44:55 -0700 (PDT) MIME-Version: 1.0 References: <20210901053951.60952-1-samuel@sholland.org> <20210901053951.60952-2-samuel@sholland.org> <53d6d018-93bf-9bfc-e296-a232105306de@sholland.org> In-Reply-To: <53d6d018-93bf-9bfc-e296-a232105306de@sholland.org> From: Rob Herring Date: Tue, 7 Sep 2021 09:44:43 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 1/7] dt-bindings: rtc: sun6i: Add H616 and R329 compatibles To: Samuel Holland Cc: Maxime Ripard , Chen-Yu Tsai , Jernej Skrabec , Michael Turquette , Stephen Boyd , devicetree@vger.kernel.org, linux-arm-kernel , linux-clk , linux-sunxi@lists.linux.dev, "linux-kernel@vger.kernel.org" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210907_074457_811156_C3AFC465 X-CRM114-Status: GOOD ( 36.25 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Sep 3, 2021 at 10:36 AM Samuel Holland wrote: > > On 9/2/21 10:27 AM, Rob Herring wrote: > > On Wed, Sep 01, 2021 at 12:39:45AM -0500, Samuel Holland wrote: > >> For these new SoCs, start requiring a complete list of input clocks. > >> > >> For H616, this means bus, hosc, and pll-32k. For R329, this means ahb, > >> bus, and hosc; and optionally ext-osc32k. > >> > >> I'm not sure how to best represent this in the binding... > >> > >> Signed-off-by: Samuel Holland > >> --- > >> .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 55 +++++++++++++++++-- > >> include/dt-bindings/clock/sun50i-rtc.h | 12 ++++ > >> 2 files changed, 61 insertions(+), 6 deletions(-) > >> create mode 100644 include/dt-bindings/clock/sun50i-rtc.h > >> > >> diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > >> index beeb90e55727..3e085db1294f 100644 > >> --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > >> +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > >> @@ -26,6 +26,8 @@ properties: > >> - const: allwinner,sun50i-a64-rtc > >> - const: allwinner,sun8i-h3-rtc > >> - const: allwinner,sun50i-h6-rtc > >> + - const: allwinner,sun50i-h616-rtc > >> + - const: allwinner,sun50i-r329-rtc > > > > Can you please make all the single entry cases a single 'enum'. > > > >> > >> reg: > >> maxItems: 1 > >> @@ -37,7 +39,24 @@ properties: > >> - description: RTC Alarm 1 > >> > >> clocks: > >> - maxItems: 1 > >> + minItems: 1 > >> + maxItems: 4 > >> + > >> + clock-names: > >> + minItems: 1 > >> + maxItems: 4 > >> + items: > >> + - anyOf: > > > > This says the first entry is any of these. What about the rest of them? > > Oh, right. The list below is the list of all possible clocks. > > >> + - const: ahb > >> + description: AHB parent for SPI bus clock > > > > The description should go in 'clocks'. > > Will do for v2. > > > The order should be defined as well with the first clock being the > > one that existed previously. > > The only way I know how to further refine the list is with > minItems/maxItems. My problem is that 1) some clocks are only valid for > certain SoCs, and 2) some clocks are optional, depending on how the > board is wired. So there is no single order where the "valid" > combinations are prefixes of the "possible" combinations of clocks. > > Or in other words, how can I say "clocks #1 and #2 from this list are > required, and #4 is optional, but #3 is not allowed"? This says you have up to 4 clocks, but only defines the 1st 2: maxItems: 4 items: - description: 1st clock - description: 2nd clock But I think you will be better off with just defining the range (minItems/maxItems) at the top level and then use if/then schemas. > > Some concrete examples, with the always-required clocks moved to the > beginning: > > H6: > - bus: required > - hosc: required > - ahb: not allowed > - ext-osc32k: optional > - pll-32k: not allowed Is this really 2 different 32k clock inputs to the h/w block? Doesn't seem like it given both are never valid. > > H616: > - bus: required > - hosc: required > - ahb: not allowed > - ext-osc32k: not allowed > - pll-32k: required > > R329: > - bus: required > - hosc: required > - ahb: required > - ext-osc32k: optional > - pll-32k: not allowed > > Should I just move the entire clocks/clock-items properties to if/then > blocks based on the compatible? Probably so. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel