lkml.org 
[lkml]   [2022]   [Jul]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 17/43] dt-bindings: phy: qcom,qmp-pcie: add missing child node schema
From
On 05/07/2022 13:51, Johan Hovold wrote:
> On Tue, Jul 05, 2022 at 12:18:37PM +0200, Krzysztof Kozlowski wrote:
>> On 05/07/2022 11:42, Johan Hovold wrote:
>>> Add the missing the description of the PHY-provider child node which was
>>> ignored when converting to DT schema.
>>>
>>> Also fix up the incorrect description that claimed that one child node
>>> per lane was required.
>>>
>>> Fixes: ccf51c1cedfd ("dt-bindings: phy: qcom,qmp: Convert QMP PHY bindings to yaml")
>>> Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
>>> ---
>>> .../bindings/phy/qcom,qmp-pcie-phy.yaml | 88 ++++++++++++++++++-
>>> 1 file changed, 85 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qmp-pcie-phy.yaml
>>> index ff1577f68a00..5a1ebf874559 100644
>>> --- a/Documentation/devicetree/bindings/phy/qcom,qmp-pcie-phy.yaml
>>> +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-pcie-phy.yaml
>>> @@ -69,9 +69,37 @@ properties:
>
>>> + - if:
>>> + properties:
>>> + compatible:
>>> + contains:
>>> + enum:
>>> + - qcom,sm8250-qmp-gen3x2-pcie-phy
>>> + - qcom,sm8250-qmp-modem-pcie-phy
>>> + - qcom,sm8450-qmp-gen4x2-pcie-phy
>>> + then:
>>> + patternProperties:
>>> + "^phy@[0-9a-f]+$":
>>> + properties:
>>> + reg:
>>> + items:
>>> + - description: TX lane 1
>>> + - description: RX lane 1
>>> + - description: PCS
>>> + - description: TX lane 2
>>> + - description: RX lane 2
>>> + - description: PCS_MISC
>>> + else:
>>> + patternProperties:
>>> + "^phy@[0-9a-f]+$":
>>> + properties:
>>> + reg:
>>> + minItems: 3
>>> + maxItems: 4
>>> + items:
>>> + - description: TX
>>> + - description: RX
>>> + - description: PCS
>>> + - description: PCS_MISC
>>> + if:
>>
>> Do not include if within other if. Just split the entire section to its
>> own if:.
>
> That sounds like it would just obfuscate the logic. The else clause
> specified 3-4 registers and the nested if determines which compatibles
> use which by further narrowing the range.
>
> If you move it out to the else: this would be really hard understand and
> verify.

Every bindings are expected to do that way and most of them are doing
it: define broad constraints in properties:, then define strict
constraints per each variant. Easy to follow code. This binding is not
particularly special to make it different than other ones. Doing
semi-strict constraints in if: and then additional constrain in nested
if: is not easy to understand and verify.


Best regards,
Krzysztof

\
 
 \ /
  Last update: 2022-07-05 13:58    [W:0.495 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site