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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 96C7DC77B7F for ; Thu, 11 May 2023 22:08:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239402AbjEKWIX (ORCPT ); Thu, 11 May 2023 18:08:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57854 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239572AbjEKWIF (ORCPT ); Thu, 11 May 2023 18:08:05 -0400 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7F598AD3A; Thu, 11 May 2023 15:07:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1683842862; x=1715378862; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=dcivrtBNBKYrwhHCG20eFak+R1jORc9y5Sw1snBi2S4=; b=kxqy3PvUa9WGfpgr+LUEjRxmxUm+zOOENAL6qsOFn8dSkbOUCqHGYL0Z 7lXCS6z4OCarbm3jfExXgAAkgqWTx/guJ5pH6OlLGf4BfvHLccFA7/Dy4 PgxqKUXsjdWp41iFRXckIONgwPPIWhg5fMf8b4BFia08nwn6JetdP2nw1 x2nYIQDBDOoVIwjcPIHEZO9onQgQNLWJD4d6CNcsHqVvsoDGRhej8l8f3 e7+QxR4NX11fNgYkUi4DNEMjxKHiZPTwxetNzjoqRcaClmok/6U3CG+qS 1wxPwDKjb/oOi8wX6idciuU2KaVCCPQupFz46NS8vrwWcwOOnGXh2U77G Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10707"; a="378780014" X-IronPort-AV: E=Sophos;i="5.99,268,1677571200"; d="scan'208";a="378780014" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 May 2023 15:07:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10707"; a="824138929" X-IronPort-AV: E=Sophos;i="5.99,268,1677571200"; d="scan'208";a="824138929" Received: from swalker-mobl1.amr.corp.intel.com (HELO [10.209.63.194]) ([10.209.63.194]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 May 2023 15:07:23 -0700 Message-ID: <35b33699-227d-d1f5-285a-e18ef8e91e57@linux.intel.com> Date: Thu, 11 May 2023 15:07:22 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.10.0 Subject: Re: [PATCH v5 2/3] PCI/AER: Disable AER interrupt on suspend Content-Language: en-US To: Kai-Heng Feng , bhelgaas@google.com Cc: mika.westerberg@linux.intel.com, koba.ko@canonical.com, Mahesh J Salgaonkar , Oliver O'Halloran , linuxppc-dev@lists.ozlabs.org, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org References: <20230511133610.99759-1-kai.heng.feng@canonical.com> <20230511133610.99759-2-kai.heng.feng@canonical.com> From: Sathyanarayanan Kuppuswamy In-Reply-To: <20230511133610.99759-2-kai.heng.feng@canonical.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On 5/11/23 6:36 AM, Kai-Heng Feng wrote: > PCIe service that shares IRQ with PME may cause spurious wakeup on > system suspend. > > This is very similar to previous attempts to suspend AER and DPC [1], > but this time disabling AER IRQ is to prevent immediate PME wakeup when > AER shares the same IRQ line with PME. IMHO, you don't need to mention the previous submission reason. > > It's okay to disable AER because PCIe Base Spec 5.0, section 5.2 "Link > State Power Management" states that TLP and DLLP transmission is > disabled for a Link in L2/L3 Ready (D3hot), L2 (D3cold with aux power) > and L3 (D3cold), hence we don't lose much here to disable AER IRQ during > system suspend. May be something like below? PCIe services that share an IRQ with PME, such as AER or DPC, may cause a spurious wakeup on system suspend. To prevent this, disable the AER interrupt notification during the system suspend process. As Per PCIe Base Spec 5.0, section 5.2, titled "Link State Power Management", TLP and DLLP transmission are disabled for a Link in L2/L3 Ready (D3hot), L2 (D3cold with aux power) and L3 (D3cold) states. So disabling the AER notification during suspend and re-enabling them during the resume process should not affect the basic functionality. > > [1] https://lore.kernel.org/linux-pci/20220408153159.106741-1-kai.heng.feng@canonical.com/ > Link: https://bugzilla.kernel.org/show_bug.cgi?id=216295 > > Reviewed-by: Mika Westerberg > Signed-off-by: Kai-Heng Feng > --- > v5: > - Wording. > > v4: > v3: > - No change. > > v2: > - Only disable AER IRQ. > - No more check on PME IRQ#. > - Use helper. > > drivers/pci/pcie/aer.c | 22 ++++++++++++++++++++++ > 1 file changed, 22 insertions(+) > > diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c > index 1420e1f27105..9c07fdbeb52d 100644 > --- a/drivers/pci/pcie/aer.c > +++ b/drivers/pci/pcie/aer.c > @@ -1356,6 +1356,26 @@ static int aer_probe(struct pcie_device *dev) > return 0; > } > > +static int aer_suspend(struct pcie_device *dev) > +{ > + struct aer_rpc *rpc = get_service_data(dev); > + struct pci_dev *pdev = rpc->rpd; > + > + aer_disable_irq(pdev); > + > + return 0; > +} > + > +static int aer_resume(struct pcie_device *dev) > +{ > + struct aer_rpc *rpc = get_service_data(dev); > + struct pci_dev *pdev = rpc->rpd; > + > + aer_enable_irq(pdev); > + > + return 0; > +} > + > /** > * aer_root_reset - reset Root Port hierarchy, RCEC, or RCiEP > * @dev: pointer to Root Port, RCEC, or RCiEP > @@ -1420,6 +1440,8 @@ static struct pcie_port_service_driver aerdriver = { > .service = PCIE_PORT_SERVICE_AER, > > .probe = aer_probe, > + .suspend = aer_suspend, > + .resume = aer_resume, > .remove = aer_remove, > }; > -- Sathyanarayanan Kuppuswamy Linux Kernel Developer