Re: [PATCH 2/2] dt-bindings: spi: ti,davinci-spi: convert to DT schema

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The `num-cs` property is incorrectly capped at a maximum of 6, artificially limiting the use of GPIO-based chip selects.
- [Medium] The converted DT schema incorrectly drops standalone support for `ti,dm6441-spi`, breaking backwards compatibility for DM644x device trees.
--

--- Patch [2]: [PATCH 2/2] dt-bindings: spi: ti,davinci-spi: convert to DT schema ---
commit e89abf8864b6f9ee684db27ba9936dcad0c1cd48
Author: Bhargav Joshi <[email protected]>

dt-bindings: spi: ti,davinci-spi: convert to DT schema

This commit converts the TI DaVinci/Keystone SPI controller binding
from text format to DT schema. It also creates a separate schema for
peripheral properties.

> diff --git a/Documentation/devicetree/bindings/spi/ti,davinci-spi.yaml b/Documentation/devicetree/bindings/spi/ti,davinci-spi.yaml
> new file mode 100644
> index 0000000000000..81014e9639097
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/ti,davinci-spi.yaml
[ ... ]
> +properties:
> +  compatible:
> +    oneOf:
> +      - enum:
> +          - ti,da830-spi
> +          - ti,keystone-spi
> +      - items:
> +          - const: ti,keystone-spi
> +          - const: ti,dm6441-spi

[Severity: Medium]
Does this structure accidentally drop support for using ti,dm6441-spi
as a standalone compatible string?

The original text binding documented ti,dm6441-spi as valid on its own,
and the driver natively matches it. This new schema restricts it to
only being used as a fallback for ti,keystone-spi, which will cause
schema validation to fail for existing DM644x device trees.

[ ... ]
> +  power-domains:
> +    maxItems: 1
> +    description:
> +      Should contain a phandle to a PM domain provider node
> +      and an args specifier containing the SPI device id
> +      value.
> +
> +  num-cs:
> +    minimum: 1
> +    maximum: 6
> +    default: 1
> +    description:
> +      Number of chip selects supported by the controller. This
> +      includes both internal and GPIO chip selects.

[Severity: Medium]
Should this property be capped at a maximum of 6?

The commit message notes this constraint is based on the maximum
hardware chip selects available. However, since the description explicitly
states this includes GPIO chip selects, imposing a rigid hardware maximum
prevents using an unbounded number of GPIO chip selects.

Device trees using more than 6 total chip selects (such as by defining
num-cs = <8> along with a cs-gpios array) will now fail validation.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2