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  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:	Fri, 21 Mar 2014 15:09:26 +0100
From:	Maxime Coquelin <maxime.coquelin@...com>
To:	Mike Turquette <mturquette@...aro.org>,
	Sylwester Nawrocki <s.nawrocki@...sung.com>,
	<linux-arm-kernel@...ts.infradead.org>,
	<devicetree@...r.kernel.org>
Cc:	<mark.rutland@....com>, <gregkh@...uxfoundation.org>,
	<t.figa@...sung.com>, <sw0312.kim@...sung.com>,
	<linux-kernel@...r.kernel.org>, <kyungmin.park@...sung.com>,
	<robh+dt@...nel.org>, <galak@...eaurora.org>,
	<grant.likely@...aro.org>, <linux@....linux.org.uk>,
	<m.szyprowski@...sung.com>, <t-kristo@...com>
Subject: Re: [RFC PATCH v2 0/2] clk: Support for DT assigned clock parents
 and rates

Hi Mike,

On 03/21/2014 02:45 AM, Mike Turquette wrote:
> Quoting Sylwester Nawrocki (2014-03-20 05:42:33)
>> Hi Maxime,
>>
>> On 06/03/14 14:45, Maxime Coquelin wrote:
>>> Hi Sylwester,
>>>
>>>        I like the principle of your implementation, but I have two questions:
>>>        1 - How can we manage PM with this solution, as the parent/rate will be
>>> set only once at probe time?
>>>        2 - How to set the parent of a parent clock (which can be shared with
>>> other devices)? Same question about the parent rates.
>>
>> Thanks for your feedback and apologies for late reply.
>>
>> IIUC your first concern is about a situation when clocks need to be
>> reconfigured upon each resume from system sleep or runtime PM resume ?
>> As I mentioned in v1 of the RFC I was considering having individual
>> drivers calling explicitly the clocks set up routine. Presumably this
>> would allow to resolve the power management related issue.
>> One example I'm aware the approach as in this RFC wouldn't work is
>> when a device in a SoC belongs to a power domain, which needs to be
>> first switched on before we can start setting up and the clocks'
>> configuration get lost after the power domain switch off.
>
> I like Sylwester's approach of handling this one-time setup in the
> driver core.
>
> Any kind of fine grained power management should not be hidden by DT,
> and by definition that logic belongs in the device driver. It can still
> be nicely abstracted away by runtime pm[1].
>
> Regards,
> Mike
>
> [1] Message-ID: <20140320114238.GQ7528@...00.arm.linux.org.uk>
How can I access this reference?

Thanks,
Maxime

>
>>
>> OTOH I suspect devices for which one-time clocks setup is sufficient
>> will be quite common. And for these there would need to be a single
>> call to the setup routine in probe() I guess, since it wouldn't be
>> possible to figure out just from the DT data when the actual call
>> should be made.
>>
>> For a global clocks configuration, I thought about specifying that
>> in the clocks controller node, and then to have the setup routine
>> called e.g. from of_clk_init(). I think that could work well enough,
>> together with the patch [1], adding clock dependencies handling.
>> But then the clock frequency set up function would need to be
>> modified to respect the clock parent relationships, similarly as
>> in patch series [2]. A just noticed [2] recently, after posting
>> this RFC (adding Tero at Cc).
>>
>> --
>> Regards,
>> Sylwester
>>
>> [1] http://www.spinics.net/lists/arm-kernel/msg310507.html
>> [2] http://www.spinics.net/lists/linux-omap/msg103069.html
--
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