On 19/03/2023 11:58, Krzysztof Kozlowski wrote:
+
+maintainers:
+ - Bryan O'Donoghue<bryan.odonoghue@xxxxxxxxxx>
+
+description: |
+ Qualcomm PMIC Virtual Type-C Port Manager Driver
+ A virtual device which manages Qualcomm PMIC provided Type-C port and
+ Power Delivery in one place.
OK, so it looks like bindings for driver, so a no-go. Unless there is
such device as "manager", this does not look like hardware description.
+
+properties:
+ compatible:
+ const: qcom,pmic-virt-tcpm
+
+ connector:
+ type: object
+ $ref: /schemas/connector/usb-connector.yaml#
+ unevaluatedProperties: false
+
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Contains a port which consumes data-role switching messages.
+
+ qcom,pmic-typec:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ A phandle to the typec port hardware driver.
+
+ qcom,pmic-pdphy:
+ $ref: /schemas/types.yaml#/definitions/phandle
Having typec and phy as phandles - not children - also suggests this is
some software construct, not hardware description.
So probably I didn't interpret Rob's comment correctly here.
For a pure software device - a virtual device - there should be no dts
representation at all - not even at the firmware{}, chosen{}, rpm{}
level, it wouldn't be possible/acceptable to have a tcpm {} with a
compat pointing to the two phandles I have here ?
---
bod
