Re: [PATCHv2] dt-bindings: mtd: convert IBM NDFC binding to YAML

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] dt-bindings: mtd: incorrectly anchored regex in patternProperties
- [Medium] dt-bindings: mtd: schema validation bypassed for nand node
--

commit 56ea8b4c720a5df58f5f626346eba38c6d9ee900
Author: Rosen Penev <rosenp@gmail.com>

dt-bindings: mtd: convert IBM NDFC binding to YAML

The NDFC NAND flash controller was only described in a legacy text file,
so dtbs_check reported a failure to match any schema with the ibm,ndfc
compatible. Convert the binding to the YAML format so those nodes match
the generic nand-controller-legacy schema.

> diff --git a/Documentation/devicetree/bindings/mtd/ibm,ndfc.yaml b/Documentation/devicetree/bindings/mtd/ibm,ndfc.yaml
> new file mode 100644
> index 0000000000000..51ba0bd1d329d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/ibm,ndfc.yaml
[ ... ]
> +  nand:
> +    type: object
> +    description: NAND chip attached to the controller.
> +
> +    properties:
> +      "#address-cells":
> +        const: 1
> +      "#size-cells":
> +        const: 1
> +
> +    patternProperties:
> +      "(^partition)?@[0-9a-f]+$":
         ^^^^^^^^^^^^^^^^^^^^^^^^^^

[Severity: Medium]
Does this regex incorrectly match any node ending with a unit address?

Because the start anchor is inside an optional group, the unanchored
@[0-9a-f]+$ allows it to match any node name ending in @<hex> (for example,
chip@0). This incorrectly applies the deprecated partition schema and its
unevaluatedProperties: false constraint to unrelated subnodes, breaking
schema validation for any device tree containing a node named
<anything>@<hex> under the nand node.

> +        $ref: /schemas/mtd/partitions/partition.yaml#/$defs/partition-node
> +        deprecated: true
> +        unevaluatedProperties: false
> +
> +    additionalProperties: true
                             ^^^^

[Severity: Medium]
Does setting additionalProperties to true on the nand subnode bypass schema
validation?

This explicitly disables strict schema validation for the nand subnode,
rendering its contents largely unvalidated. It allows arbitrary,
undocumented, or misspelled properties to pass validation silently, which
defeats the purpose of the YAML schema conversion for this node.

Should this node use additionalProperties: false or
unevaluatedProperties: false and explicitly define or reference the required
standard NAND properties?

> +
> +required:
> +  - compatible
> +  - reg

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260923192528.52330-1-rosenp@gmail.com?part=1