[PATCH 1/2] dt-bindings: nvme: Add apple,t8132-nvme-ans2 compatible

[Krzysztof Kozlowski]

On 12/08/2026 10:08, Yureka Lilian wrote:
> Thank you for the quick feedback!
> 
> On 8/12/26 01:11, Rob Herring wrote:
>> On Tue, Aug 11, 2026 at 10:49:47PM +0200, Yureka Lilian wrote:
>>> Add a new base compatible for the ANS2 NVMe on the Apple t8132 (M4) SoC,
>>> which uses a separate MMIO base for its NVMMU.
>>>
>>> Signed-off-by: Yureka Lilian <yureka at cyberchaos.dev>
>>> ---
>>>   .../devicetree/bindings/nvme/apple,nvme-ans.yaml   | 77 ++++++++++++++--------
>>>   1 file changed, 48 insertions(+), 29 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml b/Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml
>>> index 4c0b1f90aff8..c8a41b268b9c 100644
>>> --- a/Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml
>>> +++ b/Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml
>>> @@ -16,6 +16,7 @@ properties:
>>>         - items:
>>>             - const: apple,t6020-nvme-ans2
>>>             - const: apple,t8103-nvme-ans2
>>> +      - const: apple,t8132-nvme-ans2
>>>         - items:
>>>             - enum:
>>>                 # Do not add additional SoC to this list.
>>> @@ -24,16 +25,6 @@ properties:
>>>                 - apple,t6000-nvme-ans2
>>>             - const: apple,nvme-ans2
>>>   
>>> -  reg:
>>> -    items:
>>> -      - description: NVMe and NVMMU registers
>>> -      - description: ANS2 co-processor control registers
>>> -
>>> -  reg-names:
>>> -    items:
>>> -      - const: nvme
>>> -      - const: ans
>>> -
>> Keep properties defined at the top level. More below.
>>
>>>     resets:
>>>       maxItems: 1
>>>   
>>> @@ -68,25 +59,53 @@ properties:
>>>   
>>>         The SART address filter is documented in iommu/apple,sart.yaml.
>>>   
>>> -if:
>>> -  properties:
>>> -    compatible:
>>> -      contains:
>>> -        enum:
>>> -          - apple,t6000-nvme-ans2
>>> -          - apple,t6020-nvme-ans2
>>> -then:
>>> -  properties:
>>> -    power-domains:
>>> -      minItems: 3
>>> -    power-domain-names:
>>> -      minItems: 3
>>> -else:
>>> -  properties:
>>> -    power-domains:
>>> -      maxItems: 2
>>> -    power-domain-names:
>>> -      maxItems: 2
>>> +allOf:
>>> +  - if:
>>> +      properties:
>>> +        compatible:
>>> +          contains:
>>> +            const: apple,t8132-nvme-ans2
>>> +    then:
>>> +      properties:
>>> +        reg:
>>> +          items:
>>> +            - description: NVMMU registers
>>> +            - description: NVMe registers
>>> +            - description: ANS2 co-processor control registers
>>> +        reg-names:
>>> +          items:
>>> +            - const: nvmmu
>>> +            - const: nvme
>>> +            - const: ans
>> New entries go on the end.
> Ack
>> So nvmmu last and defined at the top level.
> I did read the docs which said the properties should always be 
> introduced at the top-level, however I couldn't figure out how to 
> describe the intended constraints in this way.
>> Then this is just 'minItems: 3'
>>
>>> +    else:
>>> +      properties:
>>> +        reg:
>>> +          items:
>>> +            - description: NVMe and NVMMU registers
>>> +            - description: ANS2 co-processor control registers
>>> +        reg-names:
>>> +          items:
>>> +            - const: nvme
>>> +            - const: ans
>> And 'maxItems: 2' on these 2.
> 
> When the three items are defined at the top-level, I can't seem to make 
> the dtbs_check work:
> 
> [...]
> arch/arm64/boot/dts/apple/t8112-j413.dtb: nvme at 27bcc0000 
> (apple,t8112-nvme-ans2): reg: [[2, 2076966912, 0, 262144], [2, 
> 2000683008, 0, 16384]] is too short
>      from schema $id: http://devicetree.org/schemas/nvme/apple,nvme-ans.yaml
> arch/arm64/boot/dts/apple/t8112-j413.dtb: nvme at 27bcc0000 
> (apple,t8112-nvme-ans2): reg-names: ['nvme', 'ans'] is too short
>      from schema $id: http://devicetree.org/schemas/nvme/apple,nvme-ans.yaml
> [...]
> 
> despite this compatible falling into the "... else ... maxItems: 2" branch
> 
> Would it be acceptable to define the reg and reg-names with just 
> minItems: 2, maxItems: 3, but without specific items or descriptions, 
> and then add the compatible-specific items and descriptions in the 
> conditional part below?

No, because you do workaround for your own introduced problem. If you
list the entries in top level in correct order, then everything will
work fine with Rob's answer/comment.

This is your case:
https://elixir.bootlin.com/linux/v6.11-rc6/source/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml#L39

This is not your case:
https://elixir.bootlin.com/linux/v6.11-rc6/source/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml#L127
Unless you provide arguments why it is.

Best regards,
Krzysztof