Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp694039rwi; Thu, 20 Oct 2022 04:14:51 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4YX/79s+pBVgvYs/rngpnm0kTBhktRvUIxG/ln0G8D5uSqKrv/dh3ylC8pwiVhiJ0Gf3MJ X-Received: by 2002:a05:6402:190e:b0:45c:d10a:4c1a with SMTP id e14-20020a056402190e00b0045cd10a4c1amr11796808edz.345.1666264491096; Thu, 20 Oct 2022 04:14:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666264491; cv=none; d=google.com; s=arc-20160816; b=qt+VksL3D1AGF6FSgbuMS1zClEPXQpP9b2iI+pagLCn954fDoV96kRx62fXrj217Fn Ji0mxrbXcFA0p3/5ze20o4I6cMa7z3RRkf7F7pKJJfFwe08Ljih82/ATlutjXUo4JKFz vCO7IIWyBPaeWx9a0cHGfT3DmorZac8F/SAOZsGXupy6etuxttPETewQJCjLFfAowfQy Mj73aXQiPC4vgwLDxFzObay9hOxJdeIbp0wIHj9gI7McMEhguSpRgkkhZx5ViLoQjd/8 WgBjsti9ahKaDDNxFX2c+zZ5b4FlG4cYB+TwFixWtgpVkAIRYTIblZlEbPeVnPXUSFjZ bQew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:message-id:in-reply-to :subject:cc:to:from:date:dkim-signature; bh=+DA42MjVpbVR0TM66dJLt3gdRhQ0fymTZJPpw0F8kv8=; b=0uhj/xzM70yZ4P66BwO4cOD7uKpMkwBOiDr2lA4IOPRHs1IXwqJVMTx7JY0GrZBSwS lspOiZfXt1howk1Xms639mHNX6M7dStK6yFmFPNZ33rz+5IHTUwaEutpbIjgs0NX8xw4 mOsUTiHboBz4CXNQ4sMFoEAu1q1rLmJbfaseHJHCcDtqykbMc/nqeXbBBpSYrdeKWjlh F9Zf8duuZvmTpFevnj439klV1FAFTkmnVn7k0qpJYC0E/3C1fo4PKy4lQOXv6sEX0pK+ NjFK013VBwQ9VK5P6IChkXLLJlxHOyuFy16trALqOMZGDVDX7r2OBbhOb2mcR3qvfAsh Miug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@inria.fr header.s=dc header.b="MPvNg/tu"; 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=pass (p=NONE sp=NONE dis=NONE) header.from=inria.fr Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qn24-20020a170907211800b0078d3ba4d567si14462579ejb.422.2022.10.20.04.14.25; Thu, 20 Oct 2022 04:14:51 -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=pass header.i=@inria.fr header.s=dc header.b="MPvNg/tu"; 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=pass (p=NONE sp=NONE dis=NONE) header.from=inria.fr Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229673AbiJTKYP (ORCPT + 99 others); Thu, 20 Oct 2022 06:24:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38636 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229893AbiJTKW5 (ORCPT ); Thu, 20 Oct 2022 06:22:57 -0400 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 51F2B1DDDDF for ; Thu, 20 Oct 2022 03:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=+DA42MjVpbVR0TM66dJLt3gdRhQ0fymTZJPpw0F8kv8=; b=MPvNg/tubHXzRsdqUTGERAxaOE8RvPWSAPSAMxaqtHiVFvFCZn/tTcOY zlJCKkBhumL+c6T/iWxHMeQoYZQb9EHLb+ATKn4YswmbmYg0VcNr3gVey 1KhUYBmv7n+KZTvGKkr6oNEFdMHjg0umhPikWliPFDw5UHdxZb7rNrmhN k=; Authentication-Results: mail3-relais-sop.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=julia.lawall@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr X-IronPort-AV: E=Sophos;i="5.95,198,1661810400"; d="scan'208";a="31959120" Received: from dt-lawall.paris.inria.fr ([128.93.67.65]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Oct 2022 12:21:36 +0200 Date: Thu, 20 Oct 2022 12:21:35 +0200 (CEST) From: Julia Lawall To: Deepak R Varma cc: outreachy@lists.linux.dev, Larry.Finger@lwfinger.net, phil@philpotter.co.uk, paskripkin@gmail.com, gregkh@linuxfoundation.org, linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org, kumarpraveen@linux.microsoft.com, saurabh.truth@gmail.com Subject: Re: [PATCH v3 06/10] staging: r8188eu: Add space between function & macro parameters In-Reply-To: Message-ID: <8e7c457c-a58a-9c2a-ba0-d520c5e0f53e@inria.fr> References: <79e0aa96b1c8b2bc0c0f8ef9e651ab254629c7a8.1666249716.git.drv@mailo.com> <114d7521-a15-9569-cb38-69f4bb8990f7@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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: X-Mailing-List: linux-kernel@vger.kernel.org > > > -#define PlatformEFIOWrite1Byte(_a,_b,_c) \ > > > - rtw_write8(_a,_b,_c) > > > -#define PlatformEFIOWrite2Byte(_a,_b,_c) \ > > > - rtw_write16(_a,_b,_c) > > > -#define PlatformEFIOWrite4Byte(_a,_b,_c) \ > > > - rtw_write32(_a,_b,_c) > > > - > > > -#define PlatformEFIORead1Byte(_a,_b) \ > > > - rtw_read8(_a,_b) > > > -#define PlatformEFIORead2Byte(_a,_b) \ > > > - rtw_read16(_a,_b) > > > -#define PlatformEFIORead4Byte(_a,_b) \ > > > - rtw_read32(_a,_b) > > > +#define PlatformEFIOWrite1Byte(_a, _b, _c) \ > > > + rtw_write8(_a, _b, _c) > > > +#define PlatformEFIOWrite2Byte(_a, _b, _c) \ > > > + rtw_write16(_a, _b, _c) > > > +#define PlatformEFIOWrite4Byte(_a, _b, _c) \ > > > + rtw_write32(_a, _b, _c) > > > + > > > +#define PlatformEFIORead1Byte(_a, _b) \ > > > + rtw_read8(_a, _b) > > > +#define PlatformEFIORead2Byte(_a, _b) \ > > > + rtw_read16(_a, _b) > > > +#define PlatformEFIORead4Byte(_a, _b) \ > > > + rtw_read32(_a, _b) > > > > Could these be inline functions? > > I am actually not seeing these macros being used anywhere. These macros were > added recently [commit ID: 7884fc0a1473c2721f496f1d1ddc9d2c91aefa53] in 2021. I > am unsure if they are intended to be used in the future or can removed entirely. > > Making these inline functions can be done, however, will we need to measure > performance impact? I will need help and time for this evaluation. Inline functions shouldn't have any performance impact. For these simple things the compiler should inline them. The reason why a macro may be needed is if it is not possible to find a single type for all of the possible argument values, or if some argument values are assigned to by the macro definition, and not just read. I would have suggested to look at all of the uses to see if there are any concerns like this, but if there aren't any uses, that won't be possible. There seems to be no special knowledge in these macros that is worth preserving, so I think that they can just be dropped. julia