[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.10.1409031241310.3333@nanos>
Date: Wed, 3 Sep 2014 12:57:38 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Xiubo Li <Li.Xiubo@...escale.com>
cc: daniel.lezcano@...aro.org, dongsheng.wang@...escale.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/5] Clocksource: Flextimer: Fix counter clock prescaler
calculation.
On Tue, 26 Aug 2014, Xiubo Li wrote:
> We should minus one after calculating the counter input clock's
> prescaler.
>
> Signed-off-by: Xiubo Li <Li.Xiubo@...escale.com>
> Signed-off-by: Jingchang Lu <jingchang.lu@...escale.com>
> ---
> drivers/clocksource/fsl_ftm_timer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clocksource/fsl_ftm_timer.c b/drivers/clocksource/fsl_ftm_timer.c
> index f70fcf2..974890e 100644
> --- a/drivers/clocksource/fsl_ftm_timer.c
> +++ b/drivers/clocksource/fsl_ftm_timer.c
> @@ -311,7 +311,7 @@ static int __init ftm_calc_closest_round_cyc(unsigned long freq)
> HZ * (1 << priv->ps++));
> } while (priv->periodic_cyc > 0xFFFF);
>
> - if (priv->ps > FTM_PS_MAX) {
> + if (--priv->ps > FTM_PS_MAX) {
Looking at this makes me run away screaming. Just because you
increment priv->ps unconditionally in the loop above, you decrement it
again here. Why not fix the calculation proper in the first place?
for (cyc = ~0UL, ps = 0, div = HZ; cyc > 0xffff; ps++, div *= 2)
cyc = DIV_ROUND_CLOSEST(freq, div);
Hmm?
tglx
--
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