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>] [day] [month] [year] [list]
Message-ID: <20140819104746.4a8f323c@x230>
Date:	Tue, 19 Aug 2014 10:47:46 +0200
From:	"gwenhael.goavec" <gwen@...bucayre.com>
To:	Peter Chen <peter.chen@...escale.com>
Cc:	Shawn Guo <Shawn.Guo@...escale.com>,
	Philippe Reynes <tremyfr@...il.com>,
	"Linux-kernel@...r.kernel.org" <Linux-kernel@...r.kernel.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC] usb issue on imx27: 3 clocks are needed

On Tue, 19 Aug 2014 08:18:17 +0800
Peter Chen <peter.chen@...escale.com> wrote:

> On Mon, Aug 18, 2014 at 01:49:03PM +0200, gwenhael.goavec wrote:
> > On Mon, 18 Aug 2014 10:35:53 +0000
> > Peter Chen <Peter.Chen@...escale.com> wrote:
> > 
> > >  
> > > > On Mon, Aug 18, 2014 at 05:00:59PM +0800, Peter Chen wrote:
> > > > > On Sat, Aug 16, 2014 at 05:38:30PM +0200, Philippe Reynes wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > i.MX27's usb needs three clocks (usb_ipg_gate, usb_ahb_gate and
> > > > > > usb_div) but the current chipidea driver implementation, and
> > > > > > devicetree, provides only ipg and ahb. Consequently, if the
> > > > > > bootloader don't enable the last one, the kernel will crash.
> > > > > >
> > > > > > Our approach/idea is to add a second, optionnal, clock in
> > > > > > ci_hdrc_imx.c with 'per' name in devicetree  and to add  clock name
> > > > 'main_clk' for mandatory clock.
> > > > > > This approach it correct? Or an other approach seems better?
> > > > > > Thank you very much for your point of view.
> > > > > >
> > > > >
> > > > > It is ok for me to have ipg, ahb and per clocks at driver, but how can
> > > > > you maintain DT consistent?
> > > > 
> > > > Adding new clock as optional one will just maintain the DT compatibility.
> > > > 
> > > 
> > > How to handle node_usb_soc1's clock which is without clk name to consistent with three
> > > clocks for node_usb_soc2 at driver? Except for adding some platform judge code at
> > > driver, do you have other solutions?
> > > 
> > > node_usb_soc1: {
> > > 	clocks = <&clks IMX6_CLK_USBOH3>;
> > > };
> > > 
> > > node_usb_soc2: {
> > > 	clocks = <&clks IMX27_CLK_USBIPG>, <&clks IMX27_CLK_USBOH3>, <&clks IMX27_CLK_USBPER>;
> > > 	clock-names = "ipg", "ahb", "per";
> > > };
> > > 
> > > Peter
> > > --
> > 
> > Our idea is something like this :
> > node_usb_soc: {
> > 	clocks = <&clks IMX27_CLK_USBxxx>;
> > 	clock-names = "main_clk";
> > };
> > for all CPUs
> > 
> > and 
> > node_usb_imx27: {
> > 	clocks = <&clks IMX27_CLK_USB_IPG_GATE>,
> > 		<&clks IMX27_CLK_USB_DIV>;
> > 	clock-names = "main_clk", "per";
> > };
> > 
> > For imx27 and CPUs with the need of more than one clock.
> > 
> 
> Just like Shawn said, it breaks DT compatibility, how the old dtb works
> with newer version kernel after you change.
>
New dtsi must be updated according to the clock name and to avoid breaking old
dtb, i think the best way is to to do something like :

data->clk = devm_clk_get(&pdev->dev, "main_clk");
if (IS_ERR(data->clk)) {
	/* DT compatibility */
	data->clk = devm_clk_get(&pdev->dev, NULL);
	if (IS_ERR(data->clk)) {
		dev_err(&pdev->dev,
			"Failed to get main clock, err=%ld\n",
			PTR_ERR(data->clk));
		return PTR_ERR(data->clk);
	}   
}
Gwenhael

>
> > The last clock (ie ahb) is handled by usbmisc.c and if "per" clock is not
> > present in the dtsi chipidea will not fails, just setting data->per_clk = NULL
> > for prepare/unprepare.
> > 
> > Gwenhael
> 
> -- 
> Best Regards,
> Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ