On 11/11/16 19:49, Arnd Bergmann wrote: > On Friday, November 11, 2016 9:13:00 AM CET Linus Torvalds wrote: >> On Thu, Nov 10, 2016 at 8:44 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: >>> >>> Please merge these directly if you are happy with the result. >> >> I will take this. > > Thanks a lot! > >> I do see two warnings, but they both seem to be valid and recent, >> though, so I have no issues with the spurious cases. > > Ok, both of them should have my fixes coming your way already. > >> Warning #1: >> >> sound/soc/qcom/lpass-platform.c: In function ‘lpass_platform_pcmops_open’: >> sound/soc/qcom/lpass-platform.c:83:29: warning: ‘dma_ch’ may be used >> uninitialized in this function [-Wmaybe-uninitialized] >> drvdata->substream[dma_ch] = substream; >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~ >> >> and 'dma_ch' usage there really is crazy and wrong. Broken by >> 022d00ee0b55 ("ASoC: lpass-platform: Fix broken pcm data usage") > > Right, the patches crossed here, the bugfix patch that introduced > this came into linux-next over the kernel summit, and the fix I > sent on Tuesday made it into Mark Brown's tree on Wednesday but not > before you pulled alsa tree. It should be fixed the next time you > pull from the alsa tree, the commit is > > 3b89e4b77ef9 ("ASoC: lpass-platform: initialize dma channel number") > >> Warning #2 is not a real bug, but it's reasonable that gcc doesn't >> know that storage_bytes (chip->read_size) has to be 2/4. Again, >> introduced recently by commit 231147ee77f3 ("iio: maxim_thermocouple: >> Align 16 bit big endian value of raw reads"), so you didn't see it. > > This is the one I mentioned in the commit message as one that > is fixed in linux-next and that should make it in soon. > >> drivers/iio/temperature/maxim_thermocouple.c: In function >> ‘maxim_thermocouple_read_raw’: >> drivers/iio/temperature/maxim_thermocouple.c:141:5: warning: ‘ret’ >> may be used uninitialized in this function [-Wmaybe-uninitialized] >> if (ret) >> ^ >> drivers/iio/temperature/maxim_thermocouple.c:128:6: note: ‘ret’ was >> declared here >> int ret; >> ^~~ >> >> and I guess that code can just initialize 'ret' to '-EINVAL' or >> something to just make the theoretical "somehow we had a wrong >> chip->read_size" case error out cleanly. > > Right, that was my conclusion too. I sent the bugfix on Oct 25 > for linux-next but it didn't make it in until this Monday, after > you pulled the patch that introduced it on Oct 29. > > The commit in staging-testing is > 32cb7d27e65d ("iio: maxim_thermocouple: detect invalid storage size in read()") > > Greg and Jonathan, I see now that this is part of the 'iio-for-4.10b' > branch, so I suspect you were not planning to send this before the > merge window. Could you make sure this ends up in v4.9 so we get > a clean build when -Wmaybe-uninitialized gets enabled again? I'll queue this up and send a pull to Greg tomorrow. Was highly doubtful that a false warning suppression (be it an understandable one) was worth sending mid cycle, hence it was taking the slow route. Jonathan > > Arnd > -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html