Received: by 2002:ac0:a679:0:0:0:0:0 with SMTP id p54csp1004251imp; Thu, 21 Feb 2019 16:14:34 -0800 (PST) X-Google-Smtp-Source: AHgI3IaUELH5q5CTIZHM10WztiOrwEzu8t+pcSmcBJGRF8mX8ot3kzFS+gARfZSnd4PqA10+rEUD X-Received: by 2002:a63:2882:: with SMTP id o124mr1186376pgo.446.1550794474294; Thu, 21 Feb 2019 16:14:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550794474; cv=none; d=google.com; s=arc-20160816; b=Grwb0QTclWSZYG/8v5WDEyj38MG2pp561wEBusIvOy8QSEvi43P16KhM+fnSGv2Kyi iO9xB9mFam7Vl+vEJlaprWZP0CPOaTY49ZlpmlkVM7R6ShKJkbPUW3biQY1J5Ds5x7mP k2SfeeVYaDvg8UFs00ICySe/Tkkeh+rqh8Z7i0o1ubXZ3dsG28h2+mkTv7ZlJNrX3wgJ 8petbwn90NONfMCTxWUrbY862M3zoIs+dx+jVVgSM7nXFzCH1rVzv4D8bS+vqeMEVBaZ 3SF9OfzuQl6ZBhdhN/Sje2gLgPgUc2CvFYJPUj5fN5Ys+RJWnDCYAfgP8QCyxpIOfRVI HZkA== 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=UOeop6k/ATulTYc9RAA3FktE0iQO8Zmhg7BcbfC17+s=; b=dOezuKY3TqJXGkz+Sb2EynbyESt05C44zGTDrJOjAce0Z5snkvUOsWLxlf9RHgjvtj IIIdj6NUXzk8EjDkCVMxk6T/MnYwaHELMoFjvqmA6ApBFH1CgiWRi49DSkmS5aMEK0Bd 8XWotT7XvS6x4cO5hbHLjSJRkmzojuZypZEdFPM3vCVVv88RZcfV7JtH5jjwLTcGSSfO GON3mq5uzoR7iFRBFgebV/yhwmlr09OpuFeIfQ3REc5D8b2ZpdXVgmeXS6qjYAKRzk9R 15MHBo5ZCz4JsvaCx33dUCY37j8/Yw5EefZz49s9PmwQtxobMQlGhSSk9yn72EhzKH1G ZivQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=topm4irO; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 1si234090plh.125.2019.02.21.16.14.18; Thu, 21 Feb 2019 16:14:34 -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=@google.com header.s=20161025 header.b=topm4irO; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726452AbfBVANz (ORCPT + 99 others); Thu, 21 Feb 2019 19:13:55 -0500 Received: from mail-pf1-f196.google.com ([209.85.210.196]:35621 "EHLO mail-pf1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726035AbfBVANz (ORCPT ); Thu, 21 Feb 2019 19:13:55 -0500 Received: by mail-pf1-f196.google.com with SMTP id j5so229624pfa.2 for ; Thu, 21 Feb 2019 16:13:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UOeop6k/ATulTYc9RAA3FktE0iQO8Zmhg7BcbfC17+s=; b=topm4irOQodKCaINTjIWW97FAbzlP77GPGjuIMW2HEHmBr3rqKgdrf1xWrwdeY0HKq j4gLhBH2IV+qH2D52joEGlYps+sk10jlr5YfYZ8hFXDBIyRyA0N5gtO6mLqwLVp8cnPo JWPt2D6Lq1NR4yvWVa6LTVl+uQgGAeDdY92ywe8yxdHefUOLmipK+61MqNXGJWIj3RVD 8zelQLOPdUnsIYepU2S3bP6uagnlX5az0z82hsVYoyGwgPPqtNjlT0qhlMJrtv0zo8NW 33ujfM1HwbypmyKnUQwrSUwW7HCCMfeSSpEhkCpQ7UgpJAViNllpgr9z7h0wJASVM3MM iszw== 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=UOeop6k/ATulTYc9RAA3FktE0iQO8Zmhg7BcbfC17+s=; b=njt711y3gRXmGfbwWIiFWJB1wzlE+ved+pKHnIV7nxygI5v7LeWbqNpkVa5R1NK6Cg 340hAfNWfHHVTiJ0FvITPhoaFy6xabQcARJINul3DwlrSqo5BZjlwfqacFr/f4bJS1AO 68AeXBRNm/LWFWS0k/CDjIWd5m5dTsnS1mA6BjhlSsRUr5HNT3LhKJx4K1H8nGcYObTm hTuCHE5y7sUXxx94MY0EXhcbvqEXswlphGLYL076QpBGb+ttvpjyqXHd6YpjWAl2IFwS 5mVurVmXDws5WYcyq8w0pvjafmXVdqIKVJKke2GdZTxRyJEinEgCprbSXF/9zF+9iR4X V77g== X-Gm-Message-State: AHQUAuaUBqOwYkMd4aDMoRdOs0PyF+61t2j3anPAo71OHrIyroquT+pS LxBIztSp9+Vk7Uw13BwRdszZpVPCBNQqi69q+SgCBw== X-Received: by 2002:a63:f544:: with SMTP id e4mr1161430pgk.145.1550794433844; Thu, 21 Feb 2019 16:13:53 -0800 (PST) MIME-Version: 1.0 References: <20190219182105.19933-1-natechancellor@gmail.com> <20190221080617.2795-1-natechancellor@gmail.com> In-Reply-To: <20190221080617.2795-1-natechancellor@gmail.com> From: Nick Desaulniers Date: Thu, 21 Feb 2019 16:13:42 -0800 Message-ID: Subject: Re: [PATCH v2] iwlwifi: mvm: Use div_s64 instead of do_div in iwl_mvm_debug_range_resp To: Nathan Chancellor Cc: Johannes Berg , Emmanuel Grumbach , Luca Coelho , Intel Linux Wireless , Kalle Valo , linux-wireless@vger.kernel.org, netdev@vger.kernel.org, LKML , Arnd Bergmann 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 Thu, Feb 21, 2019 at 12:08 AM Nathan Chancellor wrote: > > Clang warns: > > drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c:465:2: warning: > comparison of distinct pointer types ('typeof ((rtt_avg)) *' (aka 'long > long *') and 'uint64_t *' (aka 'unsigned long long *')) > [-Wcompare-distinct-pointer-types] > do_div(rtt_avg, 6666); > ^~~~~~~~~~~~~~~~~~~~~ > include/asm-generic/div64.h:222:28: note: expanded from macro 'do_div' > (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \ > ~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~ > 1 warning generated. > > do_div expects an unsigned dividend. Use div_s64, which expects a signed > dividend. > > Fixes: 937b10c0de68 ("iwlwifi: mvm: add debug prints for FTM") > Link: https://github.com/ClangBuiltLinux/linux/issues/372 > Suggested-by: Arnd Bergmann > Signed-off-by: Nathan Chancellor > --- > > v1 -> v2: > > * Fix logic (as the return value of div{,64}_s64 must be used), thanks > to Arnd for the review. oh boy, sorry I missed that in the initial code review, thanks Arnd for the sharp eye! Reviewed-by: Nick Desaulniers Side tangent: we see this kind of difference in APIs a lot (modifying the parameter vs returning a new value or making a copy then modifying that) in C++ when a call site isn't passing the explicit address of some variable or an identifier that's clearly a pointer. Ex. int foo; bar(foo); Doesn't tell you whether bar mutates foo or not without looking at the definition of bar, as it could be: void bar(int x); or void bar(int& x); I miss the convention in Ruby of using `!` suffixes on methods to differentiate between such cases. ex: "hello".capitalize vs "hello".capitalize! both return the same value, but the one with the ! mutates the existing object, while the one without creates a new object. And that's a very standard convention throughout the standard library. Whether or not people follow that convention is always another story. One thing I'm curious about, is "why does do_div exist?" When should I use do_div vs div_u64 (not div_s64 as is used in this patch)? > > drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c b/drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c > index e9822a3ec373..94132cfd1f56 100644 > --- a/drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c > +++ b/drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c > @@ -460,9 +460,7 @@ static int iwl_mvm_ftm_range_resp_valid(struct iwl_mvm *mvm, u8 request_id, > static void iwl_mvm_debug_range_resp(struct iwl_mvm *mvm, u8 index, > struct cfg80211_pmsr_result *res) > { > - s64 rtt_avg = res->ftm.rtt_avg * 100; > - > - do_div(rtt_avg, 6666); > + s64 rtt_avg = div_s64(res->ftm.rtt_avg * 100, 6666); > > IWL_DEBUG_INFO(mvm, "entry %d\n", index); > IWL_DEBUG_INFO(mvm, "\tstatus: %d\n", res->status); > -- > 2.21.0.rc1 > -- Thanks, ~Nick Desaulniers