linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Daniel Baluta <daniel.baluta@gmail.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	Charles Keepax <ckeepax@opensource.wolfsonmicro.com>,
	Daniel Baluta <daniel.baluta@nxp.com>,
	patches@opensource.wolfsonmicro.com, alsa-devel@alsa-project.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ASoC: codec: wm9860: avoid maybe-uninitialized warning
Date: Thu, 20 Apr 2017 09:44:28 +0200	[thread overview]
Message-ID: <CAK8P3a1_8GmVXu_gQ-dm_5SrA2bn8M7Vdb+kFC-hugkHCnYOww@mail.gmail.com> (raw)
In-Reply-To: <CAEnQRZCDi1_dsBjo_10h2ntOH57mCXMS=GeqLUgahnoVu8pBDw@mail.gmail.com>

On Thu, Apr 20, 2017 at 8:48 AM, Daniel Baluta <daniel.baluta@gmail.com> wrote:
> Hi Arnd,
>
> On Wed, Apr 19, 2017 at 8:04 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> The new PLL configuration code triggers a harmless warning:
>>
>> sound/soc/codecs/wm8960.c: In function 'wm8960_configure_clocking':
>> sound/soc/codecs/wm8960.c:735:3: error: 'best_freq_out' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>    wm8960_set_pll(codec, freq_in, best_freq_out);
>>    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> sound/soc/codecs/wm8960.c:699:12: note: 'best_freq_out' was declared here
>>
>> I think the warning was introduced by Daniel's bugfix. I've come up
>> with a way to simplify the code in a way that is more readable to
>> both humans and to gcc, which gets us rid of the warning.
>
> I've struggled with this kind of warning when reworking wm8960
> bitclock computation.
>
> Anyhow, for this exact patch the warning didn't showed up.
>
> I used:
>
> gcc version 6.2.1 20161016 (Linaro GCC 6.2-2016.11)

I'm using gcc-7.0.1 here, which overall has better warnings for
-Wmaybe-uninitialized
than older versions, but sometimes also finds new false positives.

> My next patch:
>
> https://patchwork.kernel.org/patch/9666921/ [1]
>
> which is under review, had the issue you mention (in v1)
>
> https://lkml.org/lkml/2017/4/5/246
>
> but I initialized best_freq_out with 0 to get rid of the problem.

I try hard not to do that, because it can hide real problems in case the
code gets modified further to actually have an uninitialized use that we
would otherwise get a warning for.

>> @@ -720,22 +718,14 @@ int wm8960_configure_pll(struct snd_soc_codec *codec, int freq_in,
>>                                         *sysclk_idx = i;
>>                                         *dac_idx = j;
>>                                         *bclk_idx = k;
>> -                                       best_freq_out = freq_out;
>> -                                       break;
>> +                                       return freq_out;
>>                                 }
>>                         }
>> -                       if (k != ARRAY_SIZE(bclk_divs))
>> -                               break;
>>                 }
>> -               if (j != ARRAY_SIZE(dac_divs))
>> -                       break;
>>         }
>> -
>> -       if (*bclk_idx != -1)
>> -               wm8960_set_pll(codec, freq_in, best_freq_out);
>
> I think the compiler is tricked into thinking that best_freq_out might
> be uninitialized. Notice
> that each time *bclk_idx is assigned a value (which is always >=0) we
> also initialize best_freq_out.

Right. This is probably the result of one of two things that
prevent the compiler from figuring it out:

a) bclk_idx being an indirect pointer might cause the compiler to
    decide that another operation might overwrite it, e.g. if it points
    to the same location as one of the other pointers.

b) The flow analysis might just get too tricky, so when gcc gives
    up trying to work out whether the assignment has happened
    at least once for the two variables, it concludes that it doesn't
    know, without seeing that the answer is always the same for
    both of them.

>> @@ -783,11 +773,12 @@ static int wm8960_configure_clocking(struct snd_soc_codec *codec)
>>                 }
>>         }
>>
>> -       ret = wm8960_configure_pll(codec, freq_in, &i, &j, &k);
>> -       if (ret < 0) {
>> +       freq_out = wm8960_configure_pll(codec, freq_in, &i, &j, &k);
>> +       if (freq_out < 0) {
>>                 dev_err(codec->dev, "failed to configure clock via PLL\n");
>> -               return -EINVAL;
>> +               return freq_out;
>>         }
>> +       wm8960_set_pll(codec, freq_in, freq_out);
>>
>>  configure_clock:
>>         /* configure sysclk clock */
>
> Your idea looks good, will need to rework my follow up patch on it:
>
> https://patchwork.kernel.org/patch/9666921/

Ok. Or feel free to fold my patch into yours if that makes it easier for you.

     Arnd

  reply	other threads:[~2017-04-20  7:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-19 17:04 [PATCH] ASoC: codec: wm9860: avoid maybe-uninitialized warning Arnd Bergmann
2017-04-20  6:48 ` Daniel Baluta
2017-04-20  7:44   ` Arnd Bergmann [this message]
2017-04-20  8:22     ` Daniel Baluta
2017-04-20 19:48     ` Mark Brown
2017-04-20  9:07 ` Charles Keepax
2017-05-14 10:05 ` Mark Brown
2017-05-15 14:03   ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAK8P3a1_8GmVXu_gQ-dm_5SrA2bn8M7Vdb+kFC-hugkHCnYOww@mail.gmail.com \
    --to=arnd@arndb.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=ckeepax@opensource.wolfsonmicro.com \
    --cc=daniel.baluta@gmail.com \
    --cc=daniel.baluta@nxp.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patches@opensource.wolfsonmicro.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).