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

[Sakari Ailus <sakari.ailus@linux.intel.com>]

Hi Jacopo,

On Wed, Sep 09, 2026 at 11:56:27AM +0200, Jacopo Mondi wrote:
> 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@ideasonboard.com>
> > > > > > > Acked-by: Conor Dooley <conor.dooley@microchip.com>
> > > > > > > ---
> > > > > > >  .../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@ideasonboard.com>
> > > > > > > +  - Philippe Baetens <philippebaetens@gmail.com>
> > > > > > > +
> > > > > > > +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 ?

I don't have such a recollection albeit I'm not sure I recall more than
this was probably discussed at some point. :-) What I do prefer however is
to be able to say what is relevant for a given device. There are lots of
properties there in video-interfaces.yaml that aren't for nearly every
device (node).

(It's been in my plan to better separate these based in physical interfaces
etc. but so far it's been just a plan. Even that won't make this issue go
entirely away though.)

-- 
Kind regards,

Sakari Ailus