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 BE707C32771 for ; Fri, 19 Aug 2022 12:41:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348758AbiHSMlF (ORCPT ); Fri, 19 Aug 2022 08:41:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49474 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348487AbiHSMlA (ORCPT ); Fri, 19 Aug 2022 08:41:00 -0400 Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F29CEB07FE for ; Fri, 19 Aug 2022 05:40:58 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id s1so3170824lfp.6 for ; Fri, 19 Aug 2022 05:40:58 -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=vu2lHdZxEJpxevVE8eil1qxgFt43nikAxZVf13/nJys=; b=VDbRbwgBCqlvGplcG49N2W2pqBty1ZXmsqM9ti5lVULn8qCrNwpzo4W4gHp2usxMya oAsYzH5Vhwu7qq0lKCQdIujO24m/7EVtTOkK365b3AQtl3fYUBSvV75onErnYW1XMzNm U6KpBKZInfm1Hd8R4FTmo1Vq4lZuzkz5UTcjOAXN6xx6tVneuRGeBLIBEnuzRSKA3YXz Z3wOBk7yoLLZWrC8AvjYuBN8Cv6W9D9TpCakQwJKdoUlkqsPJJrKxKdmMYZ4IYJLwZeX r91KoUsH5bsl1e6OkR3y+iG7hnX5yUehzk4JBygP6g6p6yHVzxmIS3O6B1HmJWupv4H8 tZuw== 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=vu2lHdZxEJpxevVE8eil1qxgFt43nikAxZVf13/nJys=; b=If8HnEMOJPvnmhbJdoBcNoQ3kKhRTJoWHC9+Ee6r+XGl+USeCYb7YfXD4X2HuJonhp kIFVfsje2O40SEAHNlSvapdj7D1OZXQO8DiZd5JvxAGSk4vTYrgQwSPjPWVaCvp7pNdo dsnDN7HOrQWwxM4fKrAYzrcyfRgBiZQbKodkRzgsx7990XGi8xUXxuNS3mRq6TfnsqdF vMxvWFz+AN2UIOh/PrIgpNEpI6smDI7qlAADtcdVps6wAA6Wrp70E9stO7u0mkMlm5t4 41dgnZHu8lG3FLbNVmTaNfOdZR1auZjBYy/WyiEhy2UE3eWIxD55JiHR7rYZCVVLn8sK dEdQ== X-Gm-Message-State: ACgBeo3vo+zrZ7GXi32hdOQiobQzZHdseYsuFbBwuPM9dSyDdEQl9Fzy aAx6yELEpXo8ekqa6h7KLaElkLpzLBUxrAVm X-Google-Smtp-Source: AA6agR4J0Ea6eFpB2FAYhtL/1C6G9QtgQ0s9SRqW88AqI0njZbR8KWIKtwNgd6F0NHKqPvcSU9d+Dw== X-Received: by 2002:a05:6512:1091:b0:491:f135:4633 with SMTP id j17-20020a056512109100b00491f1354633mr2651400lfg.553.1660912857246; Fri, 19 Aug 2022 05:40:57 -0700 (PDT) Received: from ?IPV6:2001:14bb:ac:e5a8:ef73:73ed:75b3:8ed5? (d1xw6v77xrs23np8r6z-4.rev.dnainternet.fi. [2001:14bb:ac:e5a8:ef73:73ed:75b3:8ed5]) by smtp.gmail.com with ESMTPSA id d4-20020ac25444000000b0048ad4c718f3sm628432lfn.30.2022.08.19.05.40.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Aug 2022 05:40:56 -0700 (PDT) Message-ID: Date: Fri, 19 Aug 2022 15:40:54 +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> <3731cd56-f7e8-6807-06b5-b8b176b078b6@linaro.org> <24e251d7-f5db-5715-463d-333f5dfbfceb@arinc9.com> From: Krzysztof Kozlowski In-Reply-To: <24e251d7-f5db-5715-463d-333f5dfbfceb@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 17:06, Arınç ÜNAL wrote: > > > On 12.08.2022 16:48, Krzysztof Kozlowski wrote: >> 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. > > The problem is: > - only specific values of reg are allowed if label is cpu. > - only specific values of phy-mode are allowed if reg is 5 or 6. > > This forces me to define properties under allOf:if:then. None of the reasons above force you to define properties in some allOf:if:then subblock. These force you to constrain the properties in allOf:if:then, but not define. > Splitting to > separate schema (per compatible string?) wouldn't help in this case. True. > > I can split patternProperties to two sections, but I can't directly > define the reg property like you put above. Of course you can and original bindings were doing it. Let me ask specific questions (yes, no): 1. Are ethernet-ports and ethernet-port present in each variant? 2. Is dsa-port.yaml applicable to each variant? (looks like that - three compatibles, three all:if:then) 3. If reg appearing in each variant? 4. If above is true, if reg is maximum one item in each variant? Looking at your patch, I think answer is 4x yes, which means you can define them in one place and constrain in allOf:if:then, just like all other schemas, because this one is not different. Best regards, Krzysztof