Message ID | Y1r4EaDvEipzhaaf@ubunlion |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp470074wru; Thu, 27 Oct 2022 14:45:22 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7ulYxkPdLCaynuNyIln2jeaSF9qaP5TwCNaNxq6Gwa9w0mXx9uVVO7v+P667Hq9VVvgpr1 X-Received: by 2002:a17:906:2699:b0:781:a473:9791 with SMTP id t25-20020a170906269900b00781a4739791mr44328289ejc.644.1666907121815; Thu, 27 Oct 2022 14:45:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666907121; cv=none; d=google.com; s=arc-20160816; b=rDuJFqKqjr/YM+LWKfMaVy1L/p1yvR4Am0zkjvXNqJrjW5KE2HkRFXbzguTfAAetpP ImApbDgaiaAO4+tFcuQrT2TpwAulY+CN3GcToY/slFe0L6eeIj9xnza4kC3u3tJWRaJB v8380JdbBNtIUlFpH/Rq76PmH5alsQLmnODYrUt498gMEePhPoYKpEoRvgvwn4nxFI4U IBim6EhxjC9HCNKxfQBY2avEwXQPnAvkd91IdzpbZyc50dETDQ67yCTau1kxH43FNnrV Zk1JMSJrRacit9UFQlGWbqpJyXoesS0M01JCf6vVopBNTGQaWuA8p4kwnICFjOAL6mIQ BY5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-disposition:mime-version:message-id :subject:to:from:date:dkim-signature; bh=QhpIO46Kz66wB3dZFNtUG506n/HwFaBdF0zUpx9ZgCk=; b=UadpyzMFEA/7OWPBAaPVAXRFuuuRwUBrvbJLycXDjtpivJnTfRS6W9hJRs5AoRdlfI yJMvOaLaIxGy98sui6TMCQAFye5AbcAVLfMmx6VTYHlNDeRLeSeYeqkd8onPTAt21CUh xw+cvKqJv+bs1Dpg4AnvD5nPPBTG5unv9DSYq1ghrzs9xRGAhMYWVn8FOGuusYNI8tth 3Zzj/dpanOaNeqKThjSkGmHB2RqiFcKt274qvGKnIsjULKw8C+JEyFJdjNswJzZgMAQp J1M6lXOQAA2blK1hdzCo1WcOH4LTl7qdfjr87bwQD/1Dt0gqgN+u0Z2eziuRAsA3Wl0z 7aHw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@mailo.com header.s=mailo header.b=pKtWuCzh; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mailo.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ss3-20020a170907c00300b00780e022dfb8si2187199ejc.494.2022.10.27.14.44.57; Thu, 27 Oct 2022 14:45:21 -0700 (PDT) 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; dkim=fail header.i=@mailo.com header.s=mailo header.b=pKtWuCzh; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mailo.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236668AbiJ0V3e (ORCPT <rfc822;chrisfriedt@gmail.com> + 99 others); Thu, 27 Oct 2022 17:29:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54846 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236551AbiJ0V3c (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 27 Oct 2022 17:29:32 -0400 Received: from msg-1.mailo.com (msg-1.mailo.com [213.182.54.11]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4F1B76352; Thu, 27 Oct 2022 14:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mailo.com; s=mailo; t=1666906136; bh=OOdVohmxjyqwES6BVgivansb/UtVz9aFP/lWyrNnjg8=; h=X-EA-Auth:Date:From:To:Subject:Message-ID:MIME-Version: Content-Type; b=pKtWuCzhbBIk1PM0LhtiIxTshU6xE/iTaortghI75CbomsIrhKFsHXQw8TQumY9L5 k2qAe37H/A9uZuvnnIM1JRkFeMIpLbCz8vO5wju6oIi2Kmp++bZOsRqacSYC80WEIw UZdceXgXv6uxSJC/GqSsOwPvuKGDe6+CaF9SGvF4= Received: by b-2.in.mailobj.net [192.168.90.12] with ESMTP via [213.182.55.206] Thu, 27 Oct 2022 23:28:56 +0200 (CEST) X-EA-Auth: 12GbF3MYEzhNl3lHw/2UILN1hYg3324yD/EbSHxll6FcVpG2POaqfvUrBwf5K3X6yPxM/38dmvXLCKbUsrRha4lx6gNTmkx5 Date: Fri, 28 Oct 2022 02:58:49 +0530 From: Deepak R Varma <drv@mailo.com> To: outreachy@lists.linux.dev, Lars-Peter Clausen <lars@metafoo.de>, Michael Hennerich <Michael.Hennerich@analog.com>, Jonathan Cameron <jic23@kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, linux-iio@vger.kernel.org, linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH] staging: iio: ad5933: Use div64_ul instead of do_div Message-ID: <Y1r4EaDvEipzhaaf@ubunlion> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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?1747878802331596548?= X-GMAIL-MSGID: =?utf-8?q?1747878802331596548?= |
Series |
staging: iio: ad5933: Use div64_ul instead of do_div
|
|
Commit Message
Deepak R Varma
Oct. 27, 2022, 9:28 p.m. UTC
do_div() does a 64-by-32 division. Here the divisor is an unsigned long
which on some platforms is 64 bit wide. So use div64_ul instead of do_div
to avoid a possible truncation. Issue was identified using the
coccicheck tool.
Signed-off-by: Deepak R Varma <drv@mailo.com>
---
drivers/staging/iio/impedance-analyzer/ad5933.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.34.1
Comments
> -----Original Message----- > From: Deepak R Varma <drv@mailo.com> > Sent: Thursday, October 27, 2022 11:29 PM > To: outreachy@lists.linux.dev; Lars-Peter Clausen <lars@metafoo.de>; > Hennerich, Michael <Michael.Hennerich@analog.com>; Jonathan Cameron > <jic23@kernel.org>; Greg Kroah-Hartman <gregkh@linuxfoundation.org>; > linux-iio@vger.kernel.org; linux-staging@lists.linux.dev; linux- > kernel@vger.kernel.org > Subject: [PATCH] staging: iio: ad5933: Use div64_ul instead of do_div > > [External] > > do_div() does a 64-by-32 division. Here the divisor is an unsigned long > which on some platforms is 64 bit wide. So use div64_ul instead of do_div > to avoid a possible truncation. Issue was identified using the > coccicheck tool. > > Signed-off-by: Deepak R Varma <drv@mailo.com> > --- Reviewed-by: Nuno Sá <nuno.sa@analog.com>
On Fri, Oct 28, 2022 at 02:58:49AM +0530, Deepak R Varma wrote: > do_div() does a 64-by-32 division. Here the divisor is an unsigned long > which on some platforms is 64 bit wide. So use div64_ul instead of do_div > to avoid a possible truncation. Issue was identified using the > coccicheck tool. > > Signed-off-by: Deepak R Varma <drv@mailo.com> > --- > drivers/staging/iio/impedance-analyzer/ad5933.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/iio/impedance-analyzer/ad5933.c b/drivers/staging/iio/impedance-analyzer/ad5933.c > index f177b20f0f2d..730bb31a20d8 100644 > --- a/drivers/staging/iio/impedance-analyzer/ad5933.c > +++ b/drivers/staging/iio/impedance-analyzer/ad5933.c > @@ -196,7 +196,7 @@ static int ad5933_set_freq(struct ad5933_state *st, > } dat; > > freqreg = (u64)freq * (u64)(1 << 27); > - do_div(freqreg, st->mclk_hz / 4); > + freqreg = div64_ul(freqreg, st->mclk_hz / 4); > > switch (reg) { > case AD5933_REG_FREQ_START: > -- > 2.34.1 No, this isn't ok, please read the mailing list archives for why these changes are not going to be accepted: https://lore.kernel.org/r/e2ec77060cc84a33b49d5fd11d7867f6@AcuMS.aculab.com Please always at least look at the archives of the past few weeks as to if changes like this are able to be accepted or not. thanks, greg k-h
> > -----Original Message----- > > From: Deepak R Varma <drv@mailo.com> > > > > [External] > > > > do_div() does a 64-by-32 division. Here the divisor is an unsigned long > > which on some platforms is 64 bit wide. So use div64_ul instead of do_div > > to avoid a possible truncation. Issue was identified using the > > coccicheck tool. These changes should all get nacked unless the domain of the values can be shown to be out of range. The entire point of do_div() is that because division is expensive using a limited range division is significantly faster. Even on Intel 64 bit cpu the 64 by 32 divide is significantly faster then a full 64 bit divide for the same input values. One might also question why the divisor is actually 'unsigned long' at all. The code is almost certainly expected to compile for 32bit so the domain of the value should fit in 32 bits. So either the type could be unsigned int, or it really doesn't matter that the value is truncated to 32bit because it can never be larger. David > > > > Signed-off-by: Deepak R Varma <drv@mailo.com> > > --- > > Reviewed-by: Nuno Sá <nuno.sa@analog.com> - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
On Sat, Oct 29, 2022 at 09:52:40AM +0200, Greg Kroah-Hartman wrote: > On Fri, Oct 28, 2022 at 02:58:49AM +0530, Deepak R Varma wrote: > > do_div() does a 64-by-32 division. Here the divisor is an unsigned long > > which on some platforms is 64 bit wide. So use div64_ul instead of do_div > > to avoid a possible truncation. Issue was identified using the > > coccicheck tool. > > > > Signed-off-by: Deepak R Varma <drv@mailo.com> > > --- > > drivers/staging/iio/impedance-analyzer/ad5933.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/staging/iio/impedance-analyzer/ad5933.c b/drivers/staging/iio/impedance-analyzer/ad5933.c > > index f177b20f0f2d..730bb31a20d8 100644 > > --- a/drivers/staging/iio/impedance-analyzer/ad5933.c > > +++ b/drivers/staging/iio/impedance-analyzer/ad5933.c > > @@ -196,7 +196,7 @@ static int ad5933_set_freq(struct ad5933_state *st, > > } dat; > > > > freqreg = (u64)freq * (u64)(1 << 27); > > - do_div(freqreg, st->mclk_hz / 4); > > + freqreg = div64_ul(freqreg, st->mclk_hz / 4); > > > > switch (reg) { > > case AD5933_REG_FREQ_START: > > -- > > 2.34.1 > > No, this isn't ok, please read the mailing list archives for why these > changes are not going to be accepted: > https://lore.kernel.org/r/e2ec77060cc84a33b49d5fd11d7867f6@AcuMS.aculab.com > > Please always at least look at the archives of the past few weeks as to > if changes like this are able to be accepted or not. Hello Greg, My apologies for not looking at the lore mailing archive. I only looked at the past git commits and found a few similar changes accepted in the past. My bad. I will always look at the mailing archive as well going forward. There are other review comments from the experts on similar patches. I appreciate everyone's time and comment. I will look at those and revert accordingly. Thank you, ./drv > > thanks, > > greg k-h
On Sat, Oct 29, 2022 at 11:23:06AM +0000, David Laight wrote: > > > -----Original Message----- > > > From: Deepak R Varma <drv@mailo.com> > > > > > > [External] > > > > > > do_div() does a 64-by-32 division. Here the divisor is an unsigned long > > > which on some platforms is 64 bit wide. So use div64_ul instead of do_div > > > to avoid a possible truncation. Issue was identified using the > > > coccicheck tool. > > These changes should all get nacked unless the domain of the values > can be shown to be out of range. Hello David, I looked through the data sheets for these hardware [ad983*] and believe the divisor max can attain 75MHz which fits well in a 32 bit size. Hence the proposed changes for these drivers to switch to div64_ul may actually slowdown the division. Please correct if I said something incorrect. Requesting to kindly ignore my proposed changes. > > The entire point of do_div() is that because division is expensive > using a limited range division is significantly faster. > > Even on Intel 64 bit cpu the 64 by 32 divide is significantly > faster then a full 64 bit divide for the same input values. > > One might also question why the divisor is actually 'unsigned long' > at all. The code is almost certainly expected to compile for 32bit > so the domain of the value should fit in 32 bits. > So either the type could be unsigned int, or it really doesn't matter > that the value is truncated to 32bit because it can never be larger. Thank you for the detailed explanation. This is very helpful. Thank you for the detailed explanation. This is very helpful. ./drv > > David > > > > > > > > Signed-off-by: Deepak R Varma <drv@mailo.com> > > > --- > > > > Reviewed-by: Nuno Sá <nuno.sa@analog.com> > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) >
diff --git a/drivers/staging/iio/impedance-analyzer/ad5933.c b/drivers/staging/iio/impedance-analyzer/ad5933.c index f177b20f0f2d..730bb31a20d8 100644 --- a/drivers/staging/iio/impedance-analyzer/ad5933.c +++ b/drivers/staging/iio/impedance-analyzer/ad5933.c @@ -196,7 +196,7 @@ static int ad5933_set_freq(struct ad5933_state *st, } dat; freqreg = (u64)freq * (u64)(1 << 27); - do_div(freqreg, st->mclk_hz / 4); + freqreg = div64_ul(freqreg, st->mclk_hz / 4); switch (reg) { case AD5933_REG_FREQ_START: