linux-kernel - Re: [PATCH v5 1/6] clk: add of_clk_get_parent

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]

Message-ID: <54EEB97B.6080006@broadcom.com>
Date:	Wed, 25 Feb 2015 22:13:15 -0800
From:	Ray Jui <rjui@...adcom.com>
To:	Sascha Hauer <s.hauer@...gutronix.de>
CC:	Mike Turquette <mturquette@...aro.org>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Matt Porter <mporter@...aro.org>,
	Alex Elder <elder@...aro.org>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Russell King <linux@....linux.org.uk>,
	Arnd Bergmann <arnd@...db.de>,
	<linux-arm-kernel@...ts.infradead.org>,
	<devicetree@...r.kernel.org>,
	Scott Branden <sbranden@...adcom.com>,
	"Dmitry Torokhov" <dtor@...gle.com>,
	Anatol Pomazau <anatol@...gle.com>,
	<linux-kernel@...r.kernel.org>,
	<bcm-kernel-feedback-list@...adcom.com>
Subject: Re: [PATCH v5 1/6] clk: add of_clk_get_parent_rate function

Hi Sascha,

On 2/25/2015 9:54 PM, Sascha Hauer wrote:
> Hi Ray,
> 
> On Wed, Feb 04, 2015 at 04:55:00PM -0800, Ray Jui wrote:
>> Sometimes a clock needs to know the rate of its parent before itself is
>> registered to the framework. An example is that a PLL may need to
>> initialize itself to a specific VCO frequency, before registering to the
>> framework. The parent rate needs to be known, for PLL multipliers and
>> divisors to be configured properly.
>>
>> Introduce helper function of_clk_get_parent_rate, which can be used to
>> obtain the parent rate of a clock, given a device node and index.
> 
> I can't see how this patch helps you. First it's not guaranteed that
> the parent is already registered, what do you do in this case?

In the case when clock parent is not found, as you can see from the
code, it simply returns zero, just like other clk get rate APIs.

I thought the order of clock registration is based on order of the clock
nodes in device tree. It makes sense to me to declare the parent clock
before a child clock, so it's guaranteed that the parent is registered
before the child.

> Then the clock framework doesn't require that you initialize the PLL
> before registering. That can be done in the clk ops later.

Sure it's not mandatory. But what's wrong with me choosing to initialize
the PLL clock to a known frequency before registering it to the framework?

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