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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DDDD2C77B7C for ; Fri, 5 May 2023 19:23:09 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4QCgZN2mLyz3fDQ for ; Sat, 6 May 2023 05:23:08 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=YwTdfSXX; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=139.178.84.217; helo=dfw.source.kernel.org; envelope-from=helgaas@kernel.org; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=YwTdfSXX; dkim-atps=neutral Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4QCgYL2SWTz3cjF for ; Sat, 6 May 2023 05:22:14 +1000 (AEST) 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 dfw.source.kernel.org (Postfix) with ESMTPS id 55C6860AB1; Fri, 5 May 2023 19:22:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 85A84C433D2; Fri, 5 May 2023 19:22:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1683314530; bh=F1EwEIEQYCrE2wRZwLhg+lUx3xE4/L3DxAf6BZZ3Unk=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=YwTdfSXXkUaVZVYnPIvGcCvU1pI5Ybu20g/RPIVeMA9cbkxDIZoOCdzm5IriR0OEC 45lphTtTVD6/Gbb65q6Gdv/U5viDq97AFV2UvvtSyCYRWRef/av4ZWxOtPwlaIUga4 imhV2c6c66VTs2i6sW/NNbY74EHya4ywNXL1h9VIaV/w/UB4OmDrWbLU9vm92EJlnP eoPNa7lmXqAgWTlyCs1J7Fc1Yi0PDq/B41IwNkfm4knaSHXPCxEPukq1dpaG3qN7kx yI3jzkjA84g/8/nFPRkbamP8CzZlCHycvlNhc9tr5N1Xx6EV4CjQStQApUWRqKuLIs C4aWftP8Y982g== Date: Fri, 5 May 2023 14:22:08 -0500 From: Bjorn Helgaas To: Kai-Heng Feng Subject: Re: [PATCH v4 2/3] PCI/AER: Disable AER interrupt on suspend Message-ID: <20230505192208.GA970992@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230424055249.460381-2-kai.heng.feng@canonical.com> X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: sathyanarayanan.kuppuswamy@linux.intel.com, linuxppc-dev@lists.ozlabs.org, Mahesh J Salgaonkar , linux-kernel@vger.kernel.org, koba.ko@canonical.com, Oliver O'Halloran , linux-pci@vger.kernel.org, bhelgaas@google.com, mika.westerberg@linux.intel.com Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Mon, Apr 24, 2023 at 01:52:48PM +0800, Kai-Heng Feng wrote: > PCIe service that shares IRQ with PME may cause spurious wakeup on > system suspend. > > 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), so we don't lose > much here to disable AER during system suspend. > > This is very similar to previous attempts to suspend AER and DPC [1], > but with a different reason. What is the reason? I assume it's something to do with the bugzilla below, but the commit log should outline the user-visible problem this fixes. The commit log basically makes the case for "why should we merge this patch." I assume it's along the lines of "I tried to suspend this system, but it immediately woke up again because of an AER interrupt, and disabling AER during suspend avoids this problem. And disabling the AER interrupt is not a problem because X" > [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 > --- > 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, > }; > > -- > 2.34.1 >