[PATCH v5 1/6] dt-bindings: add bindings for USB physical connector
Robin Murphy
robin.murphy at arm.com
Thu Mar 15 04:46:16 PDT 2018
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.
More information about the linux-arm-kernel
mailing list