Re: [PATCH v4 2/2] dt-bindings: mmc: st,sdhci: Convert to DT schema

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The DT schema fails to conditionally require `reg-names` when multiple `reg` entries are provided, which can lead to silent runtime misconfiguration.
- [Medium] The YAML schema loses the original specific allowed values constraint for `max-frequency`.
--

commit e2c333948a6b09aa2bb42febade330d8715b076f
Author: Charan Pedumuru <charan.pedumuru@gmail.com>

dt-bindings: mmc: st,sdhci: Convert to DT schema

This commit converts the STMicroelectronics sdhci-st MMC/SD controller
binding from a text format to a YAML DT schema. It preserves the flexibility
of optional clocks and registers from the original binding.

> diff --git a/Documentation/devicetree/bindings/mmc/st,sdhci.yaml b/Documentation/devicetree/bindings/mmc/st,sdhci.yaml
> new file mode 100644
> index 0000000000000..0bf4fc3ca699f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/st,sdhci.yaml

[ ... ]

> +allOf:
> +  - $ref: mmc-controller.yaml#
> +
> +properties:
> +  compatible:
> +    oneOf:
> +      - const: st,sdhci
> +      - items:
> +          - const: st,sdhci-stih407
> +          - const: st,sdhci

[Severity: Medium]
Is this a regression from the strict constraints of the text binding?

The original text binding restricted max-frequency to 200000000, 100000000,
or 50000000, which matches the driver's behavior in sdhci-st.c. Since this
new YAML schema omits max-frequency entirely, it falls back to the generic
mmc-controller.yaml which permits any integer.

Should this explicitly define max-frequency under properties with an enum
constraint to prevent unsupported frequencies from passing validation and
silently falling back to 50MHz at runtime?

> +
> +  reg:
> +    minItems: 1
> +    items:
> +      - description: MMC controller base registers
> +      - description: FlashSS Top registers for TX/RX DLL delay configuration
> +
> +  reg-names:
> +    minItems: 1
> +    items:
> +      - const: mmc
> +      - const: top-mmc-delay

[Severity: Medium]
Does this omission create a regression where the schema validation silently
accepts an invalid device tree?

The previous text binding explicitly stated that if the FlashSS Top register
is provided, reg-names must also be specified.

Without an allOf conditional block making reg-names required when the reg
property contains two items, won't the schema validation pass even if
reg-names is missing? If the driver relies on
devm_platform_ioremap_resource_byname() for top-mmc-delay, could this result
in a silent runtime misconfiguration?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260613-st-mmc-v4-0-b3c385617c16@gmail.com?part=2