| Message ID | 20241012-b4-linux-next-202041004-i2c-media-yaml-fixes-v1-2-a2bb12a1796d@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | media: i2c: Cleanup assigned-clocks and endpoint: properties: unevaluatedProperties: false | expand |
Hi Bryan, Thank you for the patch. On Sat, Oct 12, 2024 at 04:02:51PM +0100, Bryan O'Donoghue wrote: > Some of our sensor schemas use unevaluatedProperities: false for endpoint: s/unevaluatedProperities/unevaluatedProperties/ Same below. > properties: while other schemas use additionalProperties: false. > > The effect of using unevaluatedProperities: false in this instance is that > any property in media/video-interfaces.yaml can be considered in a dts for > an endpoint. > > Converting to additionalProperties: false and running DT checkers show that > such a liberal policy is unnecessary. > > We should have a consistent way of defining these properties if for no > other reason than aid other developers in the preferred way of writing > these schemas for media/i2c in the future. > > Convert to additionalProperties: as a result remote-endpoint needs to be > added to the property list for most sensors. In a few cases some > additional properties clock data-lanes or clock-lanes need to be added too > but, for-the-most-part remote-endpoint is the only missing property. > > Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> > --- > .../devicetree/bindings/media/i2c/alliedvision,alvium-csi2.yaml | 5 ++++- > Documentation/devicetree/bindings/media/i2c/galaxycore,gc05a2.yaml | 4 +++- > Documentation/devicetree/bindings/media/i2c/galaxycore,gc08a3.yaml | 4 +++- > Documentation/devicetree/bindings/media/i2c/galaxycore,gc2145.yaml | 6 +++++- > Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml | 4 +++- > Documentation/devicetree/bindings/media/i2c/imx219.yaml | 6 +++++- > Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml | 4 +++- > Documentation/devicetree/bindings/media/i2c/ovti,og01a1b.yaml | 4 +++- > Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml | 4 +++- > Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml | 4 +++- > Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml | 5 ++++- > Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml | 3 ++- > Documentation/devicetree/bindings/media/i2c/ovti,ov7251.yaml | 4 +++- > Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml | 5 ++++- > Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml | 4 +++- > Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml | 4 +++- > Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml | 4 +++- > Documentation/devicetree/bindings/media/i2c/sony,imx283.yaml | 4 +++- > Documentation/devicetree/bindings/media/i2c/sony,imx290.yaml | 4 +++- > Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml | 4 +++- > Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml | 4 +++- > Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml | 4 +++- > Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml | 4 +++- > 23 files changed, 75 insertions(+), 23 deletions(-) > > diff --git a/Documentation/devicetree/bindings/media/i2c/alliedvision,alvium-csi2.yaml b/Documentation/devicetree/bindings/media/i2c/alliedvision,alvium-csi2.yaml > index d3329e991d1652936fcf671012b8018e4317ea40..ba166ecf4fcbb77efab69ebcbdb46f5666af8e77 100644 > --- a/Documentation/devicetree/bindings/media/i2c/alliedvision,alvium-csi2.yaml > +++ b/Documentation/devicetree/bindings/media/i2c/alliedvision,alvium-csi2.yaml > @@ -32,7 +32,7 @@ properties: > properties: > endpoint: > $ref: /schemas/media/video-interfaces.yaml# > - unevaluatedProperties: false > + additionalProperties: false > > properties: > link-frequencies: true > @@ -45,9 +45,12 @@ properties: > - const: 3 > - const: 4 > > + remote-endpoint: true > + > required: > - data-lanes > - link-frequencies > + - remote-endpoint > > required: > - compatible > diff --git a/Documentation/devicetree/bindings/media/i2c/galaxycore,gc05a2.yaml b/Documentation/devicetree/bindings/media/i2c/galaxycore,gc05a2.yaml > index 0e7a7b5ac89f618e6cba0d86f6f7ea853e59ae1e..8b42440586aa8c853d8bf6046ccab0c3b23cb907 100644 > --- a/Documentation/devicetree/bindings/media/i2c/galaxycore,gc05a2.yaml > +++ b/Documentation/devicetree/bindings/media/i2c/galaxycore,gc05a2.yaml > @@ -44,7 +44,7 @@ properties: > properties: > endpoint: > $ref: /schemas/media/video-interfaces.yaml# > - unevaluatedProperties: false > + additionalProperties: false > > properties: > data-lanes: > @@ -59,10 +59,12 @@ properties: > - const: 2 > > link-frequencies: true > + remote-endpoint: true > > required: > - data-lanes > - link-frequencies > + - remote-endpoint > > required: > - endpoint > diff --git a/Documentation/devicetree/bindings/media/i2c/galaxycore,gc08a3.yaml b/Documentation/devicetree/bindings/media/i2c/galaxycore,gc08a3.yaml > index 51b8ece09c722e057fdb01b38d3e360e7604f39a..c15169ef901139411273e110523a311d87b4322e 100644 > --- a/Documentation/devicetree/bindings/media/i2c/galaxycore,gc08a3.yaml > +++ b/Documentation/devicetree/bindings/media/i2c/galaxycore,gc08a3.yaml > @@ -44,7 +44,7 @@ properties: > properties: > endpoint: > $ref: /schemas/media/video-interfaces.yaml# > - unevaluatedProperties: false > + additionalProperties: false > > properties: > data-lanes: > @@ -59,10 +59,12 @@ properties: > - const: 2 > > link-frequencies: true > + remote-endpoint: true > > required: > - data-lanes > - link-frequencies > + - remote-endpoint > > required: > - endpoint > diff --git a/Documentation/devicetree/bindings/media/i2c/galaxycore,gc2145.yaml b/Documentation/devicetree/bindings/media/i2c/galaxycore,gc2145.yaml > index 9eac588de0bc28d85f44663afe5472e35f1e652c..702625962d90ea7fafb4f4f4f865659097b51406 100644 > --- a/Documentation/devicetree/bindings/media/i2c/galaxycore,gc2145.yaml > +++ b/Documentation/devicetree/bindings/media/i2c/galaxycore,gc2145.yaml > @@ -56,13 +56,17 @@ properties: > properties: > endpoint: > $ref: /schemas/media/video-interfaces.yaml# > - unevaluatedProperties: false > + additionalProperties: false > > properties: > + data-lanes: true We should have a more precise constraint here. The sensor supports single or dual data lanes operation, so you can write data-lanes: minItems: 1 items: - const: 1 - const: 2 > link-frequencies: true > + remote-endpoint: true > > required: > + - data-lanes > - link-frequencies > + - remote-endpoint > > required: > - endpoint > diff --git a/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml b/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml > index d18ead8f7fc43bfacc291aed85b5ca9166c46edb..52bb089bd67fd0f9b5464e068b8db0b8e4406b3d 100644 > --- a/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml > +++ b/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml > @@ -52,7 +52,7 @@ properties: > properties: > endpoint: > $ref: /schemas/media/video-interfaces.yaml# > - unevaluatedProperties: false > + additionalProperties: false > > properties: > data-lanes: > @@ -67,10 +67,12 @@ properties: > - const: 2 > > link-frequencies: true > + remote-endpoint: true > > required: > - data-lanes > - link-frequencies > + - remote-endpoint > > required: > - compatible > diff --git a/Documentation/devicetree/bindings/media/i2c/imx219.yaml b/Documentation/devicetree/bindings/media/i2c/imx219.yaml > index 07d088cf66e0bde362b12d3494e5c91a1dd96bf3..5f395cf04b95ca47d5e685b8c43b8265db6910ae 100644 > --- a/Documentation/devicetree/bindings/media/i2c/imx219.yaml > +++ b/Documentation/devicetree/bindings/media/i2c/imx219.yaml > @@ -52,7 +52,7 @@ properties: > properties: > endpoint: > $ref: /schemas/media/video-interfaces.yaml# > - unevaluatedProperties: false > + additionalProperties: false > > properties: > data-lanes: > @@ -65,10 +65,14 @@ properties: > - const: 2 > > clock-noncontinuous: true > + clock-lanes: true This shouldn't be needed, as the sensor doesn't support clock lane remapping. Could we drop the clock-lanes property from upstream device tree sources instead ? > link-frequencies: true > + remote-endpoint: true > > required: > + - data-lanes > - link-frequencies > + - remote-endpoint > > required: > - compatible > diff --git a/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml b/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml > index f8ace8cbccdbac482ffba733d5b28a3a38aaf822..ce45bd8409597fa6989f632d68cd4aa1a468d152 100644 > --- a/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml > +++ b/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml > @@ -77,7 +77,7 @@ properties: > properties: > endpoint: > $ref: /schemas/media/video-interfaces.yaml# > - unevaluatedProperties: false > + additionalProperties: false > > properties: > link-frequencies: true > @@ -87,11 +87,13 @@ properties: > - 1 # CSI-2 C-PHY > - 3 # CCP2 > - 4 # CSI-2 D-PHY > + remote-endpoint: true > > required: > - link-frequencies > - data-lanes > - bus-type > + - remote-endpoint > > required: > - compatible > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,og01a1b.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,og01a1b.yaml > index ca57c01739d2b93100a37db56255ab717c1197ff..9b3738956c482d8826bf64f557c2e91630ea9799 100644 > --- a/Documentation/devicetree/bindings/media/i2c/ovti,og01a1b.yaml > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,og01a1b.yaml > @@ -55,7 +55,7 @@ properties: > properties: > endpoint: > $ref: /schemas/media/video-interfaces.yaml# > - unevaluatedProperties: false > + additionalProperties: false > > properties: > data-lanes: > @@ -65,10 +65,12 @@ properties: > enum: [1, 2] > > link-frequencies: true > + remote-endpoint: true > > required: > - data-lanes > - link-frequencies > + - remote-endpoint > > required: > - compatible > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml > index 67c1c291327b7febb6a039bf6f28c8dc1f32ed7f..b8db4be137085fe31ec2f076c7dc66b30bf0b66c 100644 > --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml > @@ -77,7 +77,7 @@ properties: > properties: > endpoint: > $ref: /schemas/media/video-interfaces.yaml# > - unevaluatedProperties: false > + additionalProperties: false > > properties: > link-frequencies: true > @@ -88,9 +88,11 @@ properties: > the link speed defined by the 'link-frequencies' property. > If present, the value shall be in the range of 0-4. > default: 4 > + remote-endpoint: true > > required: > - link-frequencies > + - remote-endpoint > > required: > - endpoint > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml > index d96199031b66c5c162a034824f195e277f2a1795..7499523a6e0fbd64b9b980333adaa14a0c40a33b 100644 > --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml > @@ -61,7 +61,7 @@ properties: > properties: > endpoint: > $ref: /schemas/media/video-interfaces.yaml# > - unevaluatedProperties: false > + additionalProperties: false > > properties: > data-lanes: > @@ -77,10 +77,12 @@ properties: > - items: > - const: 1 > link-frequencies: true > + remote-endpoint: true > > required: > - data-lanes > - link-frequencies > + - remote-endpoint > > required: > - compatible > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml > index 622243cae03caa5d14aa312df40ef5907e190d2c..358c0422451f7faa8e0ebfc9226a5cfb087e3598 100644 > --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml > @@ -45,7 +45,7 @@ properties: > properties: > endpoint: > $ref: /schemas/media/video-interfaces.yaml# > - unevaluatedProperties: false > + additionalProperties: false > > properties: > link-frequencies: true > @@ -54,9 +54,12 @@ properties: > minItems: 1 > maxItems: 2 > > + remote-endpoint: true > + > required: > - data-lanes > - link-frequencies > + - remote-endpoint > > required: > - compatible > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml > index ad07204057f979ade534d29c99c3aff7372bd332..eff212524bf3c7b1ec6aa7e826d4318d58ba53a5 100644 > --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml > @@ -60,7 +60,7 @@ properties: > properties: > endpoint: > $ref: /schemas/media/video-interfaces.yaml# > - unevaluatedProperties: false > + additionalProperties: false > > properties: > data-lanes: > @@ -69,6 +69,7 @@ properties: > > # Supports max data transfer of 900 Mbps per lane > link-frequencies: true > + remote-endpoint: true > > required: > - compatible > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov7251.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov7251.yaml > index 2e5187acbbb89728cbb8a402559d24766198a3da..cbbe3c9ce151eb33d2b0cc1a44e6ebf66d9b59fa 100644 > --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov7251.yaml > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov7251.yaml > @@ -53,7 +53,7 @@ properties: > properties: > endpoint: > $ref: /schemas/media/video-interfaces.yaml# > - unevaluatedProperties: false > + additionalProperties: false > > properties: > clock-lanes: > @@ -63,10 +63,12 @@ properties: > maxItems: 1 > > link-frequencies: true > + remote-endpoint: true > > required: > - data-lanes > - link-frequencies > + - remote-endpoint > > required: > - compatible > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml > index 382d7de7a89bcea11be384a2a3800512994f9346..dd5c5715fdcfc00e6d851f375f41e4d077b92bc0 100644 > --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml > @@ -45,7 +45,7 @@ properties: > properties: > endpoint: > $ref: /schemas/media/video-interfaces.yaml# > - unevaluatedProperties: false > + additionalProperties: false > > properties: > link-frequencies: true > @@ -54,9 +54,12 @@ properties: > minItems: 1 > maxItems: 4 > > + remote-endpoint: true > + > required: > - data-lanes > - link-frequencies > + - remote-endpoint > > required: > - compatible > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml > index 38325cf318f7bd2cd60a4c7bbb6a65b54b855e26..dde4e7426bf00920f1bd9ed1bf4d8594932dedaf 100644 > --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml > @@ -51,15 +51,17 @@ properties: > properties: > endpoint: > $ref: /schemas/media/video-interfaces.yaml# > - unevaluatedProperties: false > + additionalProperties: false > > properties: > data-lanes: true > link-frequencies: true > + remote-endpoint: true > > required: > - data-lanes > - link-frequencies > + - remote-endpoint > > required: > - endpoint > diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml > index 0162eec8ca993a7614d29908f89fa9fe6d4b545d..9b78ff6bd5f114c7f63ac90e71fa677445ddf702 100644 > --- a/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml > +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml > @@ -58,7 +58,7 @@ properties: > properties: > endpoint: > $ref: /schemas/media/video-interfaces.yaml# > - unevaluatedProperties: false > + additionalProperties: false > > properties: > data-lanes: > @@ -73,10 +73,12 @@ properties: > - const: 4 > > link-frequencies: true > + remote-endpoint: true > > required: > - data-lanes > - link-frequencies > + - remote-endpoint > > additionalProperties: false > > diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml > index f0f9726a2add89492b8c56e17ed607841baa3a0d..4cf49472c24f1b800f6d2e41b8716e2ac32f959a 100644 > --- a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml > +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml > @@ -56,7 +56,7 @@ properties: > properties: > endpoint: > $ref: /schemas/media/video-interfaces.yaml# > - unevaluatedProperties: false > + additionalProperties: false > > properties: > data-lanes: > @@ -71,10 +71,12 @@ properties: > - const: 2 > > link-frequencies: true > + remote-endpoint: true > > required: > - data-lanes > - link-frequencies > + - remote-endpoint > > required: > - compatible > diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx283.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx283.yaml > index e4f49f1435a5c2e6e1507d250662ea6ecbf3c7dc..75b78a3e925ed2fd09f56c8349d234a32739f141 100644 > --- a/Documentation/devicetree/bindings/media/i2c/sony,imx283.yaml > +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx283.yaml > @@ -48,7 +48,7 @@ properties: > properties: > endpoint: > $ref: /schemas/media/video-interfaces.yaml# > - unevaluatedProperties: false > + additionalProperties: false > > properties: > data-lanes: > @@ -60,10 +60,12 @@ properties: > - const: 4 > > link-frequencies: true > + remote-endpoint: true > > required: > - data-lanes > - link-frequencies > + - remote-endpoint > > required: > - endpoint > diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx290.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx290.yaml > index bf05ca48601abda53d60a3d03aa556e7b8fd825b..e6aec7a1ba2b22a11111d19a61384f1200041df5 100644 > --- a/Documentation/devicetree/bindings/media/i2c/sony,imx290.yaml > +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx290.yaml > @@ -71,7 +71,7 @@ properties: > properties: > endpoint: > $ref: /schemas/media/video-interfaces.yaml# > - unevaluatedProperties: false > + additionalProperties: false > > properties: > data-lanes: > @@ -86,10 +86,12 @@ properties: > - const: 4 > > link-frequencies: true > + remote-endpoint: true > > required: > - data-lanes > - link-frequencies > + - remote-endpoint > > additionalProperties: false > > diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml > index 872b8288948b2bba743f2365a55165181df156ae..d30ef330e5af225728d1a6c40b26050cd33ba4be 100644 > --- a/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml > +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml > @@ -38,15 +38,17 @@ properties: > properties: > endpoint: > $ref: /schemas/media/video-interfaces.yaml# > - unevaluatedProperties: false > + additionalProperties: false > > properties: > data-lanes: true > link-frequencies: true > + remote-endpoint: true > > required: > - data-lanes > - link-frequencies > + - remote-endpoint > > required: > - endpoint > diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml > index 38bd1c7304a59bb5fea90954c1e4e626a7c86f2f..36c3a0ba7822475770cd903cec3343d31bb66520 100644 > --- a/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml > +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml > @@ -48,15 +48,17 @@ properties: > properties: > endpoint: > $ref: /schemas/media/video-interfaces.yaml# > - unevaluatedProperties: false > + additionalProperties: false > > properties: > data-lanes: true > link-frequencies: true > + remote-endpoint: true > > required: > - data-lanes > - link-frequencies > + - remote-endpoint > > required: > - endpoint > diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml > index ece1e17fe34553671e61c965eb1833c5eb08131b..0bbdf657a8c0643ffe512ae04c14dfc8e6b4fc94 100644 > --- a/Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml > +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml > @@ -50,15 +50,17 @@ properties: > properties: > endpoint: > $ref: /schemas/media/video-interfaces.yaml# > - unevaluatedProperties: false > + additionalProperties: false > > properties: > data-lanes: true > link-frequencies: true > + remote-endpoint: true > > required: > - data-lanes > - link-frequencies > + - remote-endpoint > > required: > - endpoint > diff --git a/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml b/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml > index 1c476b635b690865cff0882578d72b1db2dc7c50..367d669ad864ed6b2a8762f953f58e206c8c8194 100644 > --- a/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml > +++ b/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml > @@ -96,7 +96,7 @@ properties: > properties: > endpoint: > $ref: /schemas/media/video-interfaces.yaml# > - unevaluatedProperties: false > + additionalProperties: false > > properties: > data-lanes: > @@ -105,10 +105,12 @@ properties: > > clock-noncontinuous: true > link-frequencies: true > + remote-endpoint: true > > required: > - data-lanes > - link-frequencies > + - remote-endpoint > > required: > - port@0 >
On 12/10/2024 19:09, Laurent Pinchart wrote: >> + clock-lanes: true > This shouldn't be needed, as the sensor doesn't support clock lane > remapping. Could we drop the clock-lanes property from upstream device > tree sources instead ? Yes probably. --- bod
On Sat, Oct 12, 2024 at 04:02:51PM +0100, Bryan O'Donoghue wrote: > Some of our sensor schemas use unevaluatedProperities: false for endpoint: > properties: while other schemas use additionalProperties: false. > > The effect of using unevaluatedProperities: false in this instance is that > any property in media/video-interfaces.yaml can be considered in a dts for > an endpoint. ... which is what we want and what is expected. You change the code from expected to less expected variant, so please clearly document why. > > Converting to additionalProperties: false and running DT checkers show that > such a liberal policy is unnecessary. > > We should have a consistent way of defining these properties if for no > other reason than aid other developers in the preferred way of writing > these schemas for media/i2c in the future. There is consistent way - common schema defines them. I do not understand the reasoning behind this change at all. I don't think DT maintainers ever suggested it (in fact, rather opposite: suggested using unevaluatedProps) and I think is not a consensus of any talks. Best regards, Krzysztof
On 14/10/2024 08:45, Krzysztof Kozlowski wrote: > I do not understand the reasoning behind this change at all. I don't > think DT maintainers ever suggested it (in fact, rather opposite: > suggested using unevaluatedProps) and I think is not a consensus of any > talks. No there is not but then, how do you give consistent feedback except proposing something to be a baseline. On the one hand you have upstream additionalProperties: false and unevaluatedProperites: false - it'd be better to have a consistent message on which is to be used. --- bod
On 14/10/2024 10:31, Bryan O'Donoghue wrote: > On 14/10/2024 08:45, Krzysztof Kozlowski wrote: >> I do not understand the reasoning behind this change at all. I don't >> think DT maintainers ever suggested it (in fact, rather opposite: >> suggested using unevaluatedProps) and I think is not a consensus of any >> talks. > > No there is not but then, how do you give consistent feedback except > proposing something to be a baseline. > > On the one hand you have upstream additionalProperties: false and > unevaluatedProperites: false - it'd be better to have a consistent > message on which is to be used. Well, I am afraid that push towards additionalProps will lead to grow common schema (video-interface-devices or video-interfaces) into huge one-fit-all binding. And that's not good. If a common binding for a group of devices encourages you to list its subset, then it is not that common. Solution is to fix that, e.g. split it per classes of devices. Or don't care and use unevaluatedProps because it makes people's life easier and is still correct. If it is not correct, then this should be used as an argument. Best regards, Krzysztof
On 14/10/2024 09:47, Krzysztof Kozlowski wrote: > If a common binding for a group of devices encourages you to list its > subset, then it is not that common. > > Solution is to fix that, e.g. split it per classes of devices. It might be possible to have $ref: /schemas/media/video-interfaces-endpoint-defaults.yaml# which declares the typical list -> $ref: /schemas/media/video-interfaces.yaml# additonalProperties:false properties: data-lanes: true link-frequencies: true remote-endpoints: true required: data-lanes link-frequencies remote-endpoints and then if you need say clock-noncontinuous you'd just include $ref: /schemas/media/video-interfaces.yaml# unevaluatedProperties: false and then list whatever you need > Or don't care and use unevaluatedProps because it makes people's life > easier and is still correct. If it is not correct, then this should be > used as an argument. I'll wait to see what people think before progressing this patch further. --- bod
On 14/10/2024 11:03, Bryan O'Donoghue wrote: > On 14/10/2024 09:47, Krzysztof Kozlowski wrote: >> If a common binding for a group of devices encourages you to list its >> subset, then it is not that common. >> >> Solution is to fix that, e.g. split it per classes of devices. > > It might be possible to have > > $ref: /schemas/media/video-interfaces-endpoint-defaults.yaml# > > which declares the typical list -> > > $ref: /schemas/media/video-interfaces.yaml# > additonalProperties:false I meant something else - define common schema matching this class of devices. Not a schema for some defaults. This is supposed to reflect how we look at hardware, not some library of schemas or library of functions. > > properties: > data-lanes: true > link-frequencies: true > remote-endpoints: true and I still don't like all these. I rather expect people to list the hardware constraints or just drop it. I mentioned it some time ago in the first patch you sent, which I think started this entire discussion. > > required: > data-lanes > link-frequencies > remote-endpoints > > and then if you need say clock-noncontinuous you'd just include > > $ref: /schemas/media/video-interfaces.yaml# > unevaluatedProperties: false > > and then list whatever you need > >> Or don't care and use unevaluatedProps because it makes people's life >> easier and is still correct. If it is not correct, then this should be >> used as an argument. > > I'll wait to see what people think before progressing this patch further. Best regards, Krzysztof
On Mon, Oct 14, 2024 at 10:47:31AM +0200, Krzysztof Kozlowski wrote: > On 14/10/2024 10:31, Bryan O'Donoghue wrote: > > On 14/10/2024 08:45, Krzysztof Kozlowski wrote: > >> I do not understand the reasoning behind this change at all. I don't > >> think DT maintainers ever suggested it (in fact, rather opposite: > >> suggested using unevaluatedProps) and I think is not a consensus of any > >> talks. > > > > No there is not but then, how do you give consistent feedback except > > proposing something to be a baseline. > > > > On the one hand you have upstream additionalProperties: false and > > unevaluatedProperites: false - it'd be better to have a consistent > > message on which is to be used. > > Well, I am afraid that push towards additionalProps will lead to grow > common schema (video-interface-devices or video-interfaces) into huge > one-fit-all binding. And that's not good. > > If a common binding for a group of devices encourages you to list its > subset, then it is not that common. > > Solution is to fix that, e.g. split it per classes of devices. I think splitting large schemas per class is a good idea, but the problem will still exist. For instance, if we were to move the CSI-2-specific properties to a separate schema, that schema would define clock-lanes, data-lanes and clock-noncontinuous. The clock-lanes and clock-noncontinuous properties do not apply to every device, how would we then handle that ? I see three options: - Use "additionalProperties: false" and explicitly list the properties that apply to the device with "$prop: true". This is what this series does. - Use "unevaluatedProperites: false" and explicitly list the properties that do not apply to the device with "$prop: false". The drawback is that any property being added to the common schema will require modifications to all bindings that use the schema. - Use "unevaluatedProperites: false" and don't list any property with "$prop: false". This is what is being done today in many bindings. The drawback is that device tree sources that specify invalid properties for the device will validate. Among those options, my preference goes to the first one. It catches the most issues in device tree sources, while not having the drawback of the second option. It requires explicitly listing the valid properties, but I don't consider that as a drawback, I think it's actually a good thing as it clearly shows to the developers which properties are valid. Are there other options I haven't considered ? > Or don't care and use unevaluatedProps because it makes people's life > easier and is still correct. If it is not correct, then this should be > used as an argument.
On 14/10/2024 22:29, Laurent Pinchart wrote: > On Mon, Oct 14, 2024 at 10:47:31AM +0200, Krzysztof Kozlowski wrote: >> On 14/10/2024 10:31, Bryan O'Donoghue wrote: >>> On 14/10/2024 08:45, Krzysztof Kozlowski wrote: >>>> I do not understand the reasoning behind this change at all. I don't >>>> think DT maintainers ever suggested it (in fact, rather opposite: >>>> suggested using unevaluatedProps) and I think is not a consensus of any >>>> talks. >>> >>> No there is not but then, how do you give consistent feedback except >>> proposing something to be a baseline. >>> >>> On the one hand you have upstream additionalProperties: false and >>> unevaluatedProperites: false - it'd be better to have a consistent >>> message on which is to be used. >> >> Well, I am afraid that push towards additionalProps will lead to grow >> common schema (video-interface-devices or video-interfaces) into huge >> one-fit-all binding. And that's not good. >> >> If a common binding for a group of devices encourages you to list its >> subset, then it is not that common. >> >> Solution is to fix that, e.g. split it per classes of devices. > > I think splitting large schemas per class is a good idea, but the > problem will still exist. For instance, if we were to move the > CSI-2-specific properties to a separate schema, that schema would define > clock-lanes, data-lanes and clock-noncontinuous. The clock-lanes and > clock-noncontinuous properties do not apply to every device, how would > we then handle that ? I see three options: Why is this a problem? Why is this a problem here, but not in other subsystems having exactly the same case? Best regards, Krzysztof
Hi Krzysztof, On Tue, Oct 15, 2024 at 08:11:18AM +0200, Krzysztof Kozlowski wrote: > On 14/10/2024 22:29, Laurent Pinchart wrote: > > On Mon, Oct 14, 2024 at 10:47:31AM +0200, Krzysztof Kozlowski wrote: > >> On 14/10/2024 10:31, Bryan O'Donoghue wrote: > >>> On 14/10/2024 08:45, Krzysztof Kozlowski wrote: > >>>> I do not understand the reasoning behind this change at all. I don't > >>>> think DT maintainers ever suggested it (in fact, rather opposite: > >>>> suggested using unevaluatedProps) and I think is not a consensus of any > >>>> talks. > >>> > >>> No there is not but then, how do you give consistent feedback except > >>> proposing something to be a baseline. > >>> > >>> On the one hand you have upstream additionalProperties: false and > >>> unevaluatedProperites: false - it'd be better to have a consistent > >>> message on which is to be used. > >> > >> Well, I am afraid that push towards additionalProps will lead to grow > >> common schema (video-interface-devices or video-interfaces) into huge > >> one-fit-all binding. And that's not good. > >> > >> If a common binding for a group of devices encourages you to list its > >> subset, then it is not that common. > >> > >> Solution is to fix that, e.g. split it per classes of devices. > > > > I think splitting large schemas per class is a good idea, but the > > problem will still exist. For instance, if we were to move the > > CSI-2-specific properties to a separate schema, that schema would define > > clock-lanes, data-lanes and clock-noncontinuous. The clock-lanes and > > clock-noncontinuous properties do not apply to every device, how would > > we then handle that ? I see three options: > > Why is this a problem? Why is this a problem here, but not in other > subsystems having exactly the same case? I won't talk for other subsystems, but I can say I see value in explicitly expressing what properties are valid for a device in DT bindings both to inform DT authors and to perform validation on DT sources. That's the whole point of YAML schemas, and I can't see a good reason not to use the tooling we have developed when it has an easy way to do the job.
On 15/10/2024 13:28, Laurent Pinchart wrote: > Hi Krzysztof, > > On Tue, Oct 15, 2024 at 08:11:18AM +0200, Krzysztof Kozlowski wrote: >> On 14/10/2024 22:29, Laurent Pinchart wrote: >>> On Mon, Oct 14, 2024 at 10:47:31AM +0200, Krzysztof Kozlowski wrote: >>>> On 14/10/2024 10:31, Bryan O'Donoghue wrote: >>>>> On 14/10/2024 08:45, Krzysztof Kozlowski wrote: >>>>>> I do not understand the reasoning behind this change at all. I don't >>>>>> think DT maintainers ever suggested it (in fact, rather opposite: >>>>>> suggested using unevaluatedProps) and I think is not a consensus of any >>>>>> talks. >>>>> >>>>> No there is not but then, how do you give consistent feedback except >>>>> proposing something to be a baseline. >>>>> >>>>> On the one hand you have upstream additionalProperties: false and >>>>> unevaluatedProperites: false - it'd be better to have a consistent >>>>> message on which is to be used. >>>> >>>> Well, I am afraid that push towards additionalProps will lead to grow >>>> common schema (video-interface-devices or video-interfaces) into huge >>>> one-fit-all binding. And that's not good. >>>> >>>> If a common binding for a group of devices encourages you to list its >>>> subset, then it is not that common. >>>> >>>> Solution is to fix that, e.g. split it per classes of devices. >>> >>> I think splitting large schemas per class is a good idea, but the >>> problem will still exist. For instance, if we were to move the >>> CSI-2-specific properties to a separate schema, that schema would define >>> clock-lanes, data-lanes and clock-noncontinuous. The clock-lanes and >>> clock-noncontinuous properties do not apply to every device, how would >>> we then handle that ? I see three options: >> >> Why is this a problem? Why is this a problem here, but not in other >> subsystems having exactly the same case? > > I won't talk for other subsystems, but I can say I see value in > explicitly expressing what properties are valid for a device in DT > bindings both to inform DT authors and to perform validation on DT > sources. That's the whole point of YAML schemas, and I can't see a good > reason not to use the tooling we have developed when it has an easy way > to do the job. I understand. The benefit, which you see, comes with complexity of the binding and need of listing properties. We do not enforce such rules (narrowing common schema in very strict way) in other subsystems, maybe with exception of input and touchscreen devices, but there common schema is quite big. And DT maintainers suggested to drop such code even for these, BTW. Best regards, Krzysztof
On Tue, Oct 15, 2024 at 02:28:06PM +0300, Laurent Pinchart wrote: > Hi Krzysztof, > > On Tue, Oct 15, 2024 at 08:11:18AM +0200, Krzysztof Kozlowski wrote: > > On 14/10/2024 22:29, Laurent Pinchart wrote: > > > On Mon, Oct 14, 2024 at 10:47:31AM +0200, Krzysztof Kozlowski wrote: > > >> On 14/10/2024 10:31, Bryan O'Donoghue wrote: > > >>> On 14/10/2024 08:45, Krzysztof Kozlowski wrote: > > >>>> I do not understand the reasoning behind this change at all. I don't > > >>>> think DT maintainers ever suggested it (in fact, rather opposite: > > >>>> suggested using unevaluatedProps) and I think is not a consensus of any > > >>>> talks. > > >>> > > >>> No there is not but then, how do you give consistent feedback except > > >>> proposing something to be a baseline. > > >>> > > >>> On the one hand you have upstream additionalProperties: false and > > >>> unevaluatedProperites: false - it'd be better to have a consistent > > >>> message on which is to be used. There are 3 options: - no $ref => additionalProperties - has a $ref: - additionalProperties and list ref-ed properties - unevaluatedProperties and don't list ref-ed properties I do debate (with myself) that that is too complicated as many don't understand the difference. We could go back to always using additionalProperties which is what we had before unevaluatedProperties was added. The other option is always use unevaluatedProperties. 2 things have stopped me from going that route. I don't care to fix 'additionalProperties' treewide which would be necessary to implement a meta-schema or check that unevaluatedProperties is used. It's not something I want to manually check in reviews. The other reason is just to not change what the rules are again. > > >> > > >> Well, I am afraid that push towards additionalProps will lead to grow > > >> common schema (video-interface-devices or video-interfaces) into huge > > >> one-fit-all binding. And that's not good. > > >> > > >> If a common binding for a group of devices encourages you to list its > > >> subset, then it is not that common. > > >> > > >> Solution is to fix that, e.g. split it per classes of devices. > > > > > > I think splitting large schemas per class is a good idea, but the > > > problem will still exist. For instance, if we were to move the > > > CSI-2-specific properties to a separate schema, that schema would define > > > clock-lanes, data-lanes and clock-noncontinuous. The clock-lanes and > > > clock-noncontinuous properties do not apply to every device, how would > > > we then handle that ? I see three options: > > > > Why is this a problem? Why is this a problem here, but not in other > > subsystems having exactly the same case? > > I won't talk for other subsystems, but I can say I see value in > explicitly expressing what properties are valid for a device in DT > bindings both to inform DT authors and to perform validation on DT > sources. That's the whole point of YAML schemas, and I can't see a good > reason not to use the tooling we have developed when it has an easy way > to do the job. This topic is just one piece of validation. A property being used that's defined, but meaningless for a device is low on the list of what I care about validating. I can't see how it would cause an actual problem? A driver is going to read the property and do what with it? Could it be an ABI issue ever? I can't see how other than a driver failing for some reason if it finds the property, but that seems a bit far fetched. Rob
On 15/10/2024 20:44, Rob Herring wrote: > On Tue, Oct 15, 2024 at 02:28:06PM +0300, Laurent Pinchart wrote: >> Hi Krzysztof, >> >> On Tue, Oct 15, 2024 at 08:11:18AM +0200, Krzysztof Kozlowski wrote: >>> On 14/10/2024 22:29, Laurent Pinchart wrote: >>>> On Mon, Oct 14, 2024 at 10:47:31AM +0200, Krzysztof Kozlowski wrote: >>>>> On 14/10/2024 10:31, Bryan O'Donoghue wrote: >>>>>> On 14/10/2024 08:45, Krzysztof Kozlowski wrote: >>>>>>> I do not understand the reasoning behind this change at all. I don't >>>>>>> think DT maintainers ever suggested it (in fact, rather opposite: >>>>>>> suggested using unevaluatedProps) and I think is not a consensus of any >>>>>>> talks. >>>>>> >>>>>> No there is not but then, how do you give consistent feedback except >>>>>> proposing something to be a baseline. >>>>>> >>>>>> On the one hand you have upstream additionalProperties: false and >>>>>> unevaluatedProperites: false - it'd be better to have a consistent >>>>>> message on which is to be used. > > There are 3 options: > > - no $ref => additionalProperties I interpret this to mean that omitting additionalProperties/unevaluatedProperties is logically the same as having additionalProperties as you will then need to list the properties explicitly. > - has a $ref: > - additionalProperties and list ref-ed properties > - unevaluatedProperties and don't list ref-ed properties > > I do debate (with myself) that that is too complicated as many don't > understand the difference. We could go back to always using > additionalProperties which is what we had before unevaluatedProperties > was added. The other option is always use unevaluatedProperties. 2 > things have stopped me from going that route. I don't care to fix > 'additionalProperties' treewide which would be necessary to implement a > meta-schema or check that unevaluatedProperties is used. It's not > something I want to manually check in reviews. The other reason is just > to not change what the rules are again. Right so I received feedback to change link-frequencies if I recall. I thought I had been very-clever (tm) by copying an upstream source and when I received feedback to change assumed the upstream source I had copied had bit-rot w/r/t the current preferred way. Some additional discussion shows there really isn't a preferred way at present. Is there a place to meaningfully document that conclusion instead both for reviewers and implementers ? Should I already know the answer to that question ? --- bod
Hi Krzysztof, On Tue, Oct 15, 2024 at 01:51:43PM +0200, Krzysztof Kozlowski wrote: > On 15/10/2024 13:28, Laurent Pinchart wrote: > > On Tue, Oct 15, 2024 at 08:11:18AM +0200, Krzysztof Kozlowski wrote: > >> On 14/10/2024 22:29, Laurent Pinchart wrote: > >>> On Mon, Oct 14, 2024 at 10:47:31AM +0200, Krzysztof Kozlowski wrote: > >>>> On 14/10/2024 10:31, Bryan O'Donoghue wrote: > >>>>> On 14/10/2024 08:45, Krzysztof Kozlowski wrote: > >>>>>> I do not understand the reasoning behind this change at all. I don't > >>>>>> think DT maintainers ever suggested it (in fact, rather opposite: > >>>>>> suggested using unevaluatedProps) and I think is not a consensus of any > >>>>>> talks. > >>>>> > >>>>> No there is not but then, how do you give consistent feedback except > >>>>> proposing something to be a baseline. > >>>>> > >>>>> On the one hand you have upstream additionalProperties: false and > >>>>> unevaluatedProperites: false - it'd be better to have a consistent > >>>>> message on which is to be used. > >>>> > >>>> Well, I am afraid that push towards additionalProps will lead to grow > >>>> common schema (video-interface-devices or video-interfaces) into huge > >>>> one-fit-all binding. And that's not good. > >>>> > >>>> If a common binding for a group of devices encourages you to list its > >>>> subset, then it is not that common. > >>>> > >>>> Solution is to fix that, e.g. split it per classes of devices. > >>> > >>> I think splitting large schemas per class is a good idea, but the > >>> problem will still exist. For instance, if we were to move the > >>> CSI-2-specific properties to a separate schema, that schema would define > >>> clock-lanes, data-lanes and clock-noncontinuous. The clock-lanes and > >>> clock-noncontinuous properties do not apply to every device, how would > >>> we then handle that ? I see three options: > >> > >> Why is this a problem? Why is this a problem here, but not in other > >> subsystems having exactly the same case? > > > > I won't talk for other subsystems, but I can say I see value in > > explicitly expressing what properties are valid for a device in DT > > bindings both to inform DT authors and to perform validation on DT > > sources. That's the whole point of YAML schemas, and I can't see a good > > reason not to use the tooling we have developed when it has an easy way > > to do the job. > > I understand. The benefit, which you see, comes with complexity of the > binding and need of listing properties. I agree, the benefit comes at a cost of additional complexity in the bindings. For me the benefit outweights the cost here as I find the cost to be relatively small, but I understand that this is a personal opinion. > We do not enforce such rules (narrowing common schema in very strict > way) in other subsystems, maybe with exception of input and touchscreen > devices, but there common schema is quite big. And DT maintainers > suggested to drop such code even for these, BTW.
Hi Rob, On Tue, Oct 15, 2024 at 02:44:18PM -0500, Rob Herring wrote: > On Tue, Oct 15, 2024 at 02:28:06PM +0300, Laurent Pinchart wrote: > > On Tue, Oct 15, 2024 at 08:11:18AM +0200, Krzysztof Kozlowski wrote: > > > On 14/10/2024 22:29, Laurent Pinchart wrote: > > > > On Mon, Oct 14, 2024 at 10:47:31AM +0200, Krzysztof Kozlowski wrote: > > > >> On 14/10/2024 10:31, Bryan O'Donoghue wrote: > > > >>> On 14/10/2024 08:45, Krzysztof Kozlowski wrote: > > > >>>> I do not understand the reasoning behind this change at all. I don't > > > >>>> think DT maintainers ever suggested it (in fact, rather opposite: > > > >>>> suggested using unevaluatedProps) and I think is not a consensus of any > > > >>>> talks. > > > >>> > > > >>> No there is not but then, how do you give consistent feedback except > > > >>> proposing something to be a baseline. > > > >>> > > > >>> On the one hand you have upstream additionalProperties: false and > > > >>> unevaluatedProperites: false - it'd be better to have a consistent > > > >>> message on which is to be used. > > There are 3 options: > > - no $ref => additionalProperties > - has a $ref: > - additionalProperties and list ref-ed properties > - unevaluatedProperties and don't list ref-ed properties > > I do debate (with myself) Those are the best and worst debates at the same time :-) > that that is too complicated as many don't > understand the difference. We could go back to always using > additionalProperties which is what we had before unevaluatedProperties > was added. The other option is always use unevaluatedProperties. 2 > things have stopped me from going that route. I don't care to fix > 'additionalProperties' treewide which would be necessary to implement a > meta-schema or check that unevaluatedProperties is used. It's not > something I want to manually check in reviews. The other reason is just > to not change what the rules are again. > > > > >> > > > >> Well, I am afraid that push towards additionalProps will lead to grow > > > >> common schema (video-interface-devices or video-interfaces) into huge > > > >> one-fit-all binding. And that's not good. > > > >> > > > >> If a common binding for a group of devices encourages you to list its > > > >> subset, then it is not that common. > > > >> > > > >> Solution is to fix that, e.g. split it per classes of devices. > > > > > > > > I think splitting large schemas per class is a good idea, but the > > > > problem will still exist. For instance, if we were to move the > > > > CSI-2-specific properties to a separate schema, that schema would define > > > > clock-lanes, data-lanes and clock-noncontinuous. The clock-lanes and > > > > clock-noncontinuous properties do not apply to every device, how would > > > > we then handle that ? I see three options: > > > > > > Why is this a problem? Why is this a problem here, but not in other > > > subsystems having exactly the same case? > > > > I won't talk for other subsystems, but I can say I see value in > > explicitly expressing what properties are valid for a device in DT > > bindings both to inform DT authors and to perform validation on DT > > sources. That's the whole point of YAML schemas, and I can't see a good > > reason not to use the tooling we have developed when it has an easy way > > to do the job. > > This topic is just one piece of validation. A property being used that's > defined, but meaningless for a device is low on the list of what I care > about validating. I can't see how it would cause an actual problem? A > driver is going to read the property and do what with it? Could it be an > ABI issue ever? I can't see how other than a driver failing for some > reason if it finds the property, but that seems a bit far fetched. I agree the risk of issues at runtime is quite low. My personal take on this is that the additional complexity of specifying "$prop: true" in the bindings is low (for me at least), and the increased correctness in DT sources to avoid confusion for DT readers is worth it. I also like how more explicit bindings cleary show in a single place what properties are expected, making it easier for DT authors. That's a personal opinion though.
diff --git a/Documentation/devicetree/bindings/media/i2c/alliedvision,alvium-csi2.yaml b/Documentation/devicetree/bindings/media/i2c/alliedvision,alvium-csi2.yaml index d3329e991d1652936fcf671012b8018e4317ea40..ba166ecf4fcbb77efab69ebcbdb46f5666af8e77 100644 --- a/Documentation/devicetree/bindings/media/i2c/alliedvision,alvium-csi2.yaml +++ b/Documentation/devicetree/bindings/media/i2c/alliedvision,alvium-csi2.yaml @@ -32,7 +32,7 @@ properties: properties: endpoint: $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false + additionalProperties: false properties: link-frequencies: true @@ -45,9 +45,12 @@ properties: - const: 3 - const: 4 + remote-endpoint: true + required: - data-lanes - link-frequencies + - remote-endpoint required: - compatible diff --git a/Documentation/devicetree/bindings/media/i2c/galaxycore,gc05a2.yaml b/Documentation/devicetree/bindings/media/i2c/galaxycore,gc05a2.yaml index 0e7a7b5ac89f618e6cba0d86f6f7ea853e59ae1e..8b42440586aa8c853d8bf6046ccab0c3b23cb907 100644 --- a/Documentation/devicetree/bindings/media/i2c/galaxycore,gc05a2.yaml +++ b/Documentation/devicetree/bindings/media/i2c/galaxycore,gc05a2.yaml @@ -44,7 +44,7 @@ properties: properties: endpoint: $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false + additionalProperties: false properties: data-lanes: @@ -59,10 +59,12 @@ properties: - const: 2 link-frequencies: true + remote-endpoint: true required: - data-lanes - link-frequencies + - remote-endpoint required: - endpoint diff --git a/Documentation/devicetree/bindings/media/i2c/galaxycore,gc08a3.yaml b/Documentation/devicetree/bindings/media/i2c/galaxycore,gc08a3.yaml index 51b8ece09c722e057fdb01b38d3e360e7604f39a..c15169ef901139411273e110523a311d87b4322e 100644 --- a/Documentation/devicetree/bindings/media/i2c/galaxycore,gc08a3.yaml +++ b/Documentation/devicetree/bindings/media/i2c/galaxycore,gc08a3.yaml @@ -44,7 +44,7 @@ properties: properties: endpoint: $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false + additionalProperties: false properties: data-lanes: @@ -59,10 +59,12 @@ properties: - const: 2 link-frequencies: true + remote-endpoint: true required: - data-lanes - link-frequencies + - remote-endpoint required: - endpoint diff --git a/Documentation/devicetree/bindings/media/i2c/galaxycore,gc2145.yaml b/Documentation/devicetree/bindings/media/i2c/galaxycore,gc2145.yaml index 9eac588de0bc28d85f44663afe5472e35f1e652c..702625962d90ea7fafb4f4f4f865659097b51406 100644 --- a/Documentation/devicetree/bindings/media/i2c/galaxycore,gc2145.yaml +++ b/Documentation/devicetree/bindings/media/i2c/galaxycore,gc2145.yaml @@ -56,13 +56,17 @@ properties: properties: endpoint: $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false + additionalProperties: false properties: + data-lanes: true link-frequencies: true + remote-endpoint: true required: + - data-lanes - link-frequencies + - remote-endpoint required: - endpoint diff --git a/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml b/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml index d18ead8f7fc43bfacc291aed85b5ca9166c46edb..52bb089bd67fd0f9b5464e068b8db0b8e4406b3d 100644 --- a/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml +++ b/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml @@ -52,7 +52,7 @@ properties: properties: endpoint: $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false + additionalProperties: false properties: data-lanes: @@ -67,10 +67,12 @@ properties: - const: 2 link-frequencies: true + remote-endpoint: true required: - data-lanes - link-frequencies + - remote-endpoint required: - compatible diff --git a/Documentation/devicetree/bindings/media/i2c/imx219.yaml b/Documentation/devicetree/bindings/media/i2c/imx219.yaml index 07d088cf66e0bde362b12d3494e5c91a1dd96bf3..5f395cf04b95ca47d5e685b8c43b8265db6910ae 100644 --- a/Documentation/devicetree/bindings/media/i2c/imx219.yaml +++ b/Documentation/devicetree/bindings/media/i2c/imx219.yaml @@ -52,7 +52,7 @@ properties: properties: endpoint: $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false + additionalProperties: false properties: data-lanes: @@ -65,10 +65,14 @@ properties: - const: 2 clock-noncontinuous: true + clock-lanes: true link-frequencies: true + remote-endpoint: true required: + - data-lanes - link-frequencies + - remote-endpoint required: - compatible diff --git a/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml b/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml index f8ace8cbccdbac482ffba733d5b28a3a38aaf822..ce45bd8409597fa6989f632d68cd4aa1a468d152 100644 --- a/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml +++ b/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml @@ -77,7 +77,7 @@ properties: properties: endpoint: $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false + additionalProperties: false properties: link-frequencies: true @@ -87,11 +87,13 @@ properties: - 1 # CSI-2 C-PHY - 3 # CCP2 - 4 # CSI-2 D-PHY + remote-endpoint: true required: - link-frequencies - data-lanes - bus-type + - remote-endpoint required: - compatible diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,og01a1b.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,og01a1b.yaml index ca57c01739d2b93100a37db56255ab717c1197ff..9b3738956c482d8826bf64f557c2e91630ea9799 100644 --- a/Documentation/devicetree/bindings/media/i2c/ovti,og01a1b.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ovti,og01a1b.yaml @@ -55,7 +55,7 @@ properties: properties: endpoint: $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false + additionalProperties: false properties: data-lanes: @@ -65,10 +65,12 @@ properties: enum: [1, 2] link-frequencies: true + remote-endpoint: true required: - data-lanes - link-frequencies + - remote-endpoint required: - compatible diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml index 67c1c291327b7febb6a039bf6f28c8dc1f32ed7f..b8db4be137085fe31ec2f076c7dc66b30bf0b66c 100644 --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml @@ -77,7 +77,7 @@ properties: properties: endpoint: $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false + additionalProperties: false properties: link-frequencies: true @@ -88,9 +88,11 @@ properties: the link speed defined by the 'link-frequencies' property. If present, the value shall be in the range of 0-4. default: 4 + remote-endpoint: true required: - link-frequencies + - remote-endpoint required: - endpoint diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml index d96199031b66c5c162a034824f195e277f2a1795..7499523a6e0fbd64b9b980333adaa14a0c40a33b 100644 --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml @@ -61,7 +61,7 @@ properties: properties: endpoint: $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false + additionalProperties: false properties: data-lanes: @@ -77,10 +77,12 @@ properties: - items: - const: 1 link-frequencies: true + remote-endpoint: true required: - data-lanes - link-frequencies + - remote-endpoint required: - compatible diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml index 622243cae03caa5d14aa312df40ef5907e190d2c..358c0422451f7faa8e0ebfc9226a5cfb087e3598 100644 --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml @@ -45,7 +45,7 @@ properties: properties: endpoint: $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false + additionalProperties: false properties: link-frequencies: true @@ -54,9 +54,12 @@ properties: minItems: 1 maxItems: 2 + remote-endpoint: true + required: - data-lanes - link-frequencies + - remote-endpoint required: - compatible diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml index ad07204057f979ade534d29c99c3aff7372bd332..eff212524bf3c7b1ec6aa7e826d4318d58ba53a5 100644 --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml @@ -60,7 +60,7 @@ properties: properties: endpoint: $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false + additionalProperties: false properties: data-lanes: @@ -69,6 +69,7 @@ properties: # Supports max data transfer of 900 Mbps per lane link-frequencies: true + remote-endpoint: true required: - compatible diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov7251.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov7251.yaml index 2e5187acbbb89728cbb8a402559d24766198a3da..cbbe3c9ce151eb33d2b0cc1a44e6ebf66d9b59fa 100644 --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov7251.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov7251.yaml @@ -53,7 +53,7 @@ properties: properties: endpoint: $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false + additionalProperties: false properties: clock-lanes: @@ -63,10 +63,12 @@ properties: maxItems: 1 link-frequencies: true + remote-endpoint: true required: - data-lanes - link-frequencies + - remote-endpoint required: - compatible diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml index 382d7de7a89bcea11be384a2a3800512994f9346..dd5c5715fdcfc00e6d851f375f41e4d077b92bc0 100644 --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml @@ -45,7 +45,7 @@ properties: properties: endpoint: $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false + additionalProperties: false properties: link-frequencies: true @@ -54,9 +54,12 @@ properties: minItems: 1 maxItems: 4 + remote-endpoint: true + required: - data-lanes - link-frequencies + - remote-endpoint required: - compatible diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml index 38325cf318f7bd2cd60a4c7bbb6a65b54b855e26..dde4e7426bf00920f1bd9ed1bf4d8594932dedaf 100644 --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml @@ -51,15 +51,17 @@ properties: properties: endpoint: $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false + additionalProperties: false properties: data-lanes: true link-frequencies: true + remote-endpoint: true required: - data-lanes - link-frequencies + - remote-endpoint required: - endpoint diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml index 0162eec8ca993a7614d29908f89fa9fe6d4b545d..9b78ff6bd5f114c7f63ac90e71fa677445ddf702 100644 --- a/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml @@ -58,7 +58,7 @@ properties: properties: endpoint: $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false + additionalProperties: false properties: data-lanes: @@ -73,10 +73,12 @@ properties: - const: 4 link-frequencies: true + remote-endpoint: true required: - data-lanes - link-frequencies + - remote-endpoint additionalProperties: false diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml index f0f9726a2add89492b8c56e17ed607841baa3a0d..4cf49472c24f1b800f6d2e41b8716e2ac32f959a 100644 --- a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml @@ -56,7 +56,7 @@ properties: properties: endpoint: $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false + additionalProperties: false properties: data-lanes: @@ -71,10 +71,12 @@ properties: - const: 2 link-frequencies: true + remote-endpoint: true required: - data-lanes - link-frequencies + - remote-endpoint required: - compatible diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx283.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx283.yaml index e4f49f1435a5c2e6e1507d250662ea6ecbf3c7dc..75b78a3e925ed2fd09f56c8349d234a32739f141 100644 --- a/Documentation/devicetree/bindings/media/i2c/sony,imx283.yaml +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx283.yaml @@ -48,7 +48,7 @@ properties: properties: endpoint: $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false + additionalProperties: false properties: data-lanes: @@ -60,10 +60,12 @@ properties: - const: 4 link-frequencies: true + remote-endpoint: true required: - data-lanes - link-frequencies + - remote-endpoint required: - endpoint diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx290.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx290.yaml index bf05ca48601abda53d60a3d03aa556e7b8fd825b..e6aec7a1ba2b22a11111d19a61384f1200041df5 100644 --- a/Documentation/devicetree/bindings/media/i2c/sony,imx290.yaml +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx290.yaml @@ -71,7 +71,7 @@ properties: properties: endpoint: $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false + additionalProperties: false properties: data-lanes: @@ -86,10 +86,12 @@ properties: - const: 4 link-frequencies: true + remote-endpoint: true required: - data-lanes - link-frequencies + - remote-endpoint additionalProperties: false diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml index 872b8288948b2bba743f2365a55165181df156ae..d30ef330e5af225728d1a6c40b26050cd33ba4be 100644 --- a/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml @@ -38,15 +38,17 @@ properties: properties: endpoint: $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false + additionalProperties: false properties: data-lanes: true link-frequencies: true + remote-endpoint: true required: - data-lanes - link-frequencies + - remote-endpoint required: - endpoint diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml index 38bd1c7304a59bb5fea90954c1e4e626a7c86f2f..36c3a0ba7822475770cd903cec3343d31bb66520 100644 --- a/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml @@ -48,15 +48,17 @@ properties: properties: endpoint: $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false + additionalProperties: false properties: data-lanes: true link-frequencies: true + remote-endpoint: true required: - data-lanes - link-frequencies + - remote-endpoint required: - endpoint diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml index ece1e17fe34553671e61c965eb1833c5eb08131b..0bbdf657a8c0643ffe512ae04c14dfc8e6b4fc94 100644 --- a/Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml @@ -50,15 +50,17 @@ properties: properties: endpoint: $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false + additionalProperties: false properties: data-lanes: true link-frequencies: true + remote-endpoint: true required: - data-lanes - link-frequencies + - remote-endpoint required: - endpoint diff --git a/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml b/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml index 1c476b635b690865cff0882578d72b1db2dc7c50..367d669ad864ed6b2a8762f953f58e206c8c8194 100644 --- a/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml +++ b/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml @@ -96,7 +96,7 @@ properties: properties: endpoint: $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false + additionalProperties: false properties: data-lanes: @@ -105,10 +105,12 @@ properties: clock-noncontinuous: true link-frequencies: true + remote-endpoint: true required: - data-lanes - link-frequencies + - remote-endpoint required: - port@0
Some of our sensor schemas use unevaluatedProperities: false for endpoint: properties: while other schemas use additionalProperties: false. The effect of using unevaluatedProperities: false in this instance is that any property in media/video-interfaces.yaml can be considered in a dts for an endpoint. Converting to additionalProperties: false and running DT checkers show that such a liberal policy is unnecessary. We should have a consistent way of defining these properties if for no other reason than aid other developers in the preferred way of writing these schemas for media/i2c in the future. Convert to additionalProperties: as a result remote-endpoint needs to be added to the property list for most sensors. In a few cases some additional properties clock data-lanes or clock-lanes need to be added too but, for-the-most-part remote-endpoint is the only missing property. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> --- .../devicetree/bindings/media/i2c/alliedvision,alvium-csi2.yaml | 5 ++++- Documentation/devicetree/bindings/media/i2c/galaxycore,gc05a2.yaml | 4 +++- Documentation/devicetree/bindings/media/i2c/galaxycore,gc08a3.yaml | 4 +++- Documentation/devicetree/bindings/media/i2c/galaxycore,gc2145.yaml | 6 +++++- Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml | 4 +++- Documentation/devicetree/bindings/media/i2c/imx219.yaml | 6 +++++- Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml | 4 +++- Documentation/devicetree/bindings/media/i2c/ovti,og01a1b.yaml | 4 +++- Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml | 4 +++- Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml | 4 +++- Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml | 5 ++++- Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml | 3 ++- Documentation/devicetree/bindings/media/i2c/ovti,ov7251.yaml | 4 +++- Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml | 5 ++++- Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml | 4 +++- Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml | 4 +++- Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml | 4 +++- Documentation/devicetree/bindings/media/i2c/sony,imx283.yaml | 4 +++- Documentation/devicetree/bindings/media/i2c/sony,imx290.yaml | 4 +++- Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml | 4 +++- Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml | 4 +++- Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml | 4 +++- Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml | 4 +++- 23 files changed, 75 insertions(+), 23 deletions(-)