[PATCH 1/2] Documentation: bindings: add DT documentation for Rockchip USB2PHY

[Frank Wang]

Hi Heiko,

On 05/31/2016 05:02 PM, Heiko Stübner wrote:
> Hi Frank,
>
> Am Dienstag, 31. Mai 2016, 14:40:10 schrieb Frank Wang:
>> Signed-off-by: Frank Wang <frank.wang at rock-chips.com>
>> ---
>>   .../bindings/phy/phy-rockchip-inno-usb2.txt        |   48
>> ++++++++++++++++++++ 1 file changed, 48 insertions(+)
>>   create mode 100644
>> Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
>> b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt new file
>> mode 100644
>> index 0000000..4e537b2
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
>> @@ -0,0 +1,48 @@
>> +ROCKCHIP USB2.0 PHY WITH INNO IP BLOCK
>> +
>> +Required properties (phy (parent) node):
>> + - compatible: should contain:
>> +	* "rockchip,rk3366-usb2phy"
>> + - #clock-cells: should be 0.
>> + - clock-names: specify the 480m output clk name.
>> +
>> +Optional properties:
>> + - vbus_host-gpio: pull gpio high/low to control the host vbus power.
>
> sorry for not catching that in our earlier talks, but I believe this should be
> a regulator instead. See for example vcc5_host1, vcc5v_otg in rk3288-veyron-
> chromebook.dtsi .
>

That is OK, I will correct it in the next version.

>
>> +Required nodes: a sub-node is required for each port the phy provides.
>> +		The sub-node name is used to identify host or otg port.
>> +
>> +Required properties (port (child) node):
>> + - #phy-cells: must be 0. See ./phy-bindings.txt for details.
>> + - interrupts: irq number for host/otg port.
>
> make that something like:
> Specify an interrupt for each entry in interrupt-names.
>
>> + - interrupt-names: interrupt name, in line with irq number.
>
> make that something like:
> Shall be "linestate" for the linestate interrupt.

Yeah, Got it.

> ---
>
> You might want to add the bvalid and id interrupts for the otg phys as well
> already - would make handling legacy devicetree files easier. [= if they get
> specified later, the driver would always need to also handle devicetrees where
> they aren't specified].
>

Hmmm! you mean that I can specify these properties into documentation, 
even if the driver have not handled (implemented) them in current?

BR.
Frank