Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755546AbbEZOJQ (ORCPT ); Tue, 26 May 2015 10:09:16 -0400 Received: from cantor2.suse.de ([195.135.220.15]:43824 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751561AbbEZOJM (ORCPT ); Tue, 26 May 2015 10:09:12 -0400 Date: Tue, 26 May 2015 16:09:09 +0200 Message-ID: From: Takashi Iwai To: "Maciej S. Szmigiero" 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 Subject: Re: [PATCH] ASoC: codecs: use SNDRV_PCM_FMTBIT_* for format bitmask In-Reply-To: <55647D25.80807@maciej.szmigiero.name> References: <5560AB9D.1010807@maciej.szmigiero.name> <55647D25.80807@maciej.szmigiero.name> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/24.5 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2198 Lines: 58 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 > > > > 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] > > 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/