Message ID | 4789678.31r3eYUQgx@kreacher |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp894303wrr; Fri, 2 Dec 2022 06:35:55 -0800 (PST) X-Google-Smtp-Source: AA0mqf6T5xu5sD7LFKjLwaXGvpPhTVELjX0LDSskv1kMY9DK3S9JQW5HPqHlwBKzUcWraMN6c+9S X-Received: by 2002:a63:1d47:0:b0:46e:df6b:b87 with SMTP id d7-20020a631d47000000b0046edf6b0b87mr44330885pgm.540.1669991755075; Fri, 02 Dec 2022 06:35:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669991755; cv=none; d=google.com; s=arc-20160816; b=v/09kfJh0df/6+z4phsPOEzGy2Ld2hM0Oc0Julc8XOrRqHXSV8BSom6SIdqfvO5Y8s kxa5nYlY15TKllxTIYXGlDwdJBJiZHZxlM1bLCHS2jzFyPnH2w7fKIVbe/8dkHdItmcv NuVDmoDHcFwVatx4L6DoREIIu1gfbsyqXeCwtAiG1WbJjd8D6xQ3PBrkjdjxmPwdMjE9 vIS7ZIPQY6zbx4rvwUsuQB02/EQoleBJKWzRZ6mT+Os4eYkfmjfcq6gQXIEVE5LG/tyE yDLwSpz2SOkoId+7qun0EjjTsm7z/3Od9NJrZPIupvlBhXEcbk0SOPH+JM57l+0F6fhs LO9A== 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 :references:in-reply-to:message-id:date:subject:cc:to:from; bh=uYImmGz6c2BoRJMxsvQqO7u7u33JkfRH06waTIgLros=; b=eLtSe0ygX4XHQ9pQbeSDpPdyhDAe0pyh0Nomh2KjGC4AXK50+ITApGq8wPIimAssuR AIvFBi/sfDKL8006DgkGkx1WRG+mjrrmOKkJ6fZMia/z2HS2x+OhWU9g8NYmh/hff/yJ DxIUvqvKDWaDtszmnu1RZKrU2OJnHtVHHIsV7j//qDubpbvrqsGP5XoxBuOnl7Ih8kXS Kq1shTk/LAJI4/pF2Kwd5uD7kx3DGEYq5uAo3H6qaUUBl7PhO1mJP18ksb7/NUXI0NXV 8RLMc04Xn3RercNeLpXFpZL92T9XjVqAMZlZBaVoQIVCAYuGX5Qmxtd9mfIP9cKflxgO Vfdw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g21-20020a170902d1d500b00187337cb651si6683912plb.505.2022.12.02.06.35.40; Fri, 02 Dec 2022 06:35:55 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233470AbiLBOc3 (ORCPT <rfc822;lhua1029@gmail.com> + 99 others); Fri, 2 Dec 2022 09:32:29 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60344 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233172AbiLBOc1 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 2 Dec 2022 09:32:27 -0500 Received: from cloudserver094114.home.pl (cloudserver094114.home.pl [79.96.170.134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 90EC4DC852; Fri, 2 Dec 2022 06:32:26 -0800 (PST) Received: from localhost (127.0.0.1) (HELO v370.home.net.pl) by /usr/run/smtp (/usr/run/postfix/private/idea_relay_lmtp) via UNIX with SMTP (IdeaSmtpServer 5.1.0) id 260a5e6107349a30; Fri, 2 Dec 2022 15:32:25 +0100 Received: from kreacher.localnet (unknown [213.134.188.181]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by v370.home.net.pl (Postfix) with ESMTPSA id 0C9072602969; Fri, 2 Dec 2022 15:32:23 +0100 (CET) Authentication-Results: v370.home.net.pl; dmarc=none (p=none dis=none) header.from=rjwysocki.net Authentication-Results: v370.home.net.pl; spf=fail smtp.mailfrom=rjwysocki.net From: "Rafael J. Wysocki" <rjw@rjwysocki.net> To: Linux PM <linux-pm@vger.kernel.org> Cc: LKML <linux-kernel@vger.kernel.org>, Tushar Nimkar <quic_tnimkar@quicinc.com>, Adrian Hunter <adrian.hunter@intel.com>, "Rafael J. Wysocki" <rafael@kernel.org>, Nitin Rawat <quic_nitirawa@quicinc.com>, Peter Wang <peter.wang@mediatek.com>, Alan Stern <stern@rowland.harvard.edu>, Ulf Hansson <ulf.hansson@linaro.org> Subject: [PATCH v1 1/2] PM: runtime: Do not call __rpm_callback() from rpm_idle() Date: Fri, 02 Dec 2022 15:30:28 +0100 Message-ID: <4789678.31r3eYUQgx@kreacher> In-Reply-To: <5627469.DvuYhMxLoT@kreacher> References: <5627469.DvuYhMxLoT@kreacher> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" X-CLIENT-IP: 213.134.188.181 X-CLIENT-HOSTNAME: 213.134.188.181 X-VADE-SPAMSTATE: clean X-VADE-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvhedrtdekgdegvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfjqffogffrnfdpggftiffpkfenuceurghilhhouhhtmecuudehtdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkjghfggfgtgesthfuredttddtjeenucfhrhhomhepfdftrghfrggvlhculfdrucghhihsohgtkhhifdcuoehrjhifsehrjhifhihsohgtkhhirdhnvghtqeenucggtffrrghtthgvrhhnpedvffeuiedtgfdvtddugeeujedtffetteegfeekffdvfedttddtuefhgeefvdejhfenucfkphepvddufedrudefgedrudekkedrudekudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpedvudefrddufeegrddukeekrddukedupdhhvghlohepkhhrvggrtghhvghrrdhlohgtrghlnhgvthdpmhgrihhlfhhrohhmpedftfgrfhgrvghlucflrdcuhgihshhotghkihdfuceorhhjfiesrhhjfiihshhotghkihdrnhgvtheqpdhnsggprhgtphhtthhopeelpdhrtghpthhtoheplhhinhhugidqphhmsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtohepqhhuihgtpghtnhhimhhkrghrsehquhhitghinhgtrdgtohhmpdhrtghpthhtoheprggurhhirghnrdhhuhhnthgvrhesihhnthgvlhdrtghomhdprhgtphht thhopehrrghfrggvlheskhgvrhhnvghlrdhorhhgpdhrtghpthhtohepqhhuihgtpghnihhtihhrrgifrgesqhhuihgtihhntgdrtghomhdprhgtphhtthhopehpvghtvghrrdifrghnghesmhgvughirghtvghkrdgtohhmpdhrtghpthhtohepshhtvghrnhesrhhofihlrghnugdrhhgrrhhvrghrugdrvgguuhdprhgtphhtthhopehulhhfrdhhrghnshhsohhnsehlihhnrghrohdrohhrgh X-DCC--Metrics: v370.home.net.pl 1024; Body=9 Fuz1=9 Fuz2=9 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS autolearn=ham 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1751113274248350292?= X-GMAIL-MSGID: =?utf-8?q?1751113274248350292?= |
Series |
PM: runtime: Fix rpm_idle() and relocate rpm_callback()
|
|
Commit Message
Rafael J. Wysocki
Dec. 2, 2022, 2:30 p.m. UTC
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Calling __rpm_callback() from rpm_idle() after adding device links support to the former is a clear mistake. Not only it causes rpm_idle() to carry out unnecessary actions, but it is also against the assumption regarding the stability of PM-runtime status accross __rpm_callback() invocations, because rpm_suspend() and rpm_resume() may run in parallel with __rpm_callback() when it is called by rpm_idle() and the device's PM-runtime status can be updated by any of them. Fixes: 21d5c57b3726 ("PM / runtime: Use device links") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> --- drivers/base/power/runtime.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
Comments
On 2/12/22 16:30, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > Calling __rpm_callback() from rpm_idle() after adding device links > support to the former is a clear mistake. > > Not only it causes rpm_idle() to carry out unnecessary actions, but it > is also against the assumption regarding the stability of PM-runtime > status accross __rpm_callback() invocations, because rpm_suspend() and accross -> across > rpm_resume() may run in parallel with __rpm_callback() when it is called > by rpm_idle() and the device's PM-runtime status can be updated by any > of them. > > Fixes: 21d5c57b3726 ("PM / runtime: Use device links") Reviewed-by: Adrian Hunter <adrian.hunter@intel.com> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > --- > drivers/base/power/runtime.c | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > Index: linux-pm/drivers/base/power/runtime.c > =================================================================== > --- linux-pm.orig/drivers/base/power/runtime.c > +++ linux-pm/drivers/base/power/runtime.c > @@ -484,7 +484,17 @@ static int rpm_idle(struct device *dev, > > dev->power.idle_notification = true; > > - retval = __rpm_callback(callback, dev); > + if (dev->power.irq_safe) > + spin_unlock(&dev->power.lock); > + else > + spin_unlock_irq(&dev->power.lock); > + > + retval = callback(dev); > + > + if (dev->power.irq_safe) > + spin_lock(&dev->power.lock); > + else > + spin_lock_irq(&dev->power.lock); > > dev->power.idle_notification = false; > wake_up_all(&dev->power.wait_queue); > > >
On Fri, 2 Dec 2022 at 15:32, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > Calling __rpm_callback() from rpm_idle() after adding device links > support to the former is a clear mistake. > > Not only it causes rpm_idle() to carry out unnecessary actions, but it > is also against the assumption regarding the stability of PM-runtime > status accross __rpm_callback() invocations, because rpm_suspend() and > rpm_resume() may run in parallel with __rpm_callback() when it is called > by rpm_idle() and the device's PM-runtime status can be updated by any > of them. Urgh, that's a nasty bug you are fixing here. Is there perhaps some links to some error reports that can make sense to include here? > > Fixes: 21d5c57b3726 ("PM / runtime: Use device links") > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > --- > drivers/base/power/runtime.c | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > Index: linux-pm/drivers/base/power/runtime.c > =================================================================== > --- linux-pm.orig/drivers/base/power/runtime.c > +++ linux-pm/drivers/base/power/runtime.c > @@ -484,7 +484,17 @@ static int rpm_idle(struct device *dev, > > dev->power.idle_notification = true; > > - retval = __rpm_callback(callback, dev); Couldn't we just extend __rpm_callback() to take another in-parameter, rather than open-coding the below? Note that, __rpm_callback() already uses a "bool use_links" internal variable, that indicates whether the device links should be used or not. > + if (dev->power.irq_safe) > + spin_unlock(&dev->power.lock); > + else > + spin_unlock_irq(&dev->power.lock); > + > + retval = callback(dev); > + > + if (dev->power.irq_safe) > + spin_lock(&dev->power.lock); > + else > + spin_lock_irq(&dev->power.lock); > > dev->power.idle_notification = false; > wake_up_all(&dev->power.wait_queue); > > > Kind regards Uffe
On Mon, Dec 5, 2022 at 1:08 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > On Fri, 2 Dec 2022 at 15:32, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > > > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > > Calling __rpm_callback() from rpm_idle() after adding device links > > support to the former is a clear mistake. > > > > Not only it causes rpm_idle() to carry out unnecessary actions, but it > > is also against the assumption regarding the stability of PM-runtime > > status accross __rpm_callback() invocations, because rpm_suspend() and > > rpm_resume() may run in parallel with __rpm_callback() when it is called > > by rpm_idle() and the device's PM-runtime status can be updated by any > > of them. > > Urgh, that's a nasty bug you are fixing here. Is there perhaps some > links to some error reports that can make sense to include here? There is a bug report, but I have no confirmation that this fix is sufficient to address it (even though I'm quite confident that it will be). > > > > Fixes: 21d5c57b3726 ("PM / runtime: Use device links") > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > --- > > drivers/base/power/runtime.c | 12 +++++++++++- > > 1 file changed, 11 insertions(+), 1 deletion(-) > > > > Index: linux-pm/drivers/base/power/runtime.c > > =================================================================== > > --- linux-pm.orig/drivers/base/power/runtime.c > > +++ linux-pm/drivers/base/power/runtime.c > > @@ -484,7 +484,17 @@ static int rpm_idle(struct device *dev, > > > > dev->power.idle_notification = true; > > > > - retval = __rpm_callback(callback, dev); > > Couldn't we just extend __rpm_callback() to take another in-parameter, > rather than open-coding the below? I'd rather not do that. I'd prefer rpm_callback() to be used only in rpm_suspend() and rpm_resume() where all of the assumptions hold and rpm_idle() really is a special case. And there is not much open-coding here, just the locking part. > Note that, __rpm_callback() already uses a "bool use_links" internal > variable, that indicates whether the device links should be used or > not. Yes, it does, but why does that matter? > > + if (dev->power.irq_safe) > > + spin_unlock(&dev->power.lock); > > + else > > + spin_unlock_irq(&dev->power.lock); > > + > > + retval = callback(dev); > > + > > + if (dev->power.irq_safe) > > + spin_lock(&dev->power.lock); > > + else > > + spin_lock_irq(&dev->power.lock); > > > > dev->power.idle_notification = false; > > wake_up_all(&dev->power.wait_queue); > > > > > >
On Mon, 5 Dec 2022 at 13:13, Rafael J. Wysocki <rafael@kernel.org> wrote: > > On Mon, Dec 5, 2022 at 1:08 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > > > On Fri, 2 Dec 2022 at 15:32, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > > > > > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > > > > Calling __rpm_callback() from rpm_idle() after adding device links > > > support to the former is a clear mistake. > > > > > > Not only it causes rpm_idle() to carry out unnecessary actions, but it > > > is also against the assumption regarding the stability of PM-runtime > > > status accross __rpm_callback() invocations, because rpm_suspend() and > > > rpm_resume() may run in parallel with __rpm_callback() when it is called > > > by rpm_idle() and the device's PM-runtime status can be updated by any > > > of them. > > > > Urgh, that's a nasty bug you are fixing here. Is there perhaps some > > links to some error reports that can make sense to include here? > > There is a bug report, but I have no confirmation that this fix is > sufficient to address it (even though I'm quite confident that it will > be). > > > > > > > Fixes: 21d5c57b3726 ("PM / runtime: Use device links") > > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > --- > > > drivers/base/power/runtime.c | 12 +++++++++++- > > > 1 file changed, 11 insertions(+), 1 deletion(-) > > > > > > Index: linux-pm/drivers/base/power/runtime.c > > > =================================================================== > > > --- linux-pm.orig/drivers/base/power/runtime.c > > > +++ linux-pm/drivers/base/power/runtime.c > > > @@ -484,7 +484,17 @@ static int rpm_idle(struct device *dev, > > > > > > dev->power.idle_notification = true; > > > > > > - retval = __rpm_callback(callback, dev); > > > > Couldn't we just extend __rpm_callback() to take another in-parameter, > > rather than open-coding the below? > > I'd rather not do that. > > I'd prefer rpm_callback() to be used only in rpm_suspend() and > rpm_resume() where all of the assumptions hold and rpm_idle() really > is a special case. > > And there is not much open-coding here, just the locking part. That and the actual call to the callback. Not much, but still. > > > Note that, __rpm_callback() already uses a "bool use_links" internal > > variable, that indicates whether the device links should be used or > > not. > > Yes, it does, but why does that matter? It means that __rpm_callback() is already prepared to (almost) cover this case. > > > > + if (dev->power.irq_safe) > > > + spin_unlock(&dev->power.lock); > > > + else > > > + spin_unlock_irq(&dev->power.lock); > > > + > > > + retval = callback(dev); > > > + > > > + if (dev->power.irq_safe) > > > + spin_lock(&dev->power.lock); > > > + else > > > + spin_lock_irq(&dev->power.lock); > > > > > > dev->power.idle_notification = false; > > > wake_up_all(&dev->power.wait_queue); > > > > > > > > > Note, it's not a big deal to me, if you feel strongly that your current approach is better, I am fine with that too. Kind regards Uffe
On Mon, Dec 5, 2022 at 1:47 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > On Mon, 5 Dec 2022 at 13:13, Rafael J. Wysocki <rafael@kernel.org> wrote: > > > > On Mon, Dec 5, 2022 at 1:08 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > > > > > On Fri, 2 Dec 2022 at 15:32, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > > > > > > > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > > > > > > Calling __rpm_callback() from rpm_idle() after adding device links > > > > support to the former is a clear mistake. > > > > > > > > Not only it causes rpm_idle() to carry out unnecessary actions, but it > > > > is also against the assumption regarding the stability of PM-runtime > > > > status accross __rpm_callback() invocations, because rpm_suspend() and > > > > rpm_resume() may run in parallel with __rpm_callback() when it is called > > > > by rpm_idle() and the device's PM-runtime status can be updated by any > > > > of them. > > > > > > Urgh, that's a nasty bug you are fixing here. Is there perhaps some > > > links to some error reports that can make sense to include here? > > > > There is a bug report, but I have no confirmation that this fix is > > sufficient to address it (even though I'm quite confident that it will > > be). > > > > > > > > > > Fixes: 21d5c57b3726 ("PM / runtime: Use device links") > > > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > > --- > > > > drivers/base/power/runtime.c | 12 +++++++++++- > > > > 1 file changed, 11 insertions(+), 1 deletion(-) > > > > > > > > Index: linux-pm/drivers/base/power/runtime.c > > > > =================================================================== > > > > --- linux-pm.orig/drivers/base/power/runtime.c > > > > +++ linux-pm/drivers/base/power/runtime.c > > > > @@ -484,7 +484,17 @@ static int rpm_idle(struct device *dev, > > > > > > > > dev->power.idle_notification = true; > > > > > > > > - retval = __rpm_callback(callback, dev); > > > > > > Couldn't we just extend __rpm_callback() to take another in-parameter, > > > rather than open-coding the below? > > > > I'd rather not do that. > > > > I'd prefer rpm_callback() to be used only in rpm_suspend() and > > rpm_resume() where all of the assumptions hold and rpm_idle() really > > is a special case. > > > > And there is not much open-coding here, just the locking part. > > That and the actual call to the callback. Not much, but still. Note that it doesn't need to check the callback pointer, though. Moreover, IMO this code is easier to read without having to look at __rpm_callback() and reverse engineer all of the different use cases covered by it. > > > Note that, __rpm_callback() already uses a "bool use_links" internal > > > variable, that indicates whether the device links should be used or > > > not. > > > > Yes, it does, but why does that matter? > > It means that __rpm_callback() is already prepared to (almost) cover this case. Well, why does it have to cover all of the cases that are even somewhat related? > > > > > > + if (dev->power.irq_safe) > > > > + spin_unlock(&dev->power.lock); > > > > + else > > > > + spin_unlock_irq(&dev->power.lock); > > > > + > > > > + retval = callback(dev); > > > > + > > > > + if (dev->power.irq_safe) > > > > + spin_lock(&dev->power.lock); > > > > + else > > > > + spin_lock_irq(&dev->power.lock); > > > > > > > > dev->power.idle_notification = false; > > > > wake_up_all(&dev->power.wait_queue); > > > > > > > > > > > > > > Note, it's not a big deal to me, if you feel strongly that your > current approach is better, I am fine with that too. OK, thanks!
On Mon, Dec 5, 2022 at 8:45 AM Adrian Hunter <adrian.hunter@intel.com> wrote: > > On 2/12/22 16:30, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > > Calling __rpm_callback() from rpm_idle() after adding device links > > support to the former is a clear mistake. > > > > Not only it causes rpm_idle() to carry out unnecessary actions, but it > > is also against the assumption regarding the stability of PM-runtime > > status accross __rpm_callback() invocations, because rpm_suspend() and > > accross -> across Fixed whey applying the patch. > > rpm_resume() may run in parallel with __rpm_callback() when it is called > > by rpm_idle() and the device's PM-runtime status can be updated by any > > of them. > > > > Fixes: 21d5c57b3726 ("PM / runtime: Use device links") > > Reviewed-by: Adrian Hunter <adrian.hunter@intel.com> Thank you! > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > --- > > drivers/base/power/runtime.c | 12 +++++++++++- > > 1 file changed, 11 insertions(+), 1 deletion(-) > > > > Index: linux-pm/drivers/base/power/runtime.c > > =================================================================== > > --- linux-pm.orig/drivers/base/power/runtime.c > > +++ linux-pm/drivers/base/power/runtime.c > > @@ -484,7 +484,17 @@ static int rpm_idle(struct device *dev, > > > > dev->power.idle_notification = true; > > > > - retval = __rpm_callback(callback, dev); > > + if (dev->power.irq_safe) > > + spin_unlock(&dev->power.lock); > > + else > > + spin_unlock_irq(&dev->power.lock); > > + > > + retval = callback(dev); > > + > > + if (dev->power.irq_safe) > > + spin_lock(&dev->power.lock); > > + else > > + spin_lock_irq(&dev->power.lock); > > > > dev->power.idle_notification = false; > > wake_up_all(&dev->power.wait_queue); > > > > > > >
Index: linux-pm/drivers/base/power/runtime.c =================================================================== --- linux-pm.orig/drivers/base/power/runtime.c +++ linux-pm/drivers/base/power/runtime.c @@ -484,7 +484,17 @@ static int rpm_idle(struct device *dev, dev->power.idle_notification = true; - retval = __rpm_callback(callback, dev); + if (dev->power.irq_safe) + spin_unlock(&dev->power.lock); + else + spin_unlock_irq(&dev->power.lock); + + retval = callback(dev); + + if (dev->power.irq_safe) + spin_lock(&dev->power.lock); + else + spin_lock_irq(&dev->power.lock); dev->power.idle_notification = false; wake_up_all(&dev->power.wait_queue);