Messages in this thread | | | Date | Tue, 26 May 2015 16:03:17 +0200 | From | "Maciej S. Szmigiero" <> | Subject | Re: [PATCH] ASoC: codecs: use SNDRV_PCM_FMTBIT_* for format bitmask |
| |
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
| |