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? > 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__ . 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. > thanks, > > Takashi Best regards, Maciej Szmigiero -- 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/
