On 15/10/2023 14:39, Laurent Pinchart wrote: >>> + properties: >>> + data-lanes: >>> + description: >>> + This property is for lane reordering between the THP7312 and the >>> + SoC. The sensor supports either two-lane, or four-lane operation. >>> + If this property is omitted four-lane operation is assumed. For >>> + two-lane operation the property must be set to <1 2>. >>> + minItems: 2 >>> + maxItems: 4 >>> + items: >>> + maximum: 4 >>> + >>> + sensors: >>> + type: object >>> + description: List of connected sensors >> >> I don't understand why do you list sensors here. From the binding >> description I understood these are external sensors, which usually sit >> on I2C bus. > > Good question :-) > > The sensors connected to the THP7312 input are controlled over I2C by > the THP7312 itself. The host operating system doesn't have access to > that I2C bus. The sensors are listed here because their power supplies > need to be controlled by the host operating system. OK > >>> + >>> + properties: >>> + "#address-cells": >>> + const: 1 >>> + >>> + "#size-cells": >>> + const: 0 >>> + >>> + patternProperties: >>> + "^sensor@[01]": >>> + type: object >>> + description: >>> + Sensors connected to the first and second input, with one node per >>> + sensor. >>> + >>> + properties: >>> + thine,model: >>> + $ref: /schemas/types.yaml#/definitions/string >>> + description: >>> + Model of the connected sensors. Must be a valid compatible string. >> >> Then why this isn't compatible? > > We picked a vendor-specific property to avoid implying that the sensor > nodes will result in devices being created by the host operating system. > I don't mind using "compatible" instead, but as far as I understand, a > compatible string implies that corresponding device DT bindings should > exist, and that won't be the case here necessarily. OK, looks sensible to me. Best regards, Krzysztof
