Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp5645952yba; Thu, 11 Apr 2019 02:40:27 -0700 (PDT) X-Google-Smtp-Source: APXvYqzu6AzrD7j/mrOGKzC5bitzAJUtDJ1W3SimlzS8hF0ordD1ODPHI+dRXHLu9/YpcP8NOl3T X-Received: by 2002:a63:41c4:: with SMTP id o187mr46361965pga.73.1554975627109; Thu, 11 Apr 2019 02:40:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554975627; cv=none; d=google.com; s=arc-20160816; b=GJMe3HOoeysn1kb1FBnWsR7IaV3n/fBIsURAkvCWMjMNZTDbtGiP+Gos6ZZMQtXTbx ZBKNa1yjgAfWvjmQNaa9jvAp2p2/RnbNlGanj9gasi0OSWkzjATiKyjiM6evXtBSQES+ lie85Q5SdpLn7mEV/OiFiJnfE5v7hqpH2eaHZHzf5uo8DX6ERPrc1TcBq7nTBSYlGtTy gPpgf4dLVLRZZE3su6z7HqwooEDmhtl1EFg3Eaolz6wm/azvuU9IqTMVy+RZA8UjRmsC ypY/W1RIGqkrnJdaZQz0EmnwJm18LrfDZu8jrMGGTUfirQsna0S+7cL3RqSGlBHAvpgE 6s1g== 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 :in-reply-to:references:mime-version:dkim-signature; bh=E0RUi/kejPKZCj7BHFvrKKp1MxUL0gG7xD1zAO9nQbI=; b=I1JCk1ySt5VkhZzfX55KSX5AJFqSK3uMfpawX5bYPbrtXjlkLLFvPjj/M8Bj78WPKR MpUlOppnmgHvZUYN7MTghuDW9qp+au5J/BQvqYI+WSvuJz7I6XoONY0Zl/tQMaZbScJe omo9jsc19mhYehc0IUbPdxvSXKbPyL3t5y2RWKnk22FZvHvyXrqVovqlMrpY9M43WwKR pE8hV74Nc40YcKO4uucCaZbGAva+4qrOi2YqArBaAsNal9QYwjad77F5i2dEV1hm+AZc tb5x45OKr9TBaEdwdByyYUDhcLb/yAFq0JVHwgNwxfA4V77y8SlypRXt1Kl6Zy0MTlAX 6z9A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=yverb6g6; 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 b23si33521086pgn.422.2019.04.11.02.40.11; Thu, 11 Apr 2019 02:40:27 -0700 (PDT) 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=yverb6g6; 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 S1727214AbfDKJhi (ORCPT + 99 others); Thu, 11 Apr 2019 05:37:38 -0400 Received: from mail-vs1-f67.google.com ([209.85.217.67]:42099 "EHLO mail-vs1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726264AbfDKJhW (ORCPT ); Thu, 11 Apr 2019 05:37:22 -0400 Received: by mail-vs1-f67.google.com with SMTP id f15so3085771vsk.9 for ; Thu, 11 Apr 2019 02:37:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=E0RUi/kejPKZCj7BHFvrKKp1MxUL0gG7xD1zAO9nQbI=; b=yverb6g6sUZ/FDWwIrwhwTZBN+oqv1lvXZbYBCzakMNcb44LfLjJaBhnr6/r9Ot5hS T1MT4KDmD9Ge2eXLtcFw4NW7n7/plIx82oms0G3JOUX3IAiZERPpMYZAbpLZ7qfMBdGp hkQw2GAAlI2Vg4B+u9rcxBFzCAefVoIaFrko6Gin9JaS7Ugr5940uuf8Qy3eGbV5obxd ca0K8ZyEivfI3EjulkPMapY4gCfsHn5NauN3Xy+fyjxeSkKv9DQ7yIIaBSQvgT5wOL5a e1ygwiZpB7SNp/5azdCDVuqBZO5pI1GXbCEoI+L5PGeMMSXYQDXWaI/y6S5UlzbZcJLA yD/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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=E0RUi/kejPKZCj7BHFvrKKp1MxUL0gG7xD1zAO9nQbI=; b=ppidnM4qPjGF+7TVa/dp+LbZir/+zeIghrn/oYpUU4YRxETfnYURVn1AXiOcuR2TC/ PgSFDK6AlaZhJCeVONdRr2seJoBvzS8ERIi4xLe+RlWAcpCKgNBdfcuXcQQNeI9ur+DT ucmgGRNAl6f3qbQrOxnarFlBRrNz3MVN0kShWH8T8jItwinQFbE6psiDkZEjkO4NDU59 q52nLSBvKQAhMdoOo9+7mmF+HNc55hCCztMLYpvNV0HJwMQkSzSw/hmq3x56g6UL8Jxy x4z6HGstovAc7Gxp50UMf09RLsr1Sx7Dbgh1fQoodYEBJrL+dVSjt38NeeDtJQlukocH e9Ig== X-Gm-Message-State: APjAAAVtabEeC+hHkWNIIzX/RkzOj6Ks00jdJmMsLD2ehdG4cWWFLOKL 9QV3bC6v2f1csKBysfFo/WFGvWMTMKGQbV35zex7cw== X-Received: by 2002:a67:2e8c:: with SMTP id u134mr27000829vsu.57.1554975441619; Thu, 11 Apr 2019 02:37:21 -0700 (PDT) MIME-Version: 1.0 References: <1554606804-29453-1-git-send-email-hofrat@opentech.at> In-Reply-To: <1554606804-29453-1-git-send-email-hofrat@opentech.at> From: Ulf Hansson Date: Thu, 11 Apr 2019 11:36:45 +0200 Message-ID: Subject: Re: [PATCH RFC] clk: ux500: add range to usleep_range To: Nicholas Mc Guire Cc: Michael Turquette , Stephen Boyd , Linux ARM , linux-clk , 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 Sun, 7 Apr 2019 at 05:13, Nicholas Mc Guire wrote: > > Providing a range for usleep_range() allows the hrtimer subsystem to > coalesce timers - the delay is runtime configurable so a factor 2 > is taken to provide the range. > > Signed-off-by: Nicholas Mc Guire > --- > > Problem located with an experimental coccinelle script > > Q: Basically usleep_range() with min == max never makes much sense notably > in non-atomic context. If the factor of 2 is tolerable or a fixed > offset of e.g. 1000 would be more suitable is not clear to me - maybe > someone familiar with that driver can clarify this. > > Patch was compile tested with: u8500_defconfig (implies COMMON_CLK=y) > (with some sparse warnings about not implemented system calls) > > Patch is against 5.1-rc3 (localversion-next is next=20190405) > > drivers/clk/ux500/clk-sysctrl.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/clk/ux500/clk-sysctrl.c b/drivers/clk/ux500/clk-sysctrl.c > index 7c0403b..a1fa3fb 100644 > --- a/drivers/clk/ux500/clk-sysctrl.c > +++ b/drivers/clk/ux500/clk-sysctrl.c > @@ -42,7 +42,7 @@ static int clk_sysctrl_prepare(struct clk_hw *hw) > clk->reg_bits[0]); > > if (!ret && clk->enable_delay_us) > - usleep_range(clk->enable_delay_us, clk->enable_delay_us); > + usleep_range(clk->enable_delay_us, clk->enable_delay_us*2); The range being used is actually in ms, so not sure we actually need to double it for the range. How about adding ~25% instead, along the lines of below: usleep_range(clk->enable_delay_us, clk->enable_delay_us + (clk->enable_delay_us >> 2)); Kind regards Uffe