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 mail@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