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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 94D15C00140 for ; Fri, 12 Aug 2022 13:49:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238042AbiHLNtD (ORCPT ); Fri, 12 Aug 2022 09:49:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36806 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237168AbiHLNs7 (ORCPT ); Fri, 12 Aug 2022 09:48:59 -0400 Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7E102A407D for ; Fri, 12 Aug 2022 06:48:55 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id r17so1400799lfm.11 for ; Fri, 12 Aug 2022 06:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc; bh=C60Y/Psn2DfbYSl6cZKqaTCQ7Sgqzh8lKtssMlfhgdo=; b=pWbMOWv12SncgQnIuIVOZIuOGhZs9m4NIgAH4gt6ZLQlOYjrJkkrpfmGlGCsIisBzI x/v8DlJwMigklZslZraUmAV3o3EudTu6miObF37SapiaOyQ7qROqopSG36e739kWIR7w JJD6EAb9D0Wzj4lYQx6qyLJVCE8AOvJfpDEYCmPZeUn+tmgP3zoa9TCJ3qI4TQidCQzh A3WWOzYXKKX64DYzpcg9y635CEsUDPsNh/89xvbckuKi0dbRGta8wpqRK3MSOwQcj2ka jioKGTP+gwvfVng2HwS+LbU1WM/BicwUT0gtxiXvDGzrnx51rOIp5qDvT7EuLpFj65Eq 45Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc; bh=C60Y/Psn2DfbYSl6cZKqaTCQ7Sgqzh8lKtssMlfhgdo=; b=0JgnRWzkuU8U6IxWwz95LX4ZJUkznvXjol902Hv6jSzm6LGkTf5WVFOS7fhB6araJk 33oKtvh6ax1A++eYlhfXzYrWIdgaePv55KzMlaS8k7NLPI2vADJJnzb/oqeye/Q1ytAm Y1QewqgZdWOApSmNpOAI78wwS8uV6qbPEbvyARHDzlYvRmS6/8vHvRefR6IezLwTu0ZY BnJj3gf+w9+IVY+Lhr3O5MzUAzigQggiEllm390G6LB+2FdoPfbGPjKbc8KvhPscXVyr UqyzM3BrIZ3GEJ+dXl/Qz7SSCXwdpuykSNlzoRfsE8mYEwXBmwMFSr2/7f0JR1JMacJ6 3zTQ== X-Gm-Message-State: ACgBeo0H6BIZa43KzjWn1FzC4MRXAe1jOKGEvqbmzOWS6T7YXQjjtIfQ jqI9iWtZExNuAaPIZaXJKOS7ng== X-Google-Smtp-Source: AA6agR64G+c5wbFPsOJpNw8i8kydU4HW7gKVfY0L7wZs/5J9GKNtG7Gd/wPYjnf5eFU18oI1+UgbUQ== X-Received: by 2002:a05:6512:1155:b0:48a:fb9a:32d8 with SMTP id m21-20020a056512115500b0048afb9a32d8mr1340962lfg.672.1660312133710; Fri, 12 Aug 2022 06:48:53 -0700 (PDT) Received: from [192.168.1.39] ([83.146.140.105]) by smtp.gmail.com with ESMTPSA id b19-20020ac24113000000b0048b03d1ca4asm221323lfi.161.2022.08.12.06.48.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Aug 2022 06:48:53 -0700 (PDT) Message-ID: <3731cd56-f7e8-6807-06b5-b8b176b078b6@linaro.org> Date: Fri, 12 Aug 2022 16:48:43 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: [PATCH 4/4] dt-bindings: net: dsa: mediatek,mt7530: update json-schema Content-Language: en-US To: =?UTF-8?B?QXLEsW7DpyDDnE5BTA==?= , Andrew Lunn , Vivien Didelot , Florian Fainelli , Vladimir Oltean , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , Matthias Brugger , Sean Wang , Landen Chao , DENG Qingfang , Frank Wunderlich , Luiz Angelo Daros de Luca , Sander Vanheule , =?UTF-8?Q?Ren=c3=a9_van_Dorst?= , Daniel Golle , erkin.bozoglu@xeront.com, Sergio Paracuellos Cc: netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org References: <20220730142627.29028-1-arinc.unal@arinc9.com> <20220730142627.29028-5-arinc.unal@arinc9.com> <8a665b7a-bbd0-99ce-658e-bc78568bdca2@linaro.org> <40130c63-1e36-bb43-43b4-444a8f287226@linaro.org> <70e246af-c336-0896-95b5-9e42a17a239d@arinc9.com> From: Krzysztof Kozlowski In-Reply-To: <70e246af-c336-0896-95b5-9e42a17a239d@arinc9.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/08/2022 16:41, Arınç ÜNAL wrote: > On 12.08.2022 10:01, Krzysztof Kozlowski wrote: >> On 12/08/2022 09:57, Krzysztof Kozlowski wrote: >>> On 12/08/2022 01:09, Arınç ÜNAL wrote: >>>>>> -patternProperties: >>>>>> - "^(ethernet-)?ports$": >>>>>> - type: object >>>>> >>>>> Actually four patches... >>>>> >>>>> I don't find this change explained in commit msg. What is more, it looks >>>>> incorrect. All properties and patternProperties should be explained in >>>>> top-level part. >>>>> >>>>> Defining such properties (with big piece of YAML) in each if:then: is no >>>>> readable. >>>> >>>> I can't figure out another way. I need to require certain properties for >>>> a compatible string AND certain enum/const for certain properties which >>>> are inside patternProperties for "^(ethernet-)?port@[0-9]+$" by reading >>>> the compatible string. >>> >>> requiring properties is not equal to defining them and nothing stops you >>> from defining all properties top-level and requiring them in >>> allOf:if:then:patternProperties. >>> >>> >>>> If I put allOf:if:then under patternProperties, I can't do the latter. >>> >>> You can. > > Am I supposed to do something like this: > > patternProperties: > "^(ethernet-)?ports$": > type: object > > patternProperties: > "^(ethernet-)?port@[0-9]+$": > type: object > description: Ethernet switch ports > > unevaluatedProperties: false > > properties: > reg: > description: > Port address described must be 5 or 6 for CPU port and > from 0 to 5 for user ports. > > allOf: > - $ref: dsa-port.yaml# > - if: > properties: > label: > items: > - const: cpu > then: > allOf: > - if: > properties: Not really, this is absolutely unreadable. Usually the way it is handled is: patternProperties: "^(ethernet-)?ports$": type: object patternProperties: "^(ethernet-)?port@[0-9]+$": type: object description: Ethernet switch ports unevaluatedProperties: false ... regular stuff follows allOf: - if: properties: compatible: ..... then: patternProperties: "^(ethernet-)?ports$": patternProperties: "^(ethernet-)?port@[0-9]+$": properties: reg: const: 5 I admit that it is still difficult to parse, which could justify splitting to separate schema. Anyway the point of my comment was to define all properties in top level, not in allOf. allOf should be used to constrain these properties. Best regards, Krzysztof