From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S377163AbdD2XdS (ORCPT ); Sat, 29 Apr 2017 19:33:18 -0400 Received: from host.buserror.net ([209.198.135.123]:47854 "EHLO host.buserror.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753382AbdD2XdL (ORCPT ); Sat, 29 Apr 2017 19:33:11 -0400 Message-ID: <1493508775.25397.26.camel@buserror.net> From: Scott Wood To: Karim Eshapa Cc: claudiu.manoil@nxp.com, roy.pledge@nxp.com, colin.king@canonical.com, linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Date: Sat, 29 Apr 2017 18:32:55 -0500 In-Reply-To: <1493498620-9975-1-git-send-email-karim.eshapa@gmail.com> References: <1493495164-8658-1-git-send-email-karim.eshapa@gmail.com> <1493498620-9975-1-git-send-email-karim.eshapa@gmail.com> Organization: NXP Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6-1ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 50.171.225.118 X-SA-Exim-Rcpt-To: karim.eshapa@gmail.com, claudiu.manoil@nxp.com, roy.pledge@nxp.com, colin.king@canonical.com, linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: oss@buserror.net X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * -15 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -1.5 GREYLIST_ISWHITE The incoming server has been whitelisted for this * recipient and sender Subject: Re: [PATCH] drivers:soc:fsl:qbman:qman.c: unsigned long jiffies value. X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:57:07 +0000) X-SA-Exim-Scanned: Yes (on host.buserror.net) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 2017-04-29 at 22:43 +0200, Karim Eshapa wrote: > unsigned long jiffies value sorry for that. You mean unsigned long msecs? > > Signed-off-by: Karim Eshapa > --- >  drivers/soc/fsl/qbman/qman.c | 2 +- >  1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/soc/fsl/qbman/qman.c b/drivers/soc/fsl/qbman/qman.c > index e0df4d1..6e1a44a 100644 > --- a/drivers/soc/fsl/qbman/qman.c > +++ b/drivers/soc/fsl/qbman/qman.c > @@ -1084,7 +1084,7 @@ static int drain_mr_fqrni(struct qm_portal *p) >    * entries well before the ring has been fully consumed, so >    * we're being *really* paranoid here. >    */ > - unsigned int udel_time = jiffies_to_usecs(10000); > + unsigned long udel_time = jiffies_to_usecs(10000); >   >   usleep_range(udel_time/2, udel_time); >   msg = qm_mr_current(p); If unsigned int isn't big enough, then unsigned long won't be either on 32- bit. With such a long delay why not use msleep()? As for the previous patch[1], you're halving the minimum timeout which may not be correct. For the NXP people: Is there *really* no better way to handle this than waiting for so long? Nothing that can be checked to exit the loop early (at least, you could exit early if there is more work to do so only the final iteration takes the full timeout)? And why is the desired timeout specified in jiffies, the duration of which can change based on kernel config and doesn't reflect anything about the hardware? -Scott [1] When fixing a patch you've already posted that hasn't yet been applied, send a replacement (v2) patch rather than a separate fix.