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] [day] [month] [year] [list]
Date:	Fri, 13 Jun 2014 17:06:37 +0200
From:	Sylwester Nawrocki <s.nawrocki@...sung.com>
To:	Tero Kristo <t-kristo@...com>
Cc:	Mike Turquette <mturquette@...aro.org>,
	Rob Herring <robherring2@...il.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Rob Herring <robh+dt@...nel.org>,
	Grant Likely <grant.likely@...aro.org>,
	Mark Rutland <mark.rutland@....com>,
	Kumar Gala <galak@...eaurora.org>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Ben Dooks <ben.dooks@...ethink.co.uk>,
	Peter De Schrijver <pdeschrijver@...dia.com>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	sw0312.kim@...sung.com,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Tomasz Figa <t.figa@...sung.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC v5 2/2] clk: Add handling of clk parent and rate
 assigned from DT

On 23/05/14 08:37, Tero Kristo wrote:
> On 05/23/2014 04:34 AM, Mike Turquette wrote:
[...]
>> It looks like this idea was dropped for v6. Can we revisit it? Take a
>> look at Tero's example implementation for OMAP using this binding:
>>
>> http://www.spinics.net/lists/linux-omap/msg104705.html
>>
>> There is a bogus "default-clocks" node made solely for storing this info
>> within the OMAP PRCM clock provider node. This is basically faking a
>> clock consumer. I think with the proposed solution above Tero could have
>> avoided that node entirely and done the following:
>>
>> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
>> index 649b5cd..e3ff1a7 100644
>> --- a/arch/arm/boot/dts/omap4.dtsi
>> +++ b/arch/arm/boot/dts/omap4.dtsi
>> @@ -145,6 +145,11 @@
>>   			cm2_clocks: clocks {
>>   				#address-cells = <1>;
>>   				#size-cells = <0>;
>> +
>> +				assigned-clocks = <&abe_dpll_refclk_mux_ck>,
>> +					<&dpll_usb_ck>, <&dpll_abe_ck>;
>> +				assigned-clock-parents = <&sys_32k_ck>;
>> +				assigned-clock-rates = <0>, <960000000>, <98304000>;
>>   			};
>>
>>   			cm2_clockdomains: clockdomains {
>>
>>
>> Tero, what do you think?
> 
> Yeah, if we can avoid having a dummy node someplace, it is always 
> better. Only issue might be the initialization order, this was the 
> reason I created the dummy node if I recall right. But I guess we can 
> just scan the clock provider nodes second time at a later phase of boot 
> (or just store the default info for later use.)

One issue I'm a bit concerned about with an initcall-like approach is
it may not work well for clock providers in kernel modules which can be
loaded at any time.  So doing the configuration upon the clock provider
registration might have worked better.  Then we could disallow (defer)
a clock provider registration if any of its dependencies (as specified
through assigned-clock* properties) are not satisfied.  Do you think
that could work ?

--
Thanks,
Sylwester
--
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