Re: [PATCH v4 1/2] dt-bindings: media: i2c: Add Mira016 image sensor

[Jacopo Mondi]

Hi Sakari

On Wed, Sep 09, 2026 at 11:09:48AM +0300, Sakari Ailus wrote:
> Hi Jacopo,
>
> On Wed, Sep 09, 2026 at 09:35:52AM +0200, Jacopo Mondi wrote:
> > Sakari,
> >
> > On Tue, Sep 08, 2026 at 02:48:54PM +0300, Sakari Ailus wrote:
> > > Hi Jacopo,
> > >
> > > On Tue, Sep 08, 2026 at 01:46:11PM +0200, Jacopo Mondi wrote:
> > > > Hi Sakari
> > > >
> > > > On Tue, Sep 08, 2026 at 11:16:26AM +0300, Sakari Ailus wrote:
> > > > > Hi Jacopo,
> > > > >
> > > > > On Tue, Sep 08, 2026 at 09:57:23AM +0200, Jacopo Mondi wrote:
> > > > > > Add bindings for the ams OSRAM Mira016 image sensor.
> > > > > >
> > > > > > Signed-off-by: Jacopo Mondi <jacopo.mondi@xxxxxxxxxxxxxxxx>
> > > > > > Acked-by: Conor Dooley <conor.dooley@xxxxxxxxxxxxx>
> > > > > > ---
> > > > > >  .../devicetree/bindings/media/i2c/ams,mira016.yaml | 97 ++++++++++++++++++++++
> > > > > >  MAINTAINERS                                        |  7 ++
> > > > > >  2 files changed, 104 insertions(+)
> > > > > >
> > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ams,mira016.yaml b/Documentation/devicetree/bindings/media/i2c/ams,mira016.yaml
> > > > > > new file mode 100644
> > > > > > index 000000000000..49a606fca6cb
> > > > > > --- /dev/null
> > > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ams,mira016.yaml
> > > > > > @@ -0,0 +1,97 @@
> > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > > +%YAML 1.2
> > > > > > +---
> > > > > > +$id: http://devicetree.org/schemas/media/i2c/ams,mira016.yaml#
> > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > +
> > > > > > +title: AMS 0.16 MP NIR enhanced global shutter image sensor
> > > > > > +
> > > > > > +maintainers:
> > > > > > +  - Jacopo Mondi <jacopo.mondi@xxxxxxxxxxxxxxxx>
> > > > > > +  - Philippe Baetens <philippebaetens@xxxxxxxxx>
> > > > > > +
> > > > > > +description:
> > > > > > +  Mira016 is a 0.16 MP NIR enhanced global shutter image sensor designed for 2D
> > > > > > +  and 3D consumer and industrial machine vision applications. The sensor is
> > > > > > +  compliant to the MIPI CSI-2 v1.3 protocol interface and the D-PHY v1.2
> > > > > > +  physical layer specifications to transmit the image data to the host
> > > > > > +  processor. It uses one data lane and one clock lane operating up to 1.5 Gbps.
> > > > > > +
> > > > > > +allOf:
> > > > > > +  - $ref: /schemas/media/video-interface-devices.yaml#
> > > > > > +
> > > > > > +properties:
> > > > > > +  compatible:
> > > > > > +    const: ams,mira016
> > > > > > +
> > > > > > +  reg:
> > > > > > +    maxItems: 1
> > > > > > +
> > > > > > +  clocks:
> > > > > > +    maxItems: 1
> > > > > > +
> > > > > > +  vdd28-supply:
> > > > > > +    description:
> > > > > > +      I/O voltage supply, 2.8 volts
> > > > > > +
> > > > > > +  vdd11-supply:
> > > > > > +    description:
> > > > > > +      I/O voltage supply, 1.1 volts
> > > > > > +
> > > > > > +  reset-gpios:
> > > > > > +    description: Sensor reset (RST_N) GPIO
> > > > > > +    maxItems: 1
> > > > > > +
> > > > > > +  port:
> > > > > > +    $ref: /schemas/graph.yaml#/$defs/port-base
> > > > > > +    additionalProperties: false
> > > > > > +    description:
> > > > > > +      Video output port
> > > > > > +
> > > > > > +    properties:
> > > > > > +      endpoint:
> > > > > > +        $ref: /schemas/media/video-interfaces.yaml#
> > > > > > +        unevaluatedProperties: false
> > > > > > +
> > > > > > +        properties:
> > > > > > +          data-lanes:
> > > > > > +            items:
> > > > > > +              - const: 1
> > > > >
> > > > > The device obviously supports non-continuous clock mode (and that's what
> > > > > the driver also only does right now) but as the continous clock mode is
> > > > > required by CSI-2, I presume the device can do both.
> > > > >
> > > > > So I think you should have
> > > > >
> > > > >              clock-noncontinuous: true
> > > > >
> > > > > here.
> > > > >
> > > >
> > > > Maybe I'm confused (again, after 10 or so years of doing this) by the
> > > > usage of unevaluatedProperties/additionalProperties, but if I read
> > > > Documentation/devicetree/bindings/writing-schema.rst right
> > > >
> > > >   * unevaluatedProperties: false
> > > >       Used when this binding references other schema whose all properties
> > > >       should be allowed.
> > > >
> > > > Means all properties from video-interfaces.yaml are accepted (which is
> > > > imho very wrong, but it's a battle with dt maintainers I don't want to
> > > > start again).
> > >
> > > I guess you should have
> > >
> > > 		additionalProperties: false
> > >
> > > too?
> > >
> >
> > Where exactly do you mean ?
> >
> > I don't think I can have additionalProperties: and
> > unevaluatedProperties: in the same node, do I ?
>
> Yes, these are mutually exclusive.
>
> >
> > It's been a long time ago when we discussed with dt-maintainers what
> > the policy should have been for endpoints that reference
> > video-interfaces.yaml.
> >
> > To me, the most sensible thing was to use "additionalProperties: false"
> > and explicitly allow the supported properties, instead of allowing all
> > of them. However dt maintainers had a different opinion (for reasons I
> > honestly can't remember) and I think we have stabilized on the
> > following pattern
> >
> >         port:
> >           $ref: /schemas/graph.yaml#/$defs/port-base
> >           additionalProperties: false
> >
> >           properties:
> >             endpoint:
> >               $ref: /schemas/media/video-interfaces.yaml#
> >               unevaluatedProperties: false
> >
> >               properties:
> >                 ...
> >
> > All the most recently merged bindings in media/i2c have this pattern
> >
> > 42f83a32259a ("dt-bindings: media: i2c: Add Sony IMX678")
> > 097d2be74ad0 ("dt-bindings: media: i2c: document Omnivision OV08D10 CMOS image sensor")
> > 631dd79305ab ("dt-bindings: media: i2c: Add ov2732 image sensor")
> >
> > I feel like I'm missing something obvious, otherwise I don't see why
> > this binding should be different ?
>
> Good question. Perhaps there was no specific thought given on
> non-contiguous clock support? I guess most of the above should probably
> specify it, even if the driver doesn't support it.

Maybe I'm still missing something, but using
'unevaluatedProperties: false' and referencing video-interfaces.yaml
means you can include all properties from there (which, again, I think
it's wrong, but allows you to specify continous/non-continuous clock
support).

>
> There's a good example of doing this in
> Documentation/devicetree/bindings/media/i2c/ovti,ov5670.yaml, you're listed
> as the maintainer there. :-)

eheh, that binding has 'additionalProperties: false' which means you
have to list properties you accept.

This would be my preferred approach, but if my recollection is
correct, we stabilized on using 'unevaluatedProperties: false' after
discussing it with dt maintainers.

Does anyone have a different recollection ?

>
> --
> Regards,
>
> Sakari Ailus