On 12/03/18 10:41, Roger Quadros wrote:
[...]
@@ -0,0 +1,75 @@
+USB Connector
+=============
+
+USB connector node represents physical USB connector. It should be
+a child of USB interface controller.
+
+Required properties:
+- compatible: describes type of the connector, must be one of:
+ "usb-a-connector",
+ "usb-b-connector",
+ "usb-c-connector".
compatible should be just "usb-connector"
Type should be a property
type: type of usb connector "A", "B", "AB", "C"
AB is for dual-role connectors.
I have proposed such property (and size also) in my first RFC [1]. Rod
did not like it :)
[1]: https://marc.info/?l=devicetree&m=150660411515233&w=2
This is what Rob says here https://patchwork.kernel.org/patch/9976043/
"We did "type" for hdmi-connector, but I think I'd really prefer
compatible be used to distinguish as least where it may matter to s/w.
In the HDMI case, they all are pretty much the same, just different
physical size."
So the question is. Does it matter to this particular software implementation
if it is type A,B,C connector?
If yes, how?
Type A will never have any alternate function. It is always dedicated to USB.
In USB spec terms, at least. In reality there are things like the cool
trick Rockchip SoCs do whereby they can expose the debug UART Rx/Tx
through the OTG port's D+/D- pins, and that is on a type A connector in
many products. I'm guessing that's probably beyond the scope of this
binding, though.
Also does the size "full", "micro", "mini" matter to software?
If it means the user can look in sysfs to easily correlate logical ports
with physical connectors that's certainly handy (e.g. on something like
Odroid-XU where the two USB3 ports are brought out to an A and a
micro-AB connector respectively).
Robin.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
