From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932389AbbFGIbs (ORCPT ); Sun, 7 Jun 2015 04:31:48 -0400 Received: from hofr.at ([212.69.189.236]:47765 "EHLO mail.hofr.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751152AbbFGIbj (ORCPT ); Sun, 7 Jun 2015 04:31:39 -0400 Date: Sun, 7 Jun 2015 10:31:37 +0200 From: Nicholas Mc Guire To: David Miller Cc: hofrat@osadl.org, romieu@fr.zoreil.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] wan: dscc4: use msecs_to_jiffies for conversions Message-ID: <20150607083137.GB9670@opentech.at> References: <1433580066-1237-1-git-send-email-hofrat@osadl.org> <20150607.001351.1615444562432115091.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150607.001351.1615444562432115091.davem@davemloft.net> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 07 Jun 2015, David Miller wrote: > From: Nicholas Mc Guire > Date: Sat, 6 Jun 2015 10:41:06 +0200 > > > API compliance scanning with coccinelle flagged: > > ./drivers/net/wan/dscc4.c:1036:1-33: > > WARNING: timeout (10) seems HZ dependent > > ./drivers/net/wan/dscc4.c:554:2-34: > > WARNING: timeout (10) seems HZ dependent > > ./drivers/net/wan/dscc4.c:599:2-34: > > WARNING: timeout (10) seems HZ dependent > > > > Numeric constants passed to schedule_timeout_*() make the effective > > timeout HZ dependent which does not seem to be the intent here. > > Fixed up by converting the constant to jiffies with msecs_to_jiffies() > > > > Signed-off-by: Nicholas Mc Guire > > Whoever wrote these things probably wanted whatever this amounts > to when HZ=100, so that is the only valid transformation you can > make to fix this up here. > > Otherwise you seriously risk breaking the driver. I did not find dscc4 in the 2.2 series of kernels so it does not predate configurable HZ - or do you mean simply that increasing the timeout here should be side-effect free and thus the larger of the values should be taken ? - though that would imply that it is possibly now broken for HZ=1000. Will fix it up to 10 == 100ms and fix the patch documentation. thx! hofrat