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 5F55EC433EF for ; Fri, 3 Dec 2021 14:49:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D12996B0073; Fri, 3 Dec 2021 09:49:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CC21D6B0074; Fri, 3 Dec 2021 09:49:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B88BD6B0075; Fri, 3 Dec 2021 09:49:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0020.hostedemail.com [216.40.44.20]) by kanga.kvack.org (Postfix) with ESMTP id ABE926B0073 for ; Fri, 3 Dec 2021 09:49:02 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 709DE84767 for ; Fri, 3 Dec 2021 14:48:52 +0000 (UTC) X-FDA: 78876764904.26.ECD1792 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by imf14.hostedemail.com (Postfix) with ESMTP id 436C86001988 for ; Fri, 3 Dec 2021 14:48:51 +0000 (UTC) X-IronPort-AV: E=McAfee;i="6200,9189,10186"; a="235718250" X-IronPort-AV: E=Sophos;i="5.87,284,1631602800"; d="scan'208";a="235718250" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Dec 2021 06:48:49 -0800 X-IronPort-AV: E=Sophos;i="5.87,284,1631602800"; d="scan'208";a="561737142" Received: from hkagda-mobl2.amr.corp.intel.com (HELO [10.212.71.79]) ([10.212.71.79]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Dec 2021 06:48:49 -0800 Subject: Re: [linux-next:master 3956/5128] sound/soc/sof/intel/hda-codec.c:132:35: error: use of undeclared identifier 'CODEC_PROBE_RETRIES' To: Kai Vehmanen Cc: "moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM..." , kbuild-all@lists.01.org, kernel test robot , llvm@lists.linux.dev, Hui Wang , Linux Memory Management List , Mark Brown , Bard Liao References: <202112031943.Twg19fWT-lkp@intel.com> From: Pierre-Louis Bossart Message-ID: <7631ac5e-c1c4-9051-ee7a-985ed02183e5@linux.intel.com> Date: Fri, 3 Dec 2021 08:48:46 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Stat-Signature: r8qbapzn4gk8xby1wppa316h66pxuaze Authentication-Results: imf14.hostedemail.com; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=intel.com (policy=none); spf=none (imf14.hostedemail.com: domain of pierre-louis.bossart@linux.intel.com has no SPF policy when checking 192.55.52.120) smtp.mailfrom=pierre-louis.bossart@linux.intel.com X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 436C86001988 X-HE-Tag: 1638542931-65212 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: On 12/3/21 8:07 AM, Kai Vehmanen wrote: > 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. Would it be a major risk to drop this compatibility, possibly in steps that can be reverted quickly? Maintaining this old HDMI-specific path isn't really sustainable. > I'll send the quick fix. Thanks!