Re: [PATCH v2 2/9] dt-bindings: mmc: cdns,sdhci: add SD6HC support and PHY properties

["Kathpalia, Tanmay" <tanmay.kathpalia@altera.com>]

On 6/28/2026 1:56 AM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] Device tree schema guideline violation: standard properties are defined solely within conditional blocks.
> --
>
> commit e277493647bd6915b90ee32b253e1cb7514a8c5f
> Author: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
>
> dt-bindings: mmc: cdns,sdhci: add SD6HC support and PHY properties
>
> Extend the Cadence SDHCI binding to support the sixth-generation SD6HC
> controller. Add the cdns,sd6hc and altr,agilex5-sd6hc compatible strings
> along with variant constraints.
>
>> diff --git a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
>> index 6c7317d13aa6c..edd96e1d2bdcd 100644
>> --- a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
>> +++ b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
> [ ... ]
>
>> @@ -139,6 +168,77 @@ allOf:
>>           reg:
>>             maxItems: 1
>>   
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            const: cdns,sd6hc
>> +    then:
>> +      description: SD6HC variant - use IO-cell and delay element properties
>> +      properties:
>> +        clocks:
>> +          minItems: 2
>> +          maxItems: 2
>> +        clock-names:
>> +          items:
>> +            - const: ciu
>> +            - const: biu
>> +        dma-coherent: true
>> +        iommus:
>> +          maxItems: 1
> [Severity: Low]
> This isn't a bug, but should clock-names, dma-coherent, and iommus be
> declared in the top-level properties block instead of solely within this
> conditional?
>
> The dt-schema guidelines suggest defining properties with their broadest
> constraints at the top level rather than entirely within if:then blocks, to
> ensure proper documentation generation and tooling compatibility.

These properties are intentionally declared only within the if:/then:
block because they are exclusively valid for cdns,sd6hc hardware,
they are not applicable to cdns,sd4hc or other variants.

>
> [ ... ]
>
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            const: altr,agilex5-sd6hc
>> +    then:
>> +      properties:
>> +        resets:
>> +          minItems: 3
>> +          maxItems: 3
>> +        reset-names:
>> +          items:
>> +            - const: sdhc-reset
>> +            - const: combophy
>> +            - const: sdmmc-ocp
> [Severity: Low]
> Similar to the clock-names property, should reset-names also be declared at
> the top level rather than being exclusively defined in this conditional block?
Same reasoning as above - the three reset names (sdhc-reset,
combophy, sdmmc-ocp) are specific to the altr,agilex5-sd6hc
integration.