Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp559605pxf; Thu, 8 Apr 2021 08:30:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx2j3DL4ZxHxgZmxhB38dgDGaN5hqqNVqeCy8sJCm42W02nDlLgEXy/yFEHp0O7aTdzLZ/M X-Received: by 2002:a62:5f47:0:b029:244:6648:a1e with SMTP id t68-20020a625f470000b029024466480a1emr3421986pfb.37.1617895839082; Thu, 08 Apr 2021 08:30:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617895839; cv=none; d=google.com; s=arc-20160816; b=Gu+6Xhs/AcSkdt9wmkklir+3sR2HXBbdJZDfjgRsBS4pRPtymUyS84dG8iy0trv2E5 AkxyE6785n2iKBH7ElzORgD5zI9kjqsuv7aM+V5rmo6xh1SbBu/Bgm2ZjdDXxT6DK2BA 6iV5gL1r8Xx/L9Q3wZQgwSJ2EIh47Fdngj4KleOLErxra1Pntu39W5Y5dTrTOKLvXAGd xh4P9BNf9Dssopi+mFJHdOs6PQ4hXhAsDBAIXY3/kHP6KYNVswTGHR9EPGQb8yYSe09F qxycmO67qFQRceClvq1NmbGbfxRr912Pc0oyQPygLb1daJ5vFN+hzOyvXUVGRWhOJgdm GZHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=w/fIHr4k/YCjJndbLMfAFWQ825CO5fXBFr+W4J/YOEk=; b=SLNaKn/FKck9jWNBToDjGBOyqecHMmc3EY8XbuiVpVr3YBe1pUo98Mhrp4GXnZvehO X6jYKjhOtxxPa5H+xHsmGMGhkEIf5PdtgVCQ/QN1mJoUrINWJB5iFlqoHWzS0m2I9IuU zI/25eh+QytxCrG7NF8YP8Mul+ztYukxzGFwyvNH6CV7o6oADj27Ie9dGuIqKwrZe8UX P/hS1hrcEjoiX2M+YPcyDQEqVs1TBvSLroFvQZs+7HBL9NtXq6t/or4svfhnPm2Jn5Tw zy1l+RxMtCoUkd1sGIakNdf3bk9nqmOs3nJkUX7ia4RqAF1p0XHDrQ6bdqfk7loG+YiD uQoQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=KeSEjnI3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 5si20399883pgg.361.2021.04.08.08.30.26; Thu, 08 Apr 2021 08:30:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=KeSEjnI3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231791AbhDHPaG (ORCPT + 99 others); Thu, 8 Apr 2021 11:30:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37288 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231630AbhDHPaF (ORCPT ); Thu, 8 Apr 2021 11:30:05 -0400 Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1AB89C061760; Thu, 8 Apr 2021 08:29:54 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id f8so2916198edd.11; Thu, 08 Apr 2021 08:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=w/fIHr4k/YCjJndbLMfAFWQ825CO5fXBFr+W4J/YOEk=; b=KeSEjnI3xQhjLShbl/Xj/CvT8KGfPMaPSq/CLq+oPKTB2Vh3gBEX8aqmBacMpODw2F ybOIcPaahLYHddplr/SlJ3kBfsdIviJaRoDn+4iTQwfl2TaGEje2ht1FErDYWLmXMiOv kF736E3CQ31QWuKUvCIdRZaYHHG2gdr7p+8M8yaT/2ReQMaDmQQz7eaTPnE4Xy9N69zl /W7wPLteWKgBmKMI2ob1X3y2ZxKH+2ohwMk2ViE3dk7MnjDL7G0dkXQEuFHmhISkWFNj r52oEnvo1b6b5QnyKhqWvyDlbkto5QYeNPkFTT+CSHYkhhh2Y4DCUjtvwJpv1QRiKs8a mK4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=w/fIHr4k/YCjJndbLMfAFWQ825CO5fXBFr+W4J/YOEk=; b=ZJoO3rFEavPEcdatfHdp+lGJWsc9gBUSvptJd179z6ohO0Q0hYTVXTEXz3I9IddN1w GVAELiAf1aHwvbsV+DgmSaB3ZOtEEjSJslPWsF54XZpgX2i3knaE+G/Qcb4fwHY2K+iL AjjUWPkuhTVytKOpwi902TqPM/w0WdDfAc1//j7ZZ4IsvG2iXciEVpXFpWl30wOYBlDn 3kRxCyVfktGsWkF1te26x0UBTaGn61wJXU70V9E7tjznwry03NMXhbbXT9d0ZKr8zaK3 GUVR3/OPa1ENXign1TELJbsAF7mNuyRg5F/zwhgwOkyT2BkaX6mrna1ohksWFeSyBm6k Oyfg== X-Gm-Message-State: AOAM533zaQ/Gm6WG/cw3GaLL+auUjAmiESrc3E0xJ1QbDlDBSHRgtt7u MgyYM5gDiQMBIb8TgPAajP8= X-Received: by 2002:a50:fd16:: with SMTP id i22mr12082023eds.239.1617895792874; Thu, 08 Apr 2021 08:29:52 -0700 (PDT) Received: from test-VirtualBox ([87.116.165.76]) by smtp.gmail.com with ESMTPSA id m5sm6719727edi.52.2021.04.08.08.29.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Apr 2021 08:29:52 -0700 (PDT) Date: Thu, 8 Apr 2021 17:29:50 +0200 From: Sergei Krainov To: Edmundo Carmona Antoranz Cc: Larry Finger , florian.c.schilhabel@googlemail.com, Greg Kroah-Hartman , linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org Subject: Re: [PATCH v2] staging: rtl8712: remove unused variable from rtl871x_mlme.c Message-ID: <20210408152950.GB5306@test-VirtualBox> References: <20210408120929.GA4346@test-VirtualBox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 08, 2021 at 08:29:00AM -0600, Edmundo Carmona Antoranz wrote: > On Thu, Apr 8, 2021 at 6:10 AM Sergei Krainov > wrote: > > No side effects can be seen locally or in r8712_find_network() > > I am sorry to jump in. Sergei, what Greg is asking is basically why > you want to delete the r8712_find_network call in the first place. > Deleting an unused variable is fine, but the problem here is that you > are _also_ deleting a call to a function that _probably_ does some > things that, even if you want to get rid of the variable, you would > probably like to keep on doing (and so the call would remain). Is that > call really not doing anything relevant? That's what you will have to > explain in the patch in order for it to make sense. > > As a side note on top of the question about the call, it's not like > the variable is not being used. It's used right after the call to > r8712_find_network to check the result of the call... so is the real > purpose of the patch to remove the call in the first place and then > having the variable removed because there is no point in having it if > the call goes away? > > I hope that helps. Thank you for clarification, guess I really misunderstood the question and didn't explain properly why I'm doing it. In this block of code call to r8712_find_network() exist only for one purpose, to return value to the pcur_wlan. And after that we're not using pcur_wlan. So in my opinion it looks like a very subtle bug where we have unused variable, which is allocated by r8712_find_network(), and if that succeeds we're also modifying value by pcur_wlan->fixed = false;. And after all that we're not using variable and compiler has no chance of catching that because of what we're doing with that value. Please correct me if I'm wrong in something, I just found that questionable behavior and decided to send patch, so someone can see it and say if I'm wrong or not. In case I'm right this change can be _possibly_ accepted. Also sorry for asking here, but is it okay that my commit has [PATCH v2] and subject is [PATCH v2] in mutt, but in mailing list I still see [PATCH]? Greg, thanks a lot for reviews of my code you did in past few days, I really appreciate that, but just didn't want to flood mailing list with my appreciation only.