At Tue, 26 May 2015 16:03:17 +0200, Maciej S. Szmigiero wrote: > > Hello Takashi, > > W dniu 26.05.2015 07:29, Takashi Iwai pisze: > > At Sat, 23 May 2015 18:32:29 +0200, > > Maciej S. Szmigiero wrote: > >> > >> snd_soc_pcm_stream.formats is a bitmask of SNDRV_PCM_FMTBIT_*, > >> not of SNDRV_PCM_FORMAT_* (which are sequential integers), > >> however some of ASoC CODEC drivers use these values instead. > >> > >> Found out by sparse on 0-day kernel tester. > >> > >> Signed-off-by: Maciej Szmigiero <m...@maciej.szmigiero.name> > > > > Wow, that made me wonder how these drivers could actually work. > > Maybe, by coincidence, the wrong defines contained enough bits > set to actually select some common, working format with their > controllers?
Well, FORMAT_S16_LE = 2, and FORMAT_S18_3LE = 40. So bits 1, 3 and 5 are set, which corresponds to U8, S16_BE and U16_BE. Hmm. > > BTW, how did you detect it? Any static analyzer like sparse or > > smatch? sparse didn't detect it at the last time I tried, IIRC... > > I've received an e-mail from "kbuild test robot" at > "0-DAY kernel test infrastructure" that automated testing there > using sparse found this issue on wm9713 and stac9766 CODECs. > > The exact warning was: > >> sound/soc/codecs/stac9766.c:324:28: sparse: incorrect type in initializer > >> (different base types) > sound/soc/codecs/stac9766.c:324:28: expected unsigned long long > [unsigned] [usertype] formats > sound/soc/codecs/stac9766.c:324:28: got restricted snd_pcm_format_t > [usertype] <noident> > > What is important the warning doesn't show unless a check build > is made with CF=-D__CHECK_ENDIAN__ . Ah, thanks, that was the missing piece. > Upon checking I've found the same issue also in two other CODECs, > which aren't normally being built on x86_64 (target architecture > for above automated build) even when SND_SOC_ALL_CODECS is selected. Oh it'd be great if you submit fixes :) thanks, Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/