Re: [PATCH v8 1/2] dt-bindings: embedded-controller: Add synology microp devices

[Krzysztof Kozlowski <krzk@kernel.org>]

On 21/04/2026 18:25, Markus Probst wrote:
>>
>> Not true. You have enum and min/maxItems. There is no such syntax for
>> compatibles. I repeat.
>>
>> Instead of just blindly disagreeing and saying "I did that", point me to
>> example-schema having compatibles with min/maxItems.
> It is supposed to minimize the schema, otherwise
> 
> - minItems: 3
>   maxItems: 3
>   items:
>     enum:
>     - synology,ds223j-microp
>     - synology,ds124-microp
>     - synology,ds118-microp
> 
> would have been
> 
> - items:
>     - const: synology,ds223j-microp
>     - const: synology,ds124-microp
>     - const: synology,ds118-microp
> 
> - items:
>     - const: synology,ds124-microp
>     - const: synology,ds223j-microp
>     - const: synology,ds118-microp
> 
> - items:
>     - const: synology,ds118-microp
>     - const: synology,ds223j-microp
>     - const: synology,ds124-microp

Only one device is the fallback for given groyp, not each of them.

There is no such syntax in the kernel, nowhere. Please do not invent own
stuff.

> .
> 
> In the case of dts validation, this is the same, with the exception of
> allowing any order. See below why the order does not matter.
> 
> And yes, the example schema didn't use min/maxItems.

Yep. It is also explained why in writing-bindings - list is STRICTLY
ordered. Not flexible. And example reflects that. BTW, other bindings as
well, so recent EC patches is good way to learn:
(although I understand that in-tree patches do not cover your case)

https://lore.kernel.org/all/20260327-add-driver-for-ec-v7-1-7684c915e42c@oss.qualcomm.com/

from:
https://lore.kernel.org/all/?q=dfn%3Abindings%2Fembedded-controller%2F


>>
>>
>>
>>>
>>>
>>> Other sources suggest, I should add fallbacks that are less specific
>>
>> That's not really discussed here. It all looks like some random schema
>> and considering amount of LLM flying on the lists I have now doubts.
> I am not using an LLM for coding. But it is the first device tree
> schema I try to write.
>>
>> You need specific compatibles.
>> ...
>>
>>>
>>> If thisisn't fine either, replying to my previous message would
>>> probably the most efficient way to move forward [1].
>>
>>
>>>
>>>>
>>>>> +        items:
>>>>> +          enum:
>>>>
>>>> No, why the list is randomly ordered.
>>
>> Look here
> Was answered below. They have the exactly same known feature set, thus
> the order does not matter. i. e. there is no known difference.
> 
>>
>>>>
>>>>> +            - synology,ds923p-microp
>>>>> +            - synology,ds1522p-microp
>>>>
>>>> And fallback, whichever is that, is not documented alone.
>>>>
>>>>> +      - minItems: 4
>>>>> +        maxItems: 4
>>>
>>> Those are devices with the exactly same known feature set.
>>> i. e. ds1522p can act as a fallback for ds923p, and ds923p could act as
>>> a fallback for ds1522p.
>>
>> You are not responding to actual comments. Lets focus ONLY on above
>> list. ONLY. Point me, where did you document the fallback to be used
>> alone? First of course, define what is the fallback.
> In this schema, I defined ds923p as fallback for ds1522p, and ds1522p

You did not define ds923p as fallback. It is used as front compatible as
well. Fallback cannot be used in some contexts at front:

+        items:
+          enum:
+            - synology,ds923p-microp
+            - synology,ds1522p-microp

> as fallback for ds923p. There was no separation of front and fallback
> until now. See below.
> 
>>
>> None of this matches example schema or any other bindings, none of this
>> produces correct constraints for correct DTS.
>>
>> You need a defined enum of fallbacks and several lists for specific
>> fallback+front, like many other bindings in kernel.
> So now I can imagine what schema you want to see.
> 
> i. e.
> - items:
>     - enum:
>       - front1
>       - front2
>       - front3
>     - const: fallback1
> - items:
>     - enum:
>       - front4
>       - front5
>       - front6
>     - const: fallback2
> - enum:
>   - fallback1
>   - fallback2

Yes

> 
> But I am unsure how to determine which devices are the fallback and
> which are the front devices, given some of them have the same feature
> set. The oldest device as fallback each?

You can open your v1 or other versions. They were quite clear about
fallback: it did not matter for you which device is used as fallback at
v1, because you treated each device as the same programming model. I
assume you treated them the same, because you did not know the
differences (which is fine), so it should not matter that much now.

If unsure, choose oldest device, less features or eventually smallest
number.


Best regards,
Krzysztof