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
