linux-kernel - Re: [RFC 6/8] of: add clock providers

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:	Wed, 9 Nov 2011 12:23:25 +0100
From:	"Cousson, Benoit" <b-cousson@...com>
To:	Sascha Hauer <s.hauer@...gutronix.de>
CC:	Grant Likely <grant.likely@...retlab.ca>,
	<devicetree-discuss@...ts.ozlabs.org>,
	Rob Herring <rob.herring@...xeda.com>,
	Sascha Hauer <kernel@...gutronix.de>,
	<linux-arm-kernel@...ts.infradead.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [RFC 6/8] of: add clock providers

On 11/9/2011 10:13 AM, Sascha Hauer wrote:
> On Tue, Nov 08, 2011 at 06:19:41PM -0700, Grant Likely wrote:

[...]

>> +Sources of clock signal can be represented by any node in the device
>> +tree.  Those nodes are designated as clock providers.  Clock consumer
>> +nodes use a phandle and clock specifier pair to connect clock provider
>> +outputs to clock inputs.  Similar to the gpio specifiers, a clock
>> +specifier is an array of one more more cells identifying the clock
>> +output on a device.  The length of a clock specifier is defined by the
>> +value of a #clock-cells property in the clock provider node.
>> +
>> +[1] http://patchwork.ozlabs.org/patch/31551/
>> +
>> +==Clock providers==
>> +
>> +Required properties:
>> +#clock-cells:	   Number of cells in a clock specifier; typically will be
>> +		   set to 1
>> +
>> +Optional properties:
>> +clock-output-name: Recommended to be a list of strings of clock output signal
>> +		   names indexed by the first cell in the clock specifier.
>> +		   However, the meaning of clock-output-names is domain
>> +		   specific to the clock provider, and is only provided to
>> +		   encourage using the same meaning for the majority of clock
>> +		   providers.  This format may not work for clock providers
>> +		   using a complex clock specifier format.  In those cases it
>> +		   is recommended to omit this property and create a binding
>> +		   specific names property.
>
> If the clock-output-name property is omitted, does this mean a clock
> provider only has a single output or does it mean that it's not known
> how many clock outputs a provider actually has?

Allowing several outputs for a single clock node might lead to a lot of 
confusion. What will be the meaning of a clock rate if you have several 
outputs at different frequency?
I think it will be better to define a clock node as a single source of 
clock. If several outputs are needed, then we should define several 
clock nodes.
If we let a clock node be any kind of big clock blob, we will never be 
able to define some generic reusable clock node API. Everybody will 
define its own custom clock blobs.

Regards,
Benoit


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