From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932541AbcHKAAL (ORCPT ); Wed, 10 Aug 2016 20:00:11 -0400 Received: from mail-pf0-f181.google.com ([209.85.192.181]:35581 "EHLO mail-pf0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932256AbcHKAAJ (ORCPT ); Wed, 10 Aug 2016 20:00:09 -0400 Subject: Re: [PATCH 6/9] clocksource: kona: fix get_counter error handling To: Arnd Bergmann , Daniel Lezcano , Thomas Gleixner References: <20160810215424.1926658-1-arnd@arndb.de> <20160810215424.1926658-7-arnd@arndb.de> Cc: Florian Fainelli , Ray Jui , Scott Branden , bcm-kernel-feedback-list@broadcom.com, linux-kernel@vger.kernel.org From: Ray Jui Message-ID: Date: Wed, 10 Aug 2016 17:00:03 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Thunderbird/47.0 MIME-Version: 1.0 In-Reply-To: <20160810215424.1926658-7-arnd@arndb.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Arnd, On 8/10/2016 2:54 PM, Arnd Bergmann wrote: > I could not figure out why, but gcc cannot prove that the > kona_timer_init function always initializes its two outputs, > and we get a warning for the use of the 'lsw' variable later, > which is obviously correct. > > drivers/clocksource/bcm_kona_timer.c: In function 'kona_timer_init': > drivers/clocksource/bcm_kona_timer.c:119:13: error: 'lsw' may be used uninitialized in this function [-Werror=maybe-uninitialized] > > Slightly reordering the loop makes the warning disappear, after > it becomes more obvious to the compiler that the loop is > always entered on the first iteration. > > As pointed out by Ray Jui, there is a related problem in the > way we deal with the loop running into the limit, as we just > keep going there with an invalid counter data, so instead we > now propagate a -ETIMEDOUT result to the caller. > > Signed-off-by: Arnd Bergmann > Link: https://patchwork.kernel.org/patch/9174261/ > --- > Originally sent this as a warning fix only on June 13, this > version actually fixes the incorrect data problem. > --- > drivers/clocksource/bcm_kona_timer.c | 16 ++++++++++------ > 1 file changed, 10 insertions(+), 6 deletions(-) > > diff --git a/drivers/clocksource/bcm_kona_timer.c b/drivers/clocksource/bcm_kona_timer.c > index 7e3fd375a627..92f6e4deee74 100644 > --- a/drivers/clocksource/bcm_kona_timer.c > +++ b/drivers/clocksource/bcm_kona_timer.c > @@ -66,10 +66,10 @@ static void kona_timer_disable_and_clear(void __iomem *base) > > } > > -static void > +static int > kona_timer_get_counter(void __iomem *timer_base, uint32_t *msw, uint32_t *lsw) > { > - int loop_limit = 4; > + int loop_limit = 3; > > /* > * Read 64-bit free running counter > @@ -83,18 +83,19 @@ kona_timer_get_counter(void __iomem *timer_base, uint32_t *msw, uint32_t *lsw) > * if new hi-word is equal to previously read hi-word then stop. > */ > > - while (--loop_limit) { > + do { > *msw = readl(timer_base + KONA_GPTIMER_STCHI_OFFSET); > *lsw = readl(timer_base + KONA_GPTIMER_STCLO_OFFSET); > if (*msw == readl(timer_base + KONA_GPTIMER_STCHI_OFFSET)) > break; > - } > + } while (--loop_limit); > if (!loop_limit) { > pr_err("bcm_kona_timer: getting counter failed.\n"); > pr_err(" Timer will be impacted\n"); > + return -ETIMEDOUT; > } > > - return; > + return 0; > } > > static int kona_timer_set_next_event(unsigned long clc, > @@ -112,8 +113,11 @@ static int kona_timer_set_next_event(unsigned long clc, > > uint32_t lsw, msw; > uint32_t reg; > + int ret; > > - kona_timer_get_counter(timers.tmr_regs, &msw, &lsw); > + ret = kona_timer_get_counter(timers.tmr_regs, &msw, &lsw); > + if (ret) > + return ret; > > /* Load the "next" event tick value */ > writel(lsw + clc, timers.tmr_regs + KONA_GPTIMER_STCM0_OFFSET); > The change looks good to me! Thanks! Acked-by: Ray Jui