linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Deepak R Varma <drv@mailo.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: outreachy@lists.linux.dev, linux-staging@lists.linux.dev,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] staging: rtl8192u: remove unused macro definition
Date: Mon, 31 Oct 2022 20:15:51 +0530	[thread overview]
Message-ID: <Y1/fn1+cthIdPKl2@debian-BULLSEYE-live-builder-AMD64> (raw)
In-Reply-To: <Y1rdEE8HBb9CVwlq@ubunlion>

On Fri, Oct 28, 2022 at 01:03:36AM +0530, Deepak Varma wrote:
> On Wed, Oct 26, 2022 at 03:55:01PM +0200, Greg Kroah-Hartman wrote:
> > On Wed, Oct 26, 2022 at 07:14:43PM +0530, Deepak R Varma wrote:
> > > On Wed, Oct 26, 2022 at 03:14:23PM +0200, Greg Kroah-Hartman wrote:
> > > > On Wed, Oct 26, 2022 at 08:58:44AM +0530, Deepak R Varma wrote:
> > > > > Pre-processor macros that are defined but are never used should be
> > > > > cleaned up to avoid unexpected usage.
> > > > >
> > > > > Signed-off-by: Deepak R Varma <drv@mailo.com>
> > > > > ---
> > > > >  drivers/staging/rtl8192u/ieee80211/ieee80211.h | 2 --
> > > > >  1 file changed, 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211.h b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
> > > > > index 00c07455cbb3..0b3dda59d7c0 100644
> > > > > --- a/drivers/staging/rtl8192u/ieee80211/ieee80211.h
> > > > > +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
> > > > > @@ -230,8 +230,6 @@ struct cb_desc {
> > > > >  #define ieee80211_unregister_crypto_ops ieee80211_unregister_crypto_ops_rsl
> > > > >  #define ieee80211_get_crypto_ops	ieee80211_get_crypto_ops_rsl
> > > > >
> > > > > -#define ieee80211_ccmp_null		ieee80211_ccmp_null_rsl
> > > > > -
> > > > >  #define free_ieee80211			free_ieee80211_rsl
> > > > >  #define alloc_ieee80211			alloc_ieee80211_rsl
> > > >
> > > > These #defines are a mess, please look into unwinding them as they
> > > > should not be needed at all.
> > >
> > > Hello Greg,
> > > I would like to know what you mean by "unwind them". Is there a documentation or past
> > > commit that I can review to understand the expectations better?
> >
> > Look at them and try to figure out why they are there, and then work to
> > remove them entirely.  A define like this is very odd in the kernel, it
> > should not be needed at all, right?
>
> Hello Greg,
> I will look into these additional macros soon and send any further edits as a
> separate patch (set). Is the current patch set with 2 patches acceptable?
>
> Also, I am trying to get Coccinelle to work on my machine. Trying to work
> through strange issues. I will work on the macro unwinding task you suggested
> once a get the Coccinelle task completed.

Hello Greg,
Most of these macro defines appear to be unused in the module anywhere.
I can simply delete the #defines for these and let the original function
names be retained.
The other way is to rename the functions by the defined value. So, we will have
to make the code change to use the foo_rsl symbol names at all places. This will
be a bigger change involving the API name change itself.

I am unable to determine the initial intention as to why these #defines were
added. Can you please suggest what would be the recommended way for the clean up
of these unused macros?

Thank you,
./drv

>
> Thank you,
> ./drv
>
> >
> > thanks,
> >
> > greg k-h
> >
>
>
>



  reply	other threads:[~2022-10-31 14:46 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-26  3:26 [PATCH 0/2] staging: rtl8192u: unused code cleanup Deepak R Varma
2022-10-26  3:27 ` [PATCH 1/2] staging: rtl8192u: remove unnecessary function implementation Deepak R Varma
2022-10-26 10:44   ` Greg Kroah-Hartman
2022-10-26 12:12     ` Deepak R Varma
2022-10-26  3:28 ` [PATCH 2/2] staging: rtl8192u: remove unused macro definition Deepak R Varma
2022-10-26 13:14   ` Greg Kroah-Hartman
2022-10-26 13:44     ` Deepak R Varma
2022-10-26 13:55       ` Greg Kroah-Hartman
2022-10-27 19:33         ` Deepak R Varma
2022-10-31 14:45           ` Deepak R Varma [this message]
2022-10-31 14:55             ` Julia Lawall
2022-10-31 15:19               ` Deepak R Varma
2022-10-31 15:37                 ` Julia Lawall
2022-10-31 16:08                   ` Deepak R Varma

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y1/fn1+cthIdPKl2@debian-BULLSEYE-live-builder-AMD64 \
    --to=drv@mailo.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=outreachy@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).