linux-kernel - Re: [PATCH v8 3/3] arm64: dts: rockchip: add usb2-phy support for rk3399

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 21 Jul 2016 00:06:36 +0200
From:	Heiko Stübner <heiko@...ech.de>
To:	Doug Anderson <dianders@...omium.org>
Cc:	Frank Wang <frank.wang@...k-chips.com>,
	Guenter Roeck <linux@...ck-us.net>,
	Guenter Roeck <groeck@...omium.org>,
	Julius Werner <jwerner@...omium.org>,
	Kishon Vijay Abraham I <kishon@...com>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
	Ziyuan Xu <xzy.xu@...k-chips.com>,
	Kever Yang <kever.yang@...k-chips.com>,
	Tao Huang <huangtao@...k-chips.com>,
	吴良峰 <william.wu@...k-chips.com>,
	daniel.meng@...k-chips.com
Subject: Re: [PATCH v8 3/3] arm64: dts: rockchip: add usb2-phy support for rk3399

Am Mittwoch, 20. Juli 2016, 14:33:25 schrieb Doug Anderson:
> > +               #address-cells = <1>;
> > +               #size-cells = <1>;
> > +
> > +               u2phy0: usb2-phy@...0 {
> > +                       compatible = "rockchip,rk3399-usb2phy";
> > +                       reg = <0xe450 0x10>;
> > +                       clocks = <&cru SCLK_USB2PHY0_REF>;
> > +                       clock-names = "phyclk";
> > +                       #clock-cells = <0>;
> > +                       clock-output-names = "clk_usbphy0_480m";
> 
> Any reason why there isn't a 'status = "disabled";' here?

my guess would be, because we might need the provided clock anyway, even in 
the case where the actual phy is not used.

But that is better decided by the board/board-dts designer if the clock is 
really needed, so add the disabled here and enable in the board, as Doug 
suggested.


> > +                       u2phy0_host: host-port {
> > +                               #phy-cells = <0>;
> > +                               interrupts = <GIC_SPI 27
> > IRQ_TYPE_LEVEL_HIGH>; +                               interrupt-names =
> > "linestate";
> > +                               status = "disabled";
> > +                       };
> > +               };
> > +
> > +               u2phy1: usb2-phy@...0 {
> > +                       compatible = "rockchip,rk3399-usb2phy";
> > +                       reg = <0xe460 0x10>;
> > +                       clocks = <&cru SCLK_USB2PHY1_REF>;
> > +                       clock-names = "phyclk";
> > +                       #clock-cells = <0>;
> > +                       clock-output-names = "clk_usbphy1_480m";
> > +
> > +                       u2phy1_host: host-port {
> > +                               #phy-cells = <0>;
> > +                               interrupts = <GIC_SPI 31
> > IRQ_TYPE_LEVEL_HIGH>; +                               interrupt-names =
> > "linestate";
> > +                               status = "disabled";
> > +                       };
> > +               };
> > 
> >         };
> >         
> >         watchdog@...40000 {
> > 
> > @@ -1009,5 +1047,12 @@
> > 
> >                                         <1 14 RK_FUNC_1 &pcfg_pull_none>;
> >                         
> >                         };
> >                 
> >                 };
> > 
> > +
> > +               usb2 {
> > +                       host_vbus_drv: host-vbus-drv {
> > +                               rockchip,pins =
> > +                                       <4 25 RK_FUNC_GPIO
> > &pcfg_pull_none>; +                       };
> > +               };
> 
> Are you certain this belongs in rk3399.dtsi?  It seems like it should
> be in the EVB file.

yep, while most boards follow a reference design, this is still highly board-
specific.