public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	"Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Arınç ÜNAL" <arinc.unal@arinc9.com>
Subject: Re: [PATCH v2] dt-bindings: mips: add CPU bindings for MIPS architecture
Date: Wed, 21 Sep 2022 09:51:55 +0200	[thread overview]
Message-ID: <658248bd-fe6f-04c5-fe41-bd3210d6b52f@linaro.org> (raw)
In-Reply-To: <CAMhs-H-TATfafSJzqXFi-Q=AYYWj-EY1tJs-9y7phR-wu4n1Tg@mail.gmail.com>

On 21/09/2022 09:18, Sergio Paracuellos wrote:
> Hi Krzysztof,
> 
> On Wed, Sep 21, 2022 at 8:42 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 20/09/2022 07:51, Sergio Paracuellos wrote:
>>> Hi Krzysztof,
>>>
>>> On Mon, Sep 19, 2022 at 6:08 PM Krzysztof Kozlowski
>>> <krzysztof.kozlowski@linaro.org> wrote:
>>>>
>>>> On 19/09/2022 15:41, Sergio Paracuellos wrote:
>>>>> Hi Krzysztof,
>>>>>
>>>>> On Mon, Sep 19, 2022 at 2:48 PM Krzysztof Kozlowski
>>>>> <krzysztof.kozlowski@linaro.org> wrote:
>>>>>>
>>>>>> On 19/09/2022 14:29, Sergio Paracuellos wrote:
>>>>>>>>
>>>>>>>> else mips-hpt-frequency: false
>>>>>>>>
>>>>>>>>> +
>>>>>>>>> +required:
>>>>>>>>> +  - compatible
>>>>>>>>> +
>>>>>>>>> +additionalProperties: true
>>>>>>>>
>>>>>>>> and this is why you did not notice errors...
>>>>>>>
>>>>>>> Current arch/mips/boot/dts folder dts files are a mess for cpu nodes,
>>>>>>> so I set additionalProperties to true and only make required for
>>>>>>> 'compatible'. What should be the correct approach?
>>>>>>
>>>>>> This is okay, but it caused you did not notice errors...
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>> +
>>>>>>>>> +examples:
>>>>>>>>> +  - |
>>>>>>>>> +    cpus {
>>>>>>>>> +      #size-cells = <0>;
>>>>>>>>> +      #address-cells = <1>;
>>>>>>>>> +
>>>>>>>>> +      cpu@0 {
>>>>>>>>> +        device_type = "cpu";
>>>>>>>>> +        compatible = "mips,mips1004Kc";
>>>>>>>>> +        reg = <0>;
>>>>>>>>> +      };
>>>>>>>>> +
>>>>>>>>> +      cpu@1 {
>>>>>>>>> +        device_type = "cpu";
>>>>>>>>> +        compatible = "mips,mips1004Kc";
>>>>>>>>> +        reg = <1>;
>>>>>>>>> +      };
>>>>>>>>> +    };
>>>>>>>>> +
>>>>>>>>> +  - |
>>>>>>>>> +    // Example 2 (BMIPS CPU)
>>>>>>>>> +    cpus {
>>>>>>>>> +      #address-cells = <1>;
>>>>>>>>> +      #size-cells = <0>;
>>>>>>>>> +
>>>>>>>>> +      mips-hpt-frequency = <150000000>;
>>>>>>>>
>>>>>>>> Does not match your bindings. Are you sure you tested the patches?
>>>>>>>
>>>>>>> Yes I did:
>>>>>>>
>>>>>>> $ make dt_binding_check
>>>>>>> DT_SCHEMA_FILES=Documentation/devicetree/bindings/mips/cpus.yaml
>>>>>>>   LINT    Documentation/devicetree/bindings
>>>>>>>   CHKDT   Documentation/devicetree/bindings/processed-schema.json
>>>>>>>   SCHEMA  Documentation/devicetree/bindings/processed-schema.json
>>>>>>>   DTEX    Documentation/devicetree/bindings/mips/cpus.example.dts
>>>>>>>   DTC     Documentation/devicetree/bindings/mips/cpus.example.dtb
>>>>>>> ' CHECK   Documentation/devicetree/bindings/mips/cpus.example.dtb
>>>>>>>
>>>>>>> Can you please point me to a sample of how to make required in a
>>>>>>> parent node of cpu@X property 'mips-hpt-frequency' only for some
>>>>>>> compatible strings inside the node? What can this be properly
>>>>>>> expressed using schema??
>>>>>>> I was looking and testing different things for a while without success at all.
>>>>>>
>>>>>> You either define new schema for /cpus node (and match by name, define
>>>>>> children etc) or include it in schema for top-level properties. The
>>>>>> first is tricky, because the cpus node does not have compatible (like
>>>>>> nvidia,tegra194-ccplex.yaml).
>>>
>>> Ok so if I am understanding correctly having two schemas is a way to go:
>>>
>>> One for brcm,bmips-cpus.yaml (since there is no compatible, should
>>> this be a valid name for this?) containing something like:
>>>
>>> properties:
>>>   $nodename:
>>>      const: cpus
>>>
>>>      mips-hpt-frequency:
>>>         $ref: /schemas/types.yaml#/definitions/uint32
>>>         description: |
>>>            This is common to all CPUs in the system so it lives
>>>             under the "cpus" node.
>>>
>>> additionalProperties: true
>>
>> Almost. Such schema will allow mips-hpt-frequency in each cpus node,
>> everywhere. On every board and architecture.
> 
> Yes, that is what I thought since no compatible to match this is
> included in current node.
> 
>>
>> You need to limit it per top-level compatibles.
> 
> Any sample of how to do this? So this bmips SoCs use compatible
> strings that are described in:
> https://elixir.bootlin.com/linux/v6.0-rc5/source/Documentation/devicetree/bindings/mips/brcm/soc.txt

Could be something like this:
https://lore.kernel.org/all/20220830065744.161163-2-krzysztof.kozlowski@linaro.org/
which is a part of top-level schema or add a new one. The new one will
duplicate the compatibles and parts from that one there, so maybe better
to keep it in top-level?

I am not sure, any suggestions are welcome. Also platform/architecture
maintainers might have their preference to organize it.

Anyway, you did not Cc the actual platform maintainers (Rafał and Hauke).

> 
> Can the top level compatible string be used in some way to filter this
> easily from this new 'brcm,bmips-cpus.yaml'

Yes. If schema matches the top level compatible, then in allOf:if:then
you can add restriction to disallow it for other variants:

For example:
https://elixir.bootlin.com/linux/v5.19/source/Documentation/devicetree/bindings/example-schema.yaml#L212

https://elixir.bootlin.com/linux/v5.19/source/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml#L152


Best regards,
Krzysztof

  reply	other threads:[~2022-09-21  7:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-17  4:11 [PATCH v2] dt-bindings: mips: add CPU bindings for MIPS architecture Sergio Paracuellos
2022-09-18 11:22 ` Thomas Bogendoerfer
2022-09-18 15:15   ` Sergio Paracuellos
2022-09-19 11:17 ` Krzysztof Kozlowski
2022-09-19 12:29   ` Sergio Paracuellos
2022-09-19 12:48     ` Krzysztof Kozlowski
2022-09-19 13:41       ` Sergio Paracuellos
2022-09-19 16:08         ` Krzysztof Kozlowski
2022-09-20  5:51           ` Sergio Paracuellos
2022-09-21  6:42             ` Krzysztof Kozlowski
2022-09-21  7:18               ` Sergio Paracuellos
2022-09-21  7:51                 ` Krzysztof Kozlowski [this message]
2022-09-21  8:11                   ` Sergio Paracuellos
2022-09-21 11:40                     ` Sergio Paracuellos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=658248bd-fe6f-04c5-fe41-bd3210d6b52f@linaro.org \
    --to=krzysztof.kozlowski@linaro.org \
    --cc=arinc.unal@arinc9.com \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=sergio.paracuellos@gmail.com \
    --cc=tsbogend@alpha.franken.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox