Hi Rob, [snip] > > > + data-lanes: > > > + $ref: /schemas/types.yaml#/definitions/uint32-array > > > + minItems: 1 > > > + maxItems: 4 > > > + items: > > > + # Assume up to 4 data and 1 clock lane > > > + maximum: 4 > > > + description: > > > + An array of physical data lane indexes. Position of an entry determines > > > + the logical lane number, while the value of an entry indicates physical > > > + lane, e.g. for 2-lane MIPI CSI-2 bus we could have "data-lanes = <1 2>;", > > > + assuming the clock lane is on hardware lane 0. If the hardware does not > > > + support lane reordering, monotonically incremented values shall be used > > > + from 0 or 1 onwards, depending on whether or not there is also a clock > > > + lane. This property is valid for serial busses only (e.g. MIPI CSI-2). > > > > This won't flag [1, 3] as wrong, right ? > > Right. In theory you could have hardware that does this, right? You > could pick and choose which lanes to use. You could if your platform supports lane re-ordering (iirc there's a single device that supports that in mainline) My (badly worded) question is: do we expect users to define the valid values as here below reported ? Or are we happy with 'maximum: 2' ? If we ask users to provide the valid arrays, we get an ugly DTS and, more problematically, this has be noticed and suggested during reviews likely for every submission, this is all but intuitive and most platforms don't support lane re-ordering, most if not all will have to limit the property supported values. We get DTS validation in exchange. If we're fine with just having the maximum value specified, we lose dts validation but it really gets less clunky for DTS. Run-time handling for drivers won't change much, as devices that don't support lane re-ordering mostly care about the number of active lanes. It's more a policy question than a technical one... > > > I guess the only alternative is the ugly: > > > > anyOf: > > - items: > > - const: 1 > > - items: > > - const: 1 > > - const: 2 > > - items: > > - const: 1 > > - const: 2 > > - const: 3 > > - items: > > - const: 1 > > - const: 2 > > - const: 3 > > - const: 4 > > > > As we express "monotonically incremented" I think it's fine, even if > > validation won't catch it. > > > > Also, sakari just pointed me to the just merged > > Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml: > > > > data-lanes: > > minItems: 1 > > maxItems: 8 > > > > sakari, where does 8 come from ? Afaik D-PHY supports 4 differential > > data lanes, and C-PHY 3 'trios' > > Okay, let me know what values to put here. > I'll defer this to Sakari :) Thanks j
