linux-kernel - Re: [PATCH] arm64: dts: mt8173: add clock

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, 2 Jul 2015 10:05:22 +0800
From:	James Liao <jamesjj.liao@...iatek.com>
To:	Sascha Hauer <s.hauer@...gutronix.de>,
	Heiko Stübner <heiko@...ech.de>
CC:	<linux-mediatek@...ts.infradead.org>,
	Eddie Huang <eddie.huang@...iatek.com>,
	Matthias Brugger <matthias.bgg@...il.com>,
	<devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>, <djkurtz@...omium.org>,
	Mike Turquette <mturquette@...libre.com>,
	Stephen Boyd <sboyd@...eaurora.org>, <ted.lin@...iatek.com>
Subject: Re: [PATCH] arm64: dts: mt8173: add clock_null

Hi Sascha,

On Wed, 2015-07-01 at 08:49 +0200, Sascha Hauer wrote:
> On Tue, Jun 30, 2015 at 05:07:09PM +0800, James Liao wrote:
> > There are 4 clocks which are derived from clk_null directly in current
> > topckgen implementation:
> > 
> > 	clkph_mck_o, dpi_ck, usb_syspll_125m, hdmitx_dig_cts
> > 
> > Our designer mentioned 2 things about external clocks:
> > 
> > 1. These 4 clocks come from analog macro, not from PLL, nor from
> > external clocks directly.
> 
> Ok, this means there actually are clocks. We can't control these clock and
> they have some known or unknown rate. This makes them fixed clocks. Just
> specify them in the device tree and you are done. Give them reasonable
> names and the rate if you know it, 0 otherwise.
> 
> The problem is not that you use fixed clocks for non software
> controllable clocks of unknwown rates, but that you try to use a single
> clock for all of them and name it 'dummy' or 'null'. Name it
> 
> dpi_ck {
> 	compatible = "fixed-clock";
> 	rate = <0>; /* unknown, generated by some Analog block */
> };
> 
> Technically it's the same, but it sounds much more professional and like
> you know what you are doing ;)

These clocks are SoC internal clocks. Is it suitable to specify them in
the device tree?

According to your and Heiko's suggestion, it looks the best way should
be specifying these clocks in the driver code without a dummy parent.
i.e.:

Original code:

FACTOR(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk_null", 1, 1),
FACTOR(CLK_TOP_DPI, "dpi_ck", "clk_null", 1, 1),
FACTOR(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk_null", 1, 1),
FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "clk_null", 1, 1),

New code:

FIXED(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", UNKNOWN_RATE),
FIXED(CLK_TOP_DPI, "dpi_ck", UNKNOWN_RATE),
FIXED(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", UNKNOWN_RATE),
FIXED(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", UNKNOWN_RATE),

Then we don't need to specify a dummy clock such as clk_null in device
tree.


Best regards,

James

--
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/