Re: [PATCH v6 1/2] media: dt-bindings: Add Himax HM1092 NIR sensor

Ramshouriesh R <[email protected]> Mon, 3 Aug 2026 22:47:07 +0530
Newsgroups dev.linux.lists.sashiko-reviews,org.kernel.vger.linux-devicetree
Message-ID <CAJTcUFQ0iBF=2i3Bqs8PmBRNeqeYjdazNYU4HPzL1eM+UGuhwA@mail.gmail.com>
On Mon, 3 Aug 2026 at 20:02, Rob Herring <[email protected]> wrote:
>
> On Sat, Aug 01, 2026 at 01:01:49PM +0000, [email protected] wrote:
> > Thank you for your contribution! Sashiko AI review found 1 potential is=
sue(s) to consider:
> > - [Medium] The schema fails to restrict the `data-lanes` property to a =
single lane, allowing physically invalid device tree configurations to sile=
ntly pass validation.
> > --
> >
> > --- Patch [1]: [PATCH v6 1/2] media: dt-bindings: Add Himax HM1092 NIR =
sensor ---
> > commit ee5879a0923ec6b56edc74d8a66ff697b111ae09
> > Author: Ramshouriesh R <[email protected]>
> >
> > media: dt-bindings: Add Himax HM1092 NIR sensor
> >
> > This commit adds a device tree binding schema for the Himax HM1092, a 1
> > megapixel monochrome near-infrared CMOS image sensor. The sensor is des=
cribed
> > as outputting 10-bit RAW data over a single MIPI CSI-2 data lane.
> >
> > > diff --git a/Documentation/devicetree/bindings/media/i2c/himax,hm1092=
.yaml b/Documentation/devicetree/bindings/media/i2c/himax,hm1092.yaml
> > > new file mode 100644
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/media/i2c/himax,hm1092.yaml
> > [ ... ]
> > > +  port:
> > > +    $ref: /schemas/graph.yaml#/$defs/port-base
> > > +    additionalProperties: false
> > > +
> > > +    properties:
> > > +      endpoint:
> > > +        $ref: /schemas/media/video-interfaces.yaml#
> > > +        unevaluatedProperties: false
> > > +
> > > +        required:
> > > +          - link-frequencies
> >
> > [Severity: Medium]
> > The commit message mentions the sensor outputs over a single MIPI CSI-2=
 data
> > lane, but does this schema restrict the data-lanes property to a single=
 lane?
> >
> > Without explicitly defining a data-lanes property constraint (such as
> > maxItems: 1 or items: - const: 1) in this endpoint block, the schema in=
herits
> > the permissive defaults from video-interfaces.yaml. This would allow de=
vice
> > trees specifying physically impossible multi-lane configurations
> > (e.g., data-lanes =3D <1 2>;) to silently pass schema validation.
>
> data-lanes should not be present, but that's probably an issue on a
> number of bindings. There's not a great way to so this other than using
> 'additionalProperties' instead and listing all the properties used from
> video-interfaces.yaml. But then you have to list 'remote-endpoint'
> everywhere which is not great either. I'd rather just allow the property
> even if it doesn't make sense for the h/w.
>
> Rob

Thanks for the clarification. I=E2=80=99ll leave the binding as-is and won=
=E2=80=99t
add the data-lanes constraint suggested by Sashiko.

Regards,
Ramshouriesh