linux-kernel - Re: [PATCH v4 3/6] clk: introduce the common clock framework

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 Jan 2012 20:51:51 -0800
From:	Saravana Kannan <skannan@...eaurora.org>
To:	"Turquette, Mike" <mturquette@...com>
CC:	Russell King - ARM Linux <linux@....linux.org.uk>, andrew@...n.ch,
	linaro-dev@...ts.linaro.org, eric.miao@...aro.org,
	grant.likely@...retlab.ca, Colin Cross <ccross@...gle.com>,
	jeremy.kerr@...onical.com, sboyd@...cinc.com,
	magnus.damm@...il.com, dsaxena@...aro.org,
	linux-arm-kernel@...ts.infradead.org, arnd.bergmann@...aro.org,
	patches@...aro.org, Thomas Gleixner <tglx@...utronix.de>,
	linux-omap@...r.kernel.org, richard.zhao@...aro.org,
	shawn.guo@...escale.com, paul@...an.com,
	linus.walleij@...ricsson.com, broonie@...nsource.wolfsonmicro.com,
	linux-kernel@...r.kernel.org, amit.kucheria@...aro.org,
	skannan@...cinc.com
Subject: Re: [PATCH v4 3/6] clk: introduce the common clock framework

On 01/13/2012 08:39 PM, Turquette, Mike wrote:
> On Fri, Jan 13, 2012 at 8:18 PM, Saravana Kannan<skannan@...eaurora.org>  wrote:
>> On 12/17/2011 03:04 AM, Russell King - ARM Linux wrote:
>>>
>>> On Fri, Dec 16, 2011 at 04:45:48PM -0800, Turquette, Mike wrote:
>>>>
>>>> On Wed, Dec 14, 2011 at 5:18 AM, Thomas Gleixner<tglx@...utronix.de>
>>>>   wrote:
>>>>>
>>>>> On Tue, 13 Dec 2011, Mike Turquette wrote:
>>>>>>
>>>>>> +void __clk_unprepare(struct clk *clk)
>>>>>> +{
>>>>>> +     if (!clk)
>>>>>> +             return;
>>>>>> +
>>>>>> +     if (WARN_ON(clk->prepare_count == 0))
>>>>>> +             return;
>>>>>> +
>>>>>> +     if (--clk->prepare_count>    0)
>>>>>> +             return;
>>>>>> +
>>>>>> +     WARN_ON(clk->enable_count>    0);
>>>>>
>>>>>
>>>>> So this leaves the clock enable count set. I'm a bit wary about
>>>>> that. Shouldn't it either return (including bumping the prepare_count
>>>>> again) or call clk_disable() ?
>>>
>>>
>>> No it should not.
>>>
>>>> I've hit this in my port of OMAP.  It comes from this simple situation:
>>>>
>>>> driver 1 (adapted for clk_prepare/clk_unprepare):
>>>> clk_prepare(clk);
>>>> clk_enable(clk);
>>>>
>>>> ...
>>>>
>>>> driver2 (not adapted for clk_prepare/clk_unprepare):
>>>> clk_enable(clk);
>>>
>>>
>>> So this is basically buggy.  Look, it's quite simple.  Convert _all_
>>> your drivers to clk_prepare/clk_unprepare _before_ you start switching
>>> your platform to use these new functions.  You can do that _today_
>>> without exception.
>>>
>>> We must refuse to merge _any_ user which does this the old way - and
>>> we should have been doing this since my commit was merged into mainline
>>> to allow drivers to be converted.
>>>
>>> And stop trying to think of ways around this inside clk_prepare/
>>> clk_unprepare/clk_enable/clk_disable.  You can't do it.  Just fix _all_
>>> the drivers.  Now.  Before you start implementing
>>> clk_prepare/clk_unprepare.
>>
>>
>> I agree with Russell's suggestion. This is what I'm trying to do with the
>> MSM platform. Not sure if I'm too optimistic, but as of today, I'm still
>> optimistic I can push the MSM driver devs to get this done before we enable
>> real prepare/unprepare support.
>
> Just to reach closure on this topic: I don't plan to change
> __clk_unprepare in the next version of the patches.  The warnings are
> doing a fine job of catching code which has yet to be properly
> converted to use clk_(un)prepare.

To be fair, I also have to improve the stub clk_prepare/unprepare to 
maintain ref counts and do refcount checking before I plan to cut off to 
the real prepare/unprepare implementations. So, I'm guessing Mike is 
just trying to partly add that support in this patch series.

My goal is to have MSM converted fully before switching to this. So, 
this code that we are debating about won't directly impact MSM. For that 
reason, I won't be trying to hold off the more important common clock 
framework due to unconventional error handling.

Thanks,
Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
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/