Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp884615pxb; Wed, 6 Apr 2022 03:11:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx9osa1s3QmmYzyYDCr0O6QKUp/fgTUjS2TXDBde1WLDTAlEVCkJo9K++DBXmTXCxMN8nsU X-Received: by 2002:a17:902:e8cf:b0:156:36e0:6bcb with SMTP id v15-20020a170902e8cf00b0015636e06bcbmr7654459plg.105.1649239882324; Wed, 06 Apr 2022 03:11:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649239882; cv=none; d=google.com; s=arc-20160816; b=hQeca3POTjptCmMa3TMjhAR0bWnl8cX9py/+evoXwy6Ulh7bEERgyE0/K73PQJydru 1tW3vecCCoOgolSgsRAiQgvJPOCX8j+egMMo1kaOA45SvTlR6MsxvK6bggTNX41FRxfL aXlgpCmjWwXrHYXJmR+5lpVuUYsBpnKxHLIVmHSELDpHJK+Teje6LjZ43wrjbOpJpxnv lPg3aFQnx6wwmxcuIstBJj0RpZrFnjw3MFSPefBOjjzIGbrecoMssgb8HR6x7OjjftSK VE9xg+3wpPpd8KA5zg8DC9FLkU9ytkRHmTwgyDfAa99PbkxILtDehgBh/R2KOX4m7QwF gtUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=LXykuRaJGqwIACO1LnwtZQBbVYq8YXLCbbj3k1AIYPU=; b=FObU8sq8AQDxLZ2jO7wmp9KjHQzLylBYgw61IzoUvUb4IV9fPjuydu/wuB0KcfEVpi ihZht/FFpVHBhEhgGoOJ7IlkTJRYlCa113kM2cIfSLfMcc0MfWPaOspVcr0Mb3Q5IG9l 5662sTSfnnvoKDq6msDSb1KskZyhtMbDE6P52p/B8+aMsx8pKo0fY/ceie/bNXrwlg7K 5LRi4m4IF95j/RBR0ruFHuMkwk34/Quc9842Xosf1gAWNV/W1AVLkMzCVcmGJE5t+LhL Vg5OnvXR0e7A8LetV9ubafDCiIVhOBC7I+hdU54iqClI3I/j+fuBvZqcEygl0zxi2/3P 9cGA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Su8Kv7Ly; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id g12-20020a17090a640c00b001ca3696234bsi4057823pjj.89.2022.04.06.03.11.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Apr 2022 03:11:22 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Su8Kv7Ly; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 5DE8749DC5E; Wed, 6 Apr 2022 01:37:46 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1842135AbiDFB1L (ORCPT + 99 others); Tue, 5 Apr 2022 21:27:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43504 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1354897AbiDEKQa (ORCPT ); Tue, 5 Apr 2022 06:16:30 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1DDFF11A; Tue, 5 Apr 2022 03:03:41 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id BFCDFB81C83; Tue, 5 Apr 2022 10:03:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3657DC385A1; Tue, 5 Apr 2022 10:03:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1649153018; bh=f5R8xVr5kUHPjjSTgAHG6sQa1CUFc8FtQRCPyki1CVU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Su8Kv7LySmkbtMOFxVAm3X2D5GZ6oFbGE0WcJPZFM32Vy8WYdbHXSAvKpCvfvZMV2 9t0w6lUI1uIn8DUI9lBh24lFTcb+9JhU+wmMDWog0BpkiJeVus851OE9aMAcMP5Xo+ If5IsarbPepD7SRSX049g9wRzkHgKI2X03XSmg0c= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mohan Kumar , Takashi Iwai Subject: [PATCH 5.10 071/599] ALSA: hda: Avoid unsol event during RPM suspending Date: Tue, 5 Apr 2022 09:26:05 +0200 Message-Id: <20220405070300.939324041@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220405070258.802373272@linuxfoundation.org> References: <20220405070258.802373272@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Mohan Kumar commit 6ddc2f749621d5d45ca03edc9f0616bcda136d29 upstream. There is a corner case with unsol event handling during codec runtime suspending state. When the codec runtime suspend call initiated, the codec->in_pm atomic variable would be 0, currently the codec runtime suspend function calls snd_hdac_enter_pm() which will just increments the codec->in_pm atomic variable. Consider unsol event happened just after this step and before snd_hdac_leave_pm() in the codec runtime suspend function. The snd_hdac_power_up_pm() in the unsol event flow in hdmi_present_sense_via_verbs() function would just increment the codec->in_pm atomic variable without calling pm_runtime_get_sync function. As codec runtime suspend flow is already in progress and in parallel unsol event is also accessing the codec verbs, as soon as codec suspend flow completes and clocks are switched off before completing the unsol event handling as both functions doesn't wait for each other. This will result in below errors [ 589.428020] tegra-hda 3510000.hda: azx_get_response timeout, switching to polling mode: last cmd=0x505f2f57 [ 589.428344] tegra-hda 3510000.hda: spurious response 0x80000074:0x5, last cmd=0x505f2f57 [ 589.428547] tegra-hda 3510000.hda: spurious response 0x80000065:0x5, last cmd=0x505f2f57 To avoid this, the unsol event flow should not perform any codec verb related operations during RPM_SUSPENDING state. Signed-off-by: Mohan Kumar Cc: Link: https://lore.kernel.org/r/20220329155940.26331-1-mkumard@nvidia.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman --- sound/pci/hda/patch_hdmi.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -1608,6 +1608,7 @@ static void hdmi_present_sense_via_verbs struct hda_codec *codec = per_pin->codec; struct hdmi_spec *spec = codec->spec; struct hdmi_eld *eld = &spec->temp_eld; + struct device *dev = hda_codec_dev(codec); hda_nid_t pin_nid = per_pin->pin_nid; int dev_id = per_pin->dev_id; /* @@ -1621,8 +1622,13 @@ static void hdmi_present_sense_via_verbs int present; int ret; +#ifdef CONFIG_PM + if (dev->power.runtime_status == RPM_SUSPENDING) + return; +#endif + ret = snd_hda_power_up_pm(codec); - if (ret < 0 && pm_runtime_suspended(hda_codec_dev(codec))) + if (ret < 0 && pm_runtime_suspended(dev)) goto out; present = snd_hda_jack_pin_sense(codec, pin_nid, dev_id);