Received: by 10.223.185.116 with SMTP id b49csp2392455wrg; Mon, 12 Feb 2018 08:51:13 -0800 (PST) X-Google-Smtp-Source: AH8x224DfX1fcRXQbWmhhE5qYPgoHGAnknG5v7nzCaRUkDqwvV/FhYRCCq2a2UqXTg7oNygoer+g X-Received: by 10.98.66.86 with SMTP id p83mr12215221pfa.229.1518454273233; Mon, 12 Feb 2018 08:51:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518454273; cv=none; d=google.com; s=arc-20160816; b=CTqUaoE6KEsiBTo9fxqK6uqxC3PdngNG//yAv2ddMvq/zKhqTB15qY9X2TGnusxDgq 9FLGx28RG5RlsDQ2bwwiXv5YGxYtjrmw4JDuN94LTiKFD/HdrC8AiFFlVzhrbZxGl3OP szhgeIiCZimPFr5bGvoT8aHggai9nhVgks1rmq0K58T8+1y8gGAuxKvAEfGDgsqSPKFy FFnyuAHbiXrkUjWv8+0yq8wy7o04Y4x3ALHuSpEcIAw6CPLULT5G8GiCdfhByE3eGLmn guVo2FUJSuEVw/rj8SKx58FQ2Cnm8GHGpVSATjajHLI30c/tk2kxu+7YKYGZwRIJa5Og p//Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=L9eVk3z5QizEAcSEd5vblAwHxyjDXg0Y9mgfHUR4xMo=; b=kWx4TM0Zul/jsiuVkuVwDMsLuFo7EhZcIZVkkaahz/MRc6ucuecRBLj8qY6SZlCGOT 2w+ibZRq7Fwpj8PPl2H93KlwYJQCfjwQ6yxeF/4OMJ1A15fq8g1q/BIyaVx+c1ZnaE7G 1TZjEUTsID209QEmtXNSYIXmGl9lZotKWxZ5oDFUle4UUs+0mNkMIRiy4CcpXtWoFEwN 7QvJZILA5iKaAgadjbzTpLBPTMfDvq4ElS9D1rxK3MdBgY199QxeOd5Za/LUajZNU08y uEx+X0+Cddwbb3mLmPz99w+W1FHKa12xz3jvGbtb1/xHrFg1hmJfurFfTh7bOYNZiJuz fLmA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=RsU7LUV4; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b127si373989pgc.220.2018.02.12.08.50.58; Mon, 12 Feb 2018 08:51:13 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=RsU7LUV4; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934664AbeBLMkz (ORCPT + 99 others); Mon, 12 Feb 2018 07:40:55 -0500 Received: from mail-it0-f66.google.com ([209.85.214.66]:36342 "EHLO mail-it0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933359AbeBLMky (ORCPT ); Mon, 12 Feb 2018 07:40:54 -0500 Received: by mail-it0-f66.google.com with SMTP id n206so6317282itg.1 for ; Mon, 12 Feb 2018 04:40:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=L9eVk3z5QizEAcSEd5vblAwHxyjDXg0Y9mgfHUR4xMo=; b=RsU7LUV4tfdXeHbmyHca5ZBQakQIPmgBl+NmqXsA+FX2+jLy+kPQrRCve5rmI54Dyd Lb1AZo0QHJdNfKuKRv8U/tyYgSUSoJvswKIzwO3nwEO0dncCoIYVII+MuzlmFIa0vp0T zmsHKLOPqK3dA4rMokl/b8DCwrbC2SEU1wh+g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=L9eVk3z5QizEAcSEd5vblAwHxyjDXg0Y9mgfHUR4xMo=; b=Jl+7B9i2LMFLUliA2SAeGxpoO6fEjz4oVPhqdGYguI+E4d5fWVZO+7J2C79rpf9mSH Qv+PqHMlPpTCAs7CKvFX7Q4ipMqccL3VyH+7BR1/SxkDkZ99koRvfwQBAXRRv4EztFJ4 K7Kn2a7/YmNOrpRtIMlewyE+Lsg8wuoywbM61ffiFWPisSWdNDSEdlvP12kaZRSKilgK gXgOY039WZTofcVMuluWMeAOcdckr89Qom4svH4fVdzye5Goft19oSYYVTdielN651W4 MCPs4NytPgXQWmWP8URrS7lBCUkPlvqeVtS8YloVDle6B5VdJw6pNPXJdcE9fYZFyaZz B7Ww== X-Gm-Message-State: APf1xPBUdPPfVY991jw+mjMGJP+TA/Kp69Pr+wudmE90Yp7vc3J+RB+a ZCR8q5Sk9GSQ1TdR7PN2p0kNDKQrruX09NH8io/Ujw== X-Received: by 10.36.47.137 with SMTP id j131mr1076682itj.22.1518439253421; Mon, 12 Feb 2018 04:40:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.91.10 with HTTP; Mon, 12 Feb 2018 04:40:52 -0800 (PST) In-Reply-To: <1518431893.2744.1.camel@pengutronix.de> References: <1516955899-31810-1-git-send-email-baijiaju1990@gmail.com> <1518431893.2744.1.camel@pengutronix.de> From: Ulf Hansson Date: Mon, 12 Feb 2018 13:40:52 +0100 Message-ID: Subject: Re: [PATCH] base: power: domain: Replace mdelay with msleep To: Lucas Stach Cc: Jia-Ju Bai , "Rafael J. Wysocki" , Kevin Hilman , Len Brown , Pavel Machek , Greg Kroah-Hartman , Linux PM , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12 February 2018 at 11:38, Lucas Stach wrote: > Am Freitag, den 09.02.2018, 14:58 +0100 schrieb Ulf Hansson: >> On 26 January 2018 at 09:38, Jia-Ju Bai >> wrote: >> > After checking all possible call chains to genpd_dev_pm_detach() >> > and >> > genpd_dev_pm_attach() here, >> > my tool finds that these functions are never called in atomic >> > context, >> > namely never in an interrupt handler or holding a spinlock. >> > Thus mdelay can be replaced with msleep to avoid busy wait. >> > >> > This is found by a static analysis tool named DCNS written by >> > myself. >> > >> > Signed-off-by: Jia-Ju Bai >> > --- >> > drivers/base/power/domain.c | 4 ++-- >> > 1 file changed, 2 insertions(+), 2 deletions(-) >> > >> > diff --git a/drivers/base/power/domain.c >> > b/drivers/base/power/domain.c >> > index 0c80bea..f84ac72 100644 >> > --- a/drivers/base/power/domain.c >> > +++ b/drivers/base/power/domain.c >> > @@ -2144,7 +2144,7 @@ static void genpd_dev_pm_detach(struct device >> > *dev, bool power_off) >> > if (ret != -EAGAIN) >> > break; >> > >> > - mdelay(i); >> > + msleep(i); >> >> This looks like a nice improvement, however moving to msleep() makes >> the call to cond_resched() below a bit superfluous. Perhaps remove >> that as well. > > At least for small values of i, msleep also has a high chance to > overshoot the desired sleep by a lot. It would be better to convert > them to usleep_range with an acceptable slack. Ack! [...] Kind regards Uffe