From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Maciej S. Szmigiero" Subject: Re: [PATCH] ASoC: codecs: use SNDRV_PCM_FMTBIT_* for format bitmask Date: Tue, 26 May 2015 16:03:17 +0200 Message-ID: <55647D25.80807@maciej.szmigiero.name> References: <5560AB9D.1010807@maciej.szmigiero.name> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Takashi Iwai Cc: "alsa-devel@alsa-project.org" , linux-kernel , patches@opensource.wolfsonmicro.com, Liam Girdwood , Mark Brown , Jaroslav Kysela , Lars-Peter Clausen , Daniel Mack , Wolfram Sang , Charles Keepax , Matt Reimer List-Id: alsa-devel@alsa-project.org 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 > > 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] 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