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