From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752591AbbE0MEt (ORCPT ); Wed, 27 May 2015 08:04:49 -0400 Received: from vi37-28-154-113.vibiznes.pl ([37.28.154.113]:36751 "EHLO vps-vb.mhejs.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750755AbbE0MEs (ORCPT ); Wed, 27 May 2015 08:04:48 -0400 Message-ID: <5565B2D0.6080506@maciej.szmigiero.name> Date: Wed, 27 May 2015 14:04:32 +0200 From: "Maciej S. Szmigiero" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 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 Subject: Re: [PATCH] ASoC: codecs: use SNDRV_PCM_FMTBIT_* for format bitmask References: <5560AB9D.1010807@maciej.szmigiero.name> <55647D25.80807@maciej.szmigiero.name> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org W dniu 26.05.2015 16:09, Takashi Iwai pisze: > 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 :) The fixes for these two remaining CODECs were included in the patch (I've meant that these two weren't in the automated checking report I've received). Upon looking again at it the "0-DAY kernel test infrastructure" have to be using some limited config, since all of the CODECs with this issue are being built/checked in allyesconfig (it selects the required dependences for them even on x86_64). > thanks, > > Takashi > Thanks, Maciej Szmigiero