linux-kernel - Re: [RFC] clk: Make clk API return per-user struct clk instances

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:	Tue, 30 Sep 2014 10:41:19 +0300
From:	Tero Kristo <t-kristo@...com>
To:	Mike Turquette <mturquette@...aro.org>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Tomeu Vizoso <tomeu.vizoso@...labora.com>,
	Russell King <linux@....linux.org.uk>
CC:	<linux-kernel@...r.kernel.org>,
	Javier Martinez Canillas <javier.martinez@...labora.co.uk>,
	<tony@...mide.com>
Subject: Re: [RFC] clk: Make clk API return per-user struct clk instances

On 09/30/2014 09:54 AM, Mike Turquette wrote:
> Quoting Stephen Boyd (2014-09-29 18:40:23)
>> On 09/29/14 11:17, Tomeu Vizoso wrote:
>>> Also moves clock state to struct clk_core, but takes care to change as little
>>> API as possible.
>>>
>>> struct clk_hw still has a pointer to a struct clk, which is the
>>> implementation's per-user clk instance, for backwards compatibility.
>>>
>>> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@...labora.com>
>>>
>>> ---
>>>
>>> Hello,
>>>
>>> I'm sending this alternate implementation of the switch to per-user clocks,
>>> with the added goal of not requiring any substantial changes to existing users
>>> of the API.
>>>
>>> This is pretty much RFC-quality right now, having only tested that it builds on
>>> tegra_defconfig.
>>>
>>> My main question right now is what do we want to do with those drivers that
>>> statically declare clocks. State is now in struct clk_core, so updating the
>>> drivers accordingly will amount to a substantial amount of lines changed, which
>>> we are now trying to avoid.
>>
>> Who's actually using the static clocks? Isn't it just omap2? It looks
>> like all of those are behind the DEFINE_CLK define so changing it in
>> clk-private.h should "just work". I'm lost as to why static clocks are
>> being used there though. If it was a problem with allocating memory too
>> early it doesn't seem to be the case given that sometimes the .parents
>> field isn't set for a mux and __clk_init() will go and allocate an array
>> of pointers. Maybe I missed something though.
>
> Yeah, the old omap2+ static clocks were due to very very early init of
> things which required clocks
>
> If memory serves, that isn't a problem any more. I've talked to Tony and
> Tero about my desire to remove clk-private.h and the need to get rid of
> its use in the omap clock code.
>
> Tero, what is the status of DT conversion for OMAP2/OMAP3? Can we get
> get away with only defining clock data in DT for those platforms? Can we
> finally kill off clk-private.h?

Clock data has been converted for all SoCs. The problem is currently 
that we are missing some OMAP3 based DT board definitions and still 
require legacy boot => thus requiring legacy clock data also => omap3 
legacy clock data can't be removed yet.

Tony, whats the latest status with these missing omap3 boards? How many 
board->dt conversions are still needed? Is there anything someone can do 
on this front?

-Tero

>
> Regards,
> Mike
>
>>
>>>
>>> Thanks,
>>>
>>> Tomeu
>>> ---
>>>   drivers/clk/clk-composite.c  |  12 +-
>>>   drivers/clk/clk.c            | 573 +++++++++++++++++++++++++++----------------
>>>   drivers/clk/clk.h            |   5 +
>>>   drivers/clk/clkdev.c         |  20 +-
>>>   drivers/clk/tegra/clk.c      |   2 +-
>>>   include/linux/clk-private.h  |  20 +-
>>>   include/linux/clk-provider.h |  22 +-
>>>   include/linux/clkdev.h       |   2 +-
>>>   8 files changed, 410 insertions(+), 246 deletions(-)
>>>
>>> diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
>>> index b9355da..cb4a09d 100644
>>> --- a/drivers/clk/clk-composite.c
>>> +++ b/drivers/clk/clk-composite.c
>>> @@ -57,14 +57,14 @@ static unsigned long clk_composite_recalc_rate(struct clk_hw *hw,
>>>
>>>   static long clk_composite_determine_rate(struct clk_hw *hw, unsigned long rate,
>>>                                        unsigned long *best_parent_rate,
>>> -                                     struct clk **best_parent_p)
>>> +                                     struct clk_core **best_parent_p)
>>
>>
>> We should avoid exposing clk_core to anything besides clk.c or users of
>> clk-private.h (the latter which should go away once we remove all static
>> clocks).
>>
>> --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> hosted by The Linux Foundation
>>

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