diff mbox

clk: Fix cached parent ptrs allocation

Message ID 1341407737-1016-1-git-send-email-pgaikwad@nvidia.com
State New, archived
Headers show

Commit Message

Prashant Gaikwad July 4, 2012, 1:15 p.m. UTC
Compiler optimizes code someway that even if clk->parents
is not NULL it tries to allocate parents array. Change the
condition so that compiler does not optimize it in wrong
way.

Also, initialize i to num_parents to make sure parent
is searched using parent name if parents is NULL.

Signed-off-by: Prashant Gaikwad <pgaikwad@nvidia.com>
---
Mike,

There could be some other way to fix problem. I have not
debugged it in detail but I think this simple change should do.

 drivers/clk/clk.c |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

Comments

Prashant Gaikwad July 5, 2012, 1:10 a.m. UTC | #1
On Wednesday 04 July 2012 06:45 PM, Prashant Gaikwad wrote:
> Compiler optimizes code someway that even if clk->parents
> is not NULL it tries to allocate parents array. Change the
> condition so that compiler does not optimize it in wrong
> way.
>
> Also, initialize i to num_parents to make sure parent
> is searched using parent name if parents is NULL.
>
> Signed-off-by: Prashant Gaikwad<pgaikwad@nvidia.com>
> ---
> Mike,
>
> There could be some other way to fix problem. I have not
> debugged it in detail but I think this simple change should do.
Mike,

Please ignore this patch as Rajendra has already sent patch to fix.

http://git.linaro.org/gitweb?p=people/mturquette/linux.git;a=commitdiff;h=863b13271f1608ab3af6f7a371047d9a66693e38

>   drivers/clk/clk.c |   10 +++++-----
>   1 files changed, 5 insertions(+), 5 deletions(-)
>
Stephen Warren July 5, 2012, 4:07 p.m. UTC | #2
On 07/04/2012 07:15 AM, Prashant Gaikwad wrote:
> Compiler optimizes code someway that even if clk->parents
> is not NULL it tries to allocate parents array. Change the
> condition so that compiler does not optimize it in wrong
> way.

If simply inverting the if test and swapping the if/else blocks solves
some problem, that sounds like a compiler bug that we need to track down
and file/fix.

> Also, initialize i to num_parents to make sure parent
> is searched using parent name if parents is NULL.

Are you sure the change to initialize i wasn't all that was required to
solve the problem though? Mike has applied a patch for this that'll be
applied to 3.5-rcX and hence trickle into 3.6.
Prashant Gaikwad July 5, 2012, 5:21 p.m. UTC | #3
On Thursday 05 July 2012 09:37 PM, Stephen Warren wrote:
> On 07/04/2012 07:15 AM, Prashant Gaikwad wrote:
>> Compiler optimizes code someway that even if clk->parents
>> is not NULL it tries to allocate parents array. Change the
>> condition so that compiler does not optimize it in wrong
>> way.
> If simply inverting the if test and swapping the if/else blocks solves
> some problem, that sounds like a compiler bug that we need to track down
> and file/fix.
>
>> Also, initialize i to num_parents to make sure parent
>> is searched using parent name if parents is NULL.
> Are you sure the change to initialize i wasn't all that was required to
> solve the problem though? Mike has applied a patch for this that'll be
> applied to 3.5-rcX and hence trickle into 3.6.
Just initializing i does not fix problem. The patch Mike has applied 
does two things
1. remove warning for uninitialized i
2. invert the if test
Stephen Warren July 5, 2012, 6:44 p.m. UTC | #4
On 07/05/2012 11:21 AM, Prashant Gaikwad wrote:
> On Thursday 05 July 2012 09:37 PM, Stephen Warren wrote:
>> On 07/04/2012 07:15 AM, Prashant Gaikwad wrote:
>>> Compiler optimizes code someway that even if clk->parents
>>> is not NULL it tries to allocate parents array. Change the
>>> condition so that compiler does not optimize it in wrong
>>> way.
>> If simply inverting the if test and swapping the if/else blocks solves
>> some problem, that sounds like a compiler bug that we need to track down
>> and file/fix.
>>
>>> Also, initialize i to num_parents to make sure parent
>>> is searched using parent name if parents is NULL.
>> Are you sure the change to initialize i wasn't all that was required to
>> solve the problem though? Mike has applied a patch for this that'll be
>> applied to 3.5-rcX and hence trickle into 3.6.
>
> Just initializing i does not fix problem. The patch Mike has applied
> does two things
> 1. remove warning for uninitialized i
> 2. invert the if test

Yes, but Mike's patch is very different to yours. Your patch description
says that you need to invert the if test to work around the compiler
optimizer so that it doesn't "optimize it in wrong way", whereas the
patch Mike applied was for a legitimate bug in the code; those are two
entirely different things.
diff mbox

Patch

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 026d901..b28f2ae 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1066,18 +1066,18 @@  static int __clk_set_parent(struct clk *clk, struct clk *parent)
 	struct clk *old_parent;
 	unsigned long flags;
 	int ret = -EINVAL;
-	u8 i;
+	u8 i = clk->num_parents;
 
 	old_parent = clk->parent;
 
 	/* find index of new parent clock using cached parent ptrs */
-	if (clk->parents)
+	if (!clk->parents)
+		clk->parents = kzalloc((sizeof(struct clk*) * clk->num_parents),
+								GFP_KERNEL);
+	else
 		for (i = 0; i < clk->num_parents; i++)
 			if (clk->parents[i] == parent)
 				break;
-	else
-		clk->parents = kzalloc((sizeof(struct clk*) * clk->num_parents),
-								GFP_KERNEL);
 
 	/*
 	 * find index of new parent clock using string name comparison