linux-kernel - Re: [PATCH] clk:mxs: Fix bug on frequency divider

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <55BBB1AC.6070102@codeaurora.org>
Date:	Fri, 31 Jul 2015 10:34:36 -0700
From:	Stephen Boyd <sboyd@...eaurora.org>
To:	Victorien Vedrine <victorien.vedrine@...rys.net>
CC:	linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org,
	mturquette@...libre.com, Shawn Guo <shawn.guo@...aro.org>
Subject: Re: [PATCH] clk:mxs: Fix bug on frequency divider

+Shawn

On 07/31/2015 09:24 AM, Victorien Vedrine wrote:
> On drivers/clk/mxs/clk-frac.c, the function clk_frac_round_rate returned a bad
> result. The division before multiplication computes a wrong value ; the
> calculation is inverted to fix the problem. The second issue is that the exact
> rate have decimals and they are truncate. The consequence is that the function
> clk_frac_set_rate (which use the result of clk_frac_round_rate) computes a
> wrong value for the register (the rate generated can be closer to the desired
> rate). The correction is : if there is decimal to the result, it is rounded to
> the next larger integer.
>
> On drivers/clk/mxs/clk-frac.c, the function clk_frac_recalc_rate returned
> a bad result. The multiplication is made before the division to compute a
> correct value.
>
> The issue is reproducible by this way : Set the SAIF frequency to 22579200Hz
> (it's the appropriate frequency for 44100hz sample rate for SGTL5000 codec).
> With the divider register (HW_CLKCTRL_SAIF0), the closest lower value is
> 22573242.1875Hz (0xC0A on register). The original clk-frac functions give 0xC09
> on the divider register.
>
> Signed-off-by: Victorien Vedrine <victorien.vedrine@...rys.net>
> ---
>   drivers/clk/mxs/clk-frac.c | 13 ++++++++++---
>   1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/mxs/clk-frac.c b/drivers/clk/mxs/clk-frac.c
> index e6aa6b5..d51cf03 100644
> --- a/drivers/clk/mxs/clk-frac.c
> +++ b/drivers/clk/mxs/clk-frac.c
> @@ -42,11 +42,13 @@ static unsigned long clk_frac_recalc_rate(struct clk_hw *hw,
>   {
>   	struct clk_frac *frac = to_clk_frac(hw);
>   	u32 div;
> +	u64 tmp_rate;
>   
>   	div = readl_relaxed(frac->reg) >> frac->shift;
>   	div &= (1 << frac->width) - 1;
>   
> -	return (parent_rate >> frac->width) * div;
> +	tmp_rate = (u64)parent_rate * (u64)div;

We shouldn't need to cast both to 64 bits...

> +	return (unsigned long)(tmp_rate >> frac->width);

Isn't the cast implicit by means of the return type of this function?

>   }
>   
>   static long clk_frac_round_rate(struct clk_hw *hw, unsigned long rate,
> @@ -55,7 +57,7 @@ static long clk_frac_round_rate(struct clk_hw *hw, unsigned long rate,
>   	struct clk_frac *frac = to_clk_frac(hw);
>   	unsigned long parent_rate = *prate;
>   	u32 div;
> -	u64 tmp;
> +	u64 tmp, tmp_rate, result;
>   
>   	if (rate > parent_rate)
>   		return -EINVAL;
> @@ -68,7 +70,12 @@ static long clk_frac_round_rate(struct clk_hw *hw, unsigned long rate,
>   	if (!div)
>   		return -EINVAL;
>   
> -	return (parent_rate >> frac->width) * div;
> +	tmp_rate = (u64)parent_rate * (u64)div;
> +	result = (u64)(tmp_rate >> frac->width);

Cast looks useless here too.

> +	if ((result << frac->width) < tmp_rate)
> +		return result + 1;
> +	else
> +		return result;

The else could be dropped and just be return result. Also, have you see 
mult_frac()? I suppose we're doing shifts with width because it's a 
power-of-2 denominator?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

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