Re: [RFC PATCH 1/8] dt-bindings: media: Add bindings for Omnivision OV2312

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [Medium] dt-bindings: media: ov2312: missing standard supplies and interface properties
- [Medium] dt-bindings: media: ov2312: missing endpoint constraints for data-lanes
- [Low] dt-bindings: media: ov2312: non-standard relative path used for schema $ref
- [Low] dt-bindings: media: ov2312: spelling error 'Omnvision' in description
--

commit 77ac9a3376c50e8570040c636f5b50eb4a9953b6
Author: Jai Luthra <jai.luthra@linux.dev>

    dt-bindings: media: Add bindings for Omnivision OV2312
    
    Add DT bindings for Omnivision OV2312 camera sensor.

> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov2312.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov2312.yaml
> new file mode 100644
> index 0000000000000..76929fcc65506
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov2312.yaml
> @@ -0,0 +1,79 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/i2c/ovti,ov2312.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: OmniVision OV2312 Camera Sensor
> +
> +maintainers:
> +  - Jai Luthra <j-luthra@ti.com>
> +
> +description: |-
> +  Omnvision OV2312 is a camera sensor with an active array size of 1600x1300.

[Severity: Low]
This isn't a bug, but there's a typo in the manufacturer's name. Should this
be "OmniVision" instead of "Omnvision"?

> +  It supports capture of frames with a 4x4 RGB-IR bayer pattern. This provides
> +  both human (RGB) and machine vision (IR) capabilities in low-light scenarios.
> +
> +properties:
> +  compatible:
> +    enum:
> +      - ovti,ov2312

[Severity: Medium]
Does the properties block need to include a $ref to
/schemas/media/video-interface-devices.yaml# and define standard physical
power regulators (like avdd-supply, dvdd-supply, dovdd-supply) or mounting
properties (rotation, orientation)?

Because the schema strictly sets additionalProperties: false, accurate device
trees that model these physical hardware features will fail dtbs_check
validation.

[ ... ]

> +  port:
> +    $ref: /schemas/graph.yaml#/properties/port
> +    additionalProperties: false
> +
> +    properties:
> +      endpoint:

[Severity: Medium]
Does this endpoint definition need explicit constraints for data-lanes and
link-frequencies?

Without constraints like maxItems: 2, the schema inherits the default from
video-interfaces.yaml and incorrectly allows up to 8 lanes. Missing these
constraints also means essential CSI-2 properties can be omitted entirely
without failing schema validation.

> +        $ref: ../video-interfaces.yaml#

[Severity: Low]
Should this use an absolute path for the schema reference?

While the dt-schema tooling might resolve the relative path
(../video-interfaces.yaml#) based on JSON schema rules, standard kernel
devicetree practice mandates absolute paths (e.g.,
/schemas/media/video-interfaces.yaml#) to ensure consistency for automated
tree-wide tooling and grepping.

> +        unevaluatedProperties: false

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260925133001.2780868-1-r-donadkar@ti.com?part=1