On 19/03/2023 15:10, Krzysztof Kozlowski wrote:
On 19/03/2023 15:59, Bryan O'Donoghue wrote:
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.
He proposed to merge it with other node:
"probably merged with
one of the nodes these phandles point to."
"Why can't most of this binding be part of"
I don't see how you implemented his comments. Actually, nothing improved
here in this regard - you still have these phandles.
So this comment from Rob is what I was aiming for
"Your other option is instantiate your own device from the virtual
driver's initcall based on presence of the 2 nodes above. "
rather than two mush the pdphy and typec into one device, which they are
not.
I guess what I'm trying to understand is how you guys would suggest that
is actually done.
Could I trouble you for an example ?
---
bod
