[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a65697f4-0a75-23e2-517c-2784b0c382bc@linaro.org>
Date: Mon, 20 Mar 2023 08:40:57 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Xingyu Wu <xingyu.wu@...rfivetech.com>
Cc: linux-riscv@...ts.infradead.org, devicetree@...r.kernel.org,
Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>,
Philipp Zabel <p.zabel@...gutronix.de>,
Conor Dooley <conor@...nel.org>,
Emil Renner Berthing <kernel@...il.dk>,
Rob Herring <robh+dt@...nel.org>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>,
Hal Feng <hal.feng@...rfivetech.com>,
William Qiu <william.qiu@...rfivetech.com>,
linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org
Subject: Re: [PATCH v2 3/6] dt-bindings: soc: starfive: syscon: Add optional
patternProperties
On 20/03/2023 08:29, Xingyu Wu wrote:
> On 2023/3/20 14:37, Krzysztof Kozlowski wrote:
>> On 20/03/2023 04:54, Xingyu Wu wrote:
>>> On 2023/3/19 20:28, Krzysztof Kozlowski wrote:
>>>> On 16/03/2023 04:05, Xingyu Wu wrote:
>>>>> Add optional compatible and patternProperties.
>>>>>
>>>>> Signed-off-by: Xingyu Wu <xingyu.wu@...rfivetech.com>
>>>>> ---
>>>>> .../soc/starfive/starfive,jh7110-syscon.yaml | 39 ++++++++++++++++---
>>>>> 1 file changed, 33 insertions(+), 6 deletions(-)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/soc/starfive/starfive,jh7110-syscon.yaml b/Documentation/devicetree/bindings/soc/starfive/starfive,jh7110-syscon.yaml
>>>>> index ae7f1d6916af..b61d8921ef42 100644
>>>>> --- a/Documentation/devicetree/bindings/soc/starfive/starfive,jh7110-syscon.yaml
>>>>> +++ b/Documentation/devicetree/bindings/soc/starfive/starfive,jh7110-syscon.yaml
>>>>> @@ -15,16 +15,31 @@ description: |
>>>>>
>>>>> properties:
>>>>> compatible:
>>>>> - items:
>>>>> - - enum:
>>>>> - - starfive,jh7110-aon-syscon
>>>>> - - starfive,jh7110-stg-syscon
>>>>> - - starfive,jh7110-sys-syscon
>>>>> - - const: syscon
>>>>> + oneOf:
>>>>> + - items:
>>>>> + - enum:
>>>>> + - starfive,jh7110-aon-syscon
>>>>> + - starfive,jh7110-stg-syscon
>>>>> + - starfive,jh7110-sys-syscon
>>>>> + - const: syscon
>>>>> + - items:
>>>>> + - enum:
>>>>> + - starfive,jh7110-aon-syscon
>>>>> + - starfive,jh7110-stg-syscon
>>>>> + - starfive,jh7110-sys-syscon
>>>>> + - const: syscon
>>>>> + - const: simple-mfd
BTW, this also looks wrong. You just said that clock controller exists
only in few variants. Also, why sometimes the same device goes with
simple-mfd and sometimies without? It's the same device.
>>>>>
>>>>> reg:
>>>>> maxItems: 1
>>>>>
>>>>> +patternProperties:
>>>>> + # Optional children
>>>>> + "pll-clock-controller":
>>>>
>>>> It's not a pattern.
>>>
>>> Does it use 'properties' instead of 'patternProperties'?
>>
>> Yes.
>>
>>>
>>>>
>>>> Anyway should be clock-controller
>>>
>>> Will fix.
>>>
>>>>
>>>>> + type: object
>>>>> + $ref: /schemas/clock/starfive,jh7110-pll.yaml#
>>>>> + description: Clock provider for PLL.
>>>>> +
>>>>
>>>> You just added these bindings! So the initial submission was incomplete
>>>> on purpose?
>>>>
>>>> No, add complete bindings.
>>>
>>> Does you mean that it should drop the 'description', or add complete 'description',
>>> or add 'compatible', 'clocks' and 'clock-cells' of complete clock-controller bindings?
>>
>> It means it should be squashed with the patch which adds it.
>
> Should I drop the 'decription' here and keep the 'decription' in patch1?
There should be no this patch at all. However I do not understand what
you want to do with description. What's wrong with description?
>
>>
>>>
>>>>
>>>>> required:
>>>>> - compatible
>>>>> - reg
>>>>> @@ -38,4 +53,16 @@ examples:
>>>>> reg = <0x10240000 0x1000>;
>>>>> };
>>>>>
>>>>> + - |
>>>>> + syscon@...30000 {
>>>>
>>>> No need for new example... Just put it in existing one.
>>>>
>>>
>>> Actually, the PLL clock-controller are just set in sys-syscon resgisters. The stg-syscon and
>>> aon-syscon don't need it. So PLL clock-controller node only is added in sys-syscon node.
>>
>> So why having other examples if they are included here? Drop them.
>>
>
> Should I drop the old example of stg-syscon and add a new example of sys-syscon which
> include clock-controller child node?
No, there should be no stg-syscon example, it's useless.
Best regards,
Krzysztof
Powered by blists - more mailing lists