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 X-Spam-Level: X-Spam-Status: No, score=-10.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS,USER_AGENT_MUTT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E1997C04EB8 for ; Tue, 4 Dec 2018 09:46:24 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B39152082D for ; Tue, 4 Dec 2018 09:46:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="DBv5km03" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B39152082D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=gKQXASiZqSYcXZ7wnDxWEe7EV/G/L82KnyZuo801jjA=; b=DBv5km03jW5doS /OdU4oOy85J/MvntTgRai/muioNeo+4MysZKPcAsrUWtD14kr0vc/r8lGcKKvbzx93XfN/H/dCDLd 4FX+ndGM3BkfZEsFn86+SAfCVgl5VxTtO8fx4CRxCme4gwioS7ilUMDfQyNLfEwPy3ph9oW1AWbtR mMJIvCQ7zitmK3PsiaNW5ExEtH0nZrvtPke2BOh0c4IHNobqCTbg6QG7b9KvC9HVFUqE8CEELGzYn SMDam6zf5eI8/FA+XGOcvuzRbRu+Q7HHtNeF4TD2bsT+Fu5UH3H7yDD2AlaVNyfNXUqyDG2XmJxb9 9rPMQ+MSF1/P/Nj409OA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gU7HZ-0004Dk-Ct; Tue, 04 Dec 2018 09:46:21 +0000 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70] helo=foss.arm.com) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gU7HV-0004CV-QY for linux-arm-kernel@lists.infradead.org; Tue, 04 Dec 2018 09:46:19 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C5D81A78; Tue, 4 Dec 2018 01:46:06 -0800 (PST) Received: from e107981-ln.cambridge.arm.com (e107981-ln.cambridge.arm.com [10.1.197.40]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D152B3F5AF; Tue, 4 Dec 2018 01:46:03 -0800 (PST) Date: Tue, 4 Dec 2018 09:45:58 +0000 From: Lorenzo Pieralisi To: "Rafael J. Wysocki" Subject: Re: [PATCH 05/12] PCI: aardvark: add suspend to RAM support Message-ID: <20181204094558.GA24588@e107981-ln.cambridge.arm.com> References: <20181123141831.8214-1-miquel.raynal@bootlin.com> <20181203102708.GA6090@e107981-ln.cambridge.arm.com> <20181203163846.494904f9@xps13> <1999610.6DN9RK2Tt3@aspire.rjw.lan> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1999610.6DN9RK2Tt3@aspire.rjw.lan> User-Agent: Mutt/1.5.24 (2015-08-30) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20181204_014617_870697_89EC1999 X-CRM114-Status: GOOD ( 26.76 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Andrew Lunn , Jason Cooper , devicetree@vger.kernel.org, Antoine Tenart , linux-pci@vger.kernel.org, Gregory Clement , Miquel Raynal , linux-kernel@vger.kernel.org, Maxime Chevallier , Nadav Haklai , Rob Herring , Thomas Petazzoni , sudeep.holla@arm.com, Bjorn Helgaas , linux-arm-kernel@lists.infradead.org, Sebastian Hesselbarth Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Dec 03, 2018 at 11:00:20PM +0100, Rafael J. Wysocki wrote: > On Monday, December 3, 2018 4:38:46 PM CET Miquel Raynal wrote: > > Hi Lorenzo, > > > > Lorenzo Pieralisi wrote on Mon, 3 Dec 2018 > > 10:27:08 +0000: > > > > > [+Rafael, Sudeep] > > > > > > On Fri, Nov 23, 2018 at 03:18:24PM +0100, Miquel Raynal wrote: > > > > Add suspend and resume callbacks. The priority of these are > > > > "_noirq()", to workaround early access to the registers done by the > > > > PCI core through the ->read()/->write() callbacks at resume time. > > > > > > > > Signed-off-by: Miquel Raynal > > > > --- > > > > drivers/pci/controller/pci-aardvark.c | 52 +++++++++++++++++++++++++++ > > > > 1 file changed, 52 insertions(+) > > > > > > > > diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/controller/pci-aardvark.c > > > > index 108b3f15c410..7ecf1ac4036b 100644 > > > > --- a/drivers/pci/controller/pci-aardvark.c > > > > +++ b/drivers/pci/controller/pci-aardvark.c > > > > @@ -1108,6 +1108,55 @@ static int advk_pcie_setup_clk(struct advk_pcie *pci > > > > return ret; > > > > } > > > > > > > > +static int __maybe_unused advk_pcie_suspend(struct device *dev) > > > > +{ > > > > + struct advk_pcie *pcie = dev_get_drvdata(dev); > > > > + > > > > + advk_pcie_disable_phy(pcie); > > > > + > > > > + clk_disable_unprepare(pcie->clk); > > > > > > I have noticed it is common practice, still, I would like to check whether > > > it is allowed to call functions that may sleep in a NOIRQ suspend/resume > > > callback ? > > > > You are right this is weird. I double checked and for instance, > > pcie-mediatek.c, pci-tegra.c and pci-imx6.c do the exact same thing. There are > > probably other cases where drivers call functions that may sleep from a NOIRQ > > context. I am interested to know if this is valid and if not, what is the > > alternative? > > > > Yes, it is valid. _noirq means that the high-level action handlers > will not be invoked for interrupts occurring during that period, but > that doesn't apply to timer interrupts. > > IOW, don't expect *your* IRQ handler to be invoked then (if this is > not a timer IRQ), but you can sleep. Hi Rafael, all, I did not ask my question (that may be silly) properly apologies. I know that the S2R context allows sleeping the question is, in case clk_disable_unprepare() (and resume counterparts) sleeps, what is going to wake it up, given that we are in the S2R NOIRQ phase and as you said the action handlers (that are possibly required to wake up the eg clk_disable_unprepare() caller) are disabled (unless, AFAIK, IRQF_NO_SUSPEND is passed at IRQ request time in the respective driver). The clk API implementations back-ends are beyond my depth, I just wanted to make sure I understand how the S2R flow is expected to work in this specific case. Thanks, Lorenzo _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel