From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 19795C433F5 for ; Fri, 3 Dec 2021 14:15:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9176B6B0073; Fri, 3 Dec 2021 09:15:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8C7946B0074; Fri, 3 Dec 2021 09:15:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 78F656B0075; Fri, 3 Dec 2021 09:15:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0217.hostedemail.com [216.40.44.217]) by kanga.kvack.org (Postfix) with ESMTP id 6B5AE6B0073 for ; Fri, 3 Dec 2021 09:15:37 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 2DE4718403FFB for ; Fri, 3 Dec 2021 14:15:27 +0000 (UTC) X-FDA: 78876680694.24.6D1B7E3 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by imf05.hostedemail.com (Postfix) with ESMTP id 557A6100002 for ; Fri, 3 Dec 2021 14:15:26 +0000 (UTC) X-IronPort-AV: E=McAfee;i="6200,9189,10186"; a="216998706" X-IronPort-AV: E=Sophos;i="5.87,284,1631602800"; d="scan'208";a="216998706" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Dec 2021 06:15:24 -0800 X-IronPort-AV: E=Sophos;i="5.87,284,1631602800"; d="scan'208";a="610414696" Received: from eliteleevi.tm.intel.com ([10.237.54.20]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Dec 2021 06:15:22 -0800 Date: Fri, 3 Dec 2021 16:07:43 +0200 (EET) From: Kai Vehmanen X-X-Sender: kvehmane@eliteleevi.tm.intel.com To: Pierre-Louis Bossart cc: kernel test robot , Hui Wang , "moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM..." , kbuild-all@lists.01.org, Kai Vehmanen , llvm@lists.linux.dev, Linux Memory Management List , Mark Brown , Bard Liao Subject: Re: [linux-next:master 3956/5128] sound/soc/sof/intel/hda-codec.c:132:35: error: use of undeclared identifier 'CODEC_PROBE_RETRIES' In-Reply-To: Message-ID: References: <202112031943.Twg19fWT-lkp@intel.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7 02160 Espoo MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 557A6100002 X-Stat-Signature: b7k5gcdpguhcbjywbpqkd68njzgo5miq Authentication-Results: imf05.hostedemail.com; dkim=none; spf=none (imf05.hostedemail.com: domain of kai.vehmanen@linux.intel.com has no SPF policy when checking 192.55.52.136) smtp.mailfrom=kai.vehmanen@linux.intel.com; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=intel.com (policy=none) X-HE-Tag: 1638540926-825634 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hey, On Fri, 3 Dec 2021, Pierre-Louis Bossart wrote: > > 127 do { > > 128 mutex_lock(&hbus->core.cmd_mutex); > > 129 snd_hdac_bus_send_cmd(&hbus->core, hda_cmd); > > 130 snd_hdac_bus_get_response(&hbus->core, address, &resp); > > 131 mutex_unlock(&hbus->core.cmd_mutex); > > > 132 } while (resp == -1 && retry++ < CODEC_PROBE_RETRIES); > > Indeed, something's not right here. > > CODEC_PROBE_RETRIES is defined conditionally > > #if IS_ENABLED(CONFIG_SND_SOC_SOF_HDA_AUDIO_CODEC) > #define IDISP_VID_INTEL 0x80860000 > #define CODEC_PROBE_RETRIES 3 > > but it's used unconditionally. yup, the definition needs to be moved out. > We could define this constant unconditionally as a quick fix, but this > compilation problem might expose a larger problem. > > Kai, I wonder if this is code from lines 120 to 139 that we didn't > update when we moved to support HDMI with the generic HDaudio parts? I > don't see why we could even try to send a command on the bus is there's > no audio codec support? > > hda_codec_use_common_hdmi should be the default assumption now, I don't > think we support the old solution, do we? We do still support the hdac-hdmi as well, albeit only for select old hardware to maintain backwards compatibility. I'll send the quick fix. Br, Kai