Re: [PATCH v12 02/22] dt-bindings: media: i2c: max96717: add support for I2C ATR

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The `reg` property constraint inside the `^i2c@[01]$` pattern is missing `maxItems: 1` and incorrectly applies numeric constraints directly via `items`, making the validation ineffective.
- [Low] The `anyOf` logic used to enforce mutual exclusion between `i2c-atr` and `i2c-gate` is overly complex and redundant.
--

commit 38012c69a8fca6511a921f6751ee84fefe0e14a1
Author: Cosmin Tanislav <demonsingur@gmail.com>

dt-bindings: media: i2c: max96717: add support for I2C ATR

This commit adds support for I2C address translation (ATR) to the MAX96717 
device tree bindings. It introduces the i2c-atr property and associated 
address pools while maintaining support for the legacy i2c-gate property.

> diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max96717.yaml b/Documentation/devicetree/bindings/media/i2c/maxim,max96717.yaml
> index d1e8ba6e368ec..976f6dd2c164c 100644
> --- a/Documentation/devicetree/bindings/media/i2c/maxim,max96717.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/maxim,max96717.yaml

[ ... ]

> +    patternProperties:
> +      '^i2c@[01]$':
> +        $ref: /schemas/i2c/i2c-controller.yaml#
> +        unevaluatedProperties: false
> +        properties:
> +          reg:
> +            items:
> +              minimum: 0
> +              maximum: 1

[Severity: Medium]
Does this properly validate the reg property? Since dt-schema parses reg as 
a matrix (an array of tuples), applying minimum and maximum directly to 
items causes JSON schema to silently ignore the numeric constraints, as they 
are being applied to arrays instead of numbers.

Additionally, the lack of maxItems: 1 allows multiple register regions to 
incorrectly pass validation.

[ ... ]

> +allOf:
> +  - $ref: /schemas/i2c/i2c-atr.yaml#
> +
> +  - anyOf:
> +      - oneOf:
> +          - required: [i2c-atr]
> +          - required: [i2c-gate]
> +
> +      - not:
> +          required: [i2c-atr, i2c-gate]

[Severity: Low]
Is this anyOf block more complex than necessary? 

The not branch evaluates to true when only one is present or when neither 
is present, which completely subsumes the oneOf branch. Could this be 
mathematically simplified to just use the not condition without changing 
the validation logic?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260521-gmsl2-3_serdes-v12-0-b26d92931196@analog.com?part=2