Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp5478608pxb; Wed, 26 Jan 2022 13:00:58 -0800 (PST) X-Google-Smtp-Source: ABdhPJzJnjmj/2/F7+7DUMdrf2dkJ5O7kPt/rocAm5hq62ayFjlIhto9w/JgluBs7Q4jvU23zCtY X-Received: by 2002:a17:903:22d2:: with SMTP id y18mr134068plg.155.1643230858340; Wed, 26 Jan 2022 13:00:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643230858; cv=none; d=google.com; s=arc-20160816; b=g5vdTayd9F2Uob2R1WUqVySHNKXgBeLez04UWxwBrW+cuSFsfREo3XdcSWpxf/f/QD nvgI+TlGVX5EiPEM7r8B1o58hBgrVY6C4GASdofO+J+od/e5RMkKlT+yGRqLDMu8BP0d s93h8wSUkuJnS0Cg7N0CFpkpO8JkzUQLszR0mU0WBCTX7+iE+E4wjW77rQiXeum+cYYX EFTkkGSqw7q6+Tf7vqiTpq0LD0Q7CdIoQ0dAQecG4Av/3G+2f+wVwtlzM5jjjNboPEui 94WMIYZu/vFMrZKSGqNAOEnDNPJj92YWAblpy/zEEbenMAnTy1o2j5Z39oBvimTp5lYL rfpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=JBuWtik7LMy3F0tZeItzrFUrCNM6hkXa3Q1aN59RsBA=; b=qt/ticNWXhJ//+oJoTwfVwYoOE1UxUJz+BZa8LBoescRam/MJyYKZE6JpDuImnAE0q +rLJ411YKweUsaQk2KuJ9h0f6xT6tWALjgc3ZHXisBb8cmjpBXrfX/Ao72N3yasNwwvd oWsAuuXAbkVHe3eglTLnbsuOu0HBCv4pHeo54Rpyj0VXiv+YP1yk23dfH3DObukOo4LP f0+doRO7DhLszO+PV5F+ckyheQ3kZ6mpOpr2kKSiFRplxlXAB4Q1Moa5g8bPaEl0L3tC d9kSHV4nihYkJosGxxmQsEUTzck6QtBeYSejlZF+seHVrKJF+ETkTfRACKX4a5r3SrOm uEPw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=Ekgs2EYw; 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 s14si231213plg.205.2022.01.26.13.00.46; Wed, 26 Jan 2022 13:00:58 -0800 (PST) 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=20210112 header.b=Ekgs2EYw; 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 S239878AbiAZK0R (ORCPT + 99 others); Wed, 26 Jan 2022 05:26:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57468 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239873AbiAZK0M (ORCPT ); Wed, 26 Jan 2022 05:26:12 -0500 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 08840C061747 for ; Wed, 26 Jan 2022 02:26:11 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id x7so62079369lfu.8 for ; Wed, 26 Jan 2022 02:26:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=JBuWtik7LMy3F0tZeItzrFUrCNM6hkXa3Q1aN59RsBA=; b=Ekgs2EYw50nyD1x1t3pixFS8bs8OxZICI/3+cxOHhZ0vbKJtbmNnyfq4jc2uKKZkC6 iAB07lg3EW9dtTB0ieXIh4//aeK6Ojxp6QlKj+QhSdnQXW6302ZcbyyN6PRrA5a7AYfm WbweAJ9MvYTnoozdA7VtCJgjKUuprS86MjERUTWCK3dM/yJSF/Ug/+UxsPZmW9DxfvgL ctzsmM03KAoSXof/dH8nyxv4Gkm02gj7ZCXjCXU2EXDdV/Y76tiWjJkiS0yWEJ16TO// WN5QQedd34NlZFMVVRI+5u0g1Pmyym6WAKvqMzVlq6iOH+9TtyE/Htj0p5KcYgNv+AR5 cpHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=JBuWtik7LMy3F0tZeItzrFUrCNM6hkXa3Q1aN59RsBA=; b=0YSHagwWntZt8+Gahd2eL7hK6vrvCXcylLF9gP/JCkwetWEPVQSGe/EVzz7AwhSXkA p7c4ncA0jjttZRbEuEAVZWpnJXQOnXZFFywhyMbkVkdE1irTck6S2oKYYKYFykI+qSTh hiKj2mtcCmb4vFiHo4QPWOaNVt9yludN6cp6mAEHR+B0RP1D7mNsrLv5R/jZ9K4J1ogO 78nIWLkWdvJ/KdpCnohlSjVsqZYpPmpDY0yhdSIrg8/hxnH8VrutjcopDV2psOtUBbD6 SCX0YKvdCDI43Z9J5F7ZgbbTeAQ4UNFAR/elHxOSpp/wFEM124cXLZ06ePcLJh0oY0E0 CTLw== X-Gm-Message-State: AOAM530SWlxqU1SEtUCmAmOG7tQWPZc3Q8w/QXHdGLcrM2nLtAs2s7qY uCgL6b52CrlaVQE2UO/hoKU= X-Received: by 2002:a05:6512:10d2:: with SMTP id k18mr19638544lfg.167.1643192770102; Wed, 26 Jan 2022 02:26:10 -0800 (PST) Received: from [192.168.1.11] ([94.103.227.208]) by smtp.gmail.com with ESMTPSA id b39sm1516962ljr.88.2022.01.26.02.26.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 26 Jan 2022 02:26:09 -0800 (PST) Message-ID: Date: Wed, 26 Jan 2022 13:26:08 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH 06/10] staging: r8188eu: remove DBG_88E calls from os_dep/ioctl_linux.c Content-Language: en-US To: Phillip Potter Cc: gregkh@linuxfoundation.org, dan.carpenter@oracle.com, Larry.Finger@lwfinger.net, straube.linux@gmail.com, martin@kaiser.cx, linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org References: <20220124224415.831-1-phil@philpotter.co.uk> <20220124224415.831-7-phil@philpotter.co.uk> From: Pavel Skripkin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Phillip, On 1/26/22 04:13, Phillip Potter wrote: [snip] } >> >> And here you also removes the reads. I guess, some kind of magic pattern is >> used >> > > So these calls are macro arguments, they would never be executed under > normal circumstances anyway, unless the rtw_debug kernel module was > passed in as 5 or more - it is 1 by default. The DBG_88E macro would > expand during preprocessing phase to (for example): > > do { > if (5 <= GlobalDebugLevel) > pr_info("R8188EU: " "dbg(0x450) = 0x%x\n", rtw_read32(padapter, 0x450)); > } while (0) > > As this is never executed under normal circumstances anyway, I would say > calls like these are therefore safe to remove. Happy to be convinced > though :-) Many thanks. > I see your point, thanks for explanation. Well, in this case, you may left all reads, that are executed during normal lifetime of a driver. We know, that there is at least 1 place, where read() call removal can break things. Might be there are couple of other places we don't know about. IMHO the best thing you can do is to leave these reads and leave a comment like "hey, please remove me and test". One day useless reads should be anyway removed, since ideally rtw_read family must get __must_check annotation + normal error handling. Thanks :) With regards, Pavel Skripkin