Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp2141200rwi; Thu, 20 Oct 2022 23:38:57 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4HRYgF2t/rgnugwjgREKfWL9hUqezY/kWr7kTV6wzFX4kVSXQmLPBOKTifJ384SvFM9X0i X-Received: by 2002:a05:6402:2686:b0:45d:82c0:c2b6 with SMTP id w6-20020a056402268600b0045d82c0c2b6mr15350198edd.390.1666334337133; Thu, 20 Oct 2022 23:38:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666334337; cv=none; d=google.com; s=arc-20160816; b=mPWPzsAo4ZUtGOI30XMQZvi6YvW6d2fXFoacwA3q7BBsokwxncdT088qVoAXbqnB/V kGqGKfl2lGpRalh3tXbIv5b0CzbyxiO9Bz+tsn7NU7BzCxSptwobSzvoF8/0R2ppWS09 lLRkMoo06O3z+wAQZbcOzEvERtrek4RdFri83bTo2xHeNWLI/8bGEKYyCgy1IZsPV/Iq KNDi8NWYcHvBSIAHcmLIPHIdCuOXMVBGAOpLnVtwr2EqDZLNqEUYR1G9MCMJJsrz4oOz vU6FI+/XqU+TVAnzEO9uMBViwSb+9iLNCpCXVzs94WDWjihqR0csVr/XONZPkGxLRmZl flwg== 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=AGNpjTz/8etV68fU/zq0Wg5AG/mjk8oqIW9pT6MuO5I=; b=c1MxEhMgT1p7ZF+ls4UVbohYcy9Kp4p/2IbZUtxLYlp9JFpV40WUYp0R+w3hTtpRW9 HTNHHfW54v5S+HZJdDKphap+JdbbuuTgKkb+lcnyEbVaUyikjDZ7VxQnt6vN7sqZOZ8m W0w/buppGds874u2xIqttnkk6pv2+J3GU1r6G08FMenY1h8M3L0XD8P9dN5wszj5QU8A 5BRXTPd7PMILdn07GTDc1ziFhVI8In8nKC2bcRcggZF5I/yzjc/GG3JBHIN82kwkZE9a imcK4fgLtPb5f2rwpG+caEM9+Lo88DAjiYRNsImXYGHE1Sj5mNjfz5v/vMpge1y5M+fp lwDw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=xlB7VteB; 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=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ds14-20020a170907724e00b0078c3197bf86si18300665ejc.533.2022.10.20.23.38.31; Thu, 20 Oct 2022 23:38:57 -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=@linuxfoundation.org header.s=korg header.b=xlB7VteB; 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=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229895AbiJUF4O (ORCPT + 99 others); Fri, 21 Oct 2022 01:56:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37274 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229810AbiJUF4N (ORCPT ); Fri, 21 Oct 2022 01:56:13 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 914D91D3773 for ; Thu, 20 Oct 2022 22:56:10 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 642D4B82A66 for ; Fri, 21 Oct 2022 05:56:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B3AA3C433D7; Fri, 21 Oct 2022 05:56:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666331768; bh=7HRzomlRuJXonuSkna+wF+rj0NZf1bCzqfwL19Q3qPc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=xlB7VteB3fw5FVqFFqB6x+hBAGVdBB1cbY9Aqv4xl1bbhW2pMB+BU2izpkNBdO5Bv Vy4jVYsYiSAsL0lHwNQAyOicbDldGBj5VzSgWDr/SPHHiBwFuXGTnECjsrKES7iYT3 9KuqEb3cZHU770LIeg/JMQZ0EXexogMUqvFXPjdM= Date: Fri, 21 Oct 2022 07:56:05 +0200 From: Greg KH To: Praveen Kumar Cc: Deepak R Varma , outreachy@lists.linux.dev, Larry.Finger@lwfinger.net, phil@philpotter.co.uk, paskripkin@gmail.com, linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org, saurabh.truth@gmail.com Subject: Re: [PATCH v4 11/11] staging: r8188eu: Remove unused macros Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, 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 On Fri, Oct 21, 2022 at 11:21:06AM +0530, Praveen Kumar wrote: > On 21-10-2022 03:02, Deepak R Varma wrote: > > Simple variants of macros PlatformEFIOWrite and PlatformEFIORead are > > defined but never used. As they do not appear to be designed for anything > > significant, we can remove them to avoid unexpected usage. > > > > Suggested-by: Julia Lawall > > Signed-off-by: Deepak R Varma > > --- > > > > Changes in v4: > > 1. Patch newly added to the patch set. > > > > > > drivers/staging/r8188eu/include/rtw_io.h | 14 -------------- > > 1 file changed, 14 deletions(-) > > > > diff --git a/drivers/staging/r8188eu/include/rtw_io.h b/drivers/staging/r8188eu/include/rtw_io.h > > index 87fcf6c94ff3..e9744694204b 100644 > > --- a/drivers/staging/r8188eu/include/rtw_io.h > > +++ b/drivers/staging/r8188eu/include/rtw_io.h > > @@ -285,18 +285,4 @@ void bus_sync_io(struct io_queue *pio_q); > > u32 _ioreq2rwmem(struct io_queue *pio_q); > > void dev_power_down(struct adapter *Adapter, u8 bpwrup); > > > > -#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) \ > > Can the naming be reworked to make more Linux friendly ? something like PLATFORM_EFIO_READ1BYTE or better if there are other suggestions? > Rest others as applicable ? All of these should just be removed entirely and the normal calls here made instead. There is no need for these #defines at all. thanks, greg k-h