Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 31 Aug 2018 10:24:49 +0300
From:   Dan Carpenter <dan.carpenter@oracle.com>
To:     John Whitmore <arigead@gmail.com>
Cc:     John Whitmore <johnfwhitmore@gmail.com>,
        devel@driverdev.osuosl.org, gregkh@linuxfoundation.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 01/21] staging:rtl8192u: Rename AdvCoding - Style
Message-ID: <20180831072449.6zhkm4emdoiqfwyn@mwanda>
References: <20180829203547.15650-1-johnfwhitmore@gmail.com>
 <20180829203547.15650-2-johnfwhitmore@gmail.com>
 <20180830082305.umqtq3fdexlyvn65@mwanda>
 <20180830082628.ff5x3tzvd2wdrbir@mwanda>
 <20180830213536.GA2904@xux707-tw>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180830213536.GA2904@xux707-tw>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Aug 30, 2018 at 10:35:37PM +0100, John Whitmore wrote:
> On Thu, Aug 30, 2018 at 11:26:28AM +0300, Dan Carpenter wrote:
> > On Thu, Aug 30, 2018 at 11:23:05AM +0300, Dan Carpenter wrote:
> > > On Wed, Aug 29, 2018 at 09:35:27PM +0100, John Whitmore wrote:
> > > > Rename the bit field element AdvCoding, as it causes a checkpatch issue
> > > > with CamelCase naming. As the element is not actually used in code it
> > > > has been renamed to 'not_used_adv_coding'.
> > > > 
> > > > The single line of code which initialises the bit has been removed,
> > > > as the  field is unused.
> > > > 
> > > > This is a purely coding style change which should have no impact
> > > > on runtime code execution.
> > > > 
> > > > Signed-off-by: John Whitmore <johnfwhitmore@gmail.com>
> > > > ---
> > > >  drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h     | 2 +-
> > > >  drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 1 -
> > > >  2 files changed, 1 insertion(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h b/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
> > > > index 64d5359cf7e2..66a0274077d3 100644
> > > > --- a/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
> > > > +++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
> > > > @@ -39,7 +39,7 @@ enum ht_extension_chan_offset {
> > > >  
> > > >  struct ht_capability_ele {
> > > >  	//HT capability info
> > > > -	u8	AdvCoding:1;
> > > > +	u8	not_used_adv_coding:1;
> > > 
> > > I can't review any more of this patchset when this is the first line...
> > > 
> > 
> > That email wasn't very clear.  If you think some of your patches are
> > going to be more controversial than others, put them at the very end so
> > we can at least apply part of the patchset.
> > 
> > regards,
> > dan carpenter
> > 
> 
> Thanks for the clarification, I needed it ;)
> 
> I'm not sure I consider any of the patches in the series as being
> controversial. They are all just simple name changes of member
> variables. As a number of the variables are not used in code the names
> have been changed to reflect that fact. If I'd renamed them and left out
> the 'not_used_' prefix would the changes not be controversial? I
> don't think the fact that the members are unused is a biggy.
> 

I didn't like the new name at all.

Quite often when I review these I just use a script to verify that we're
only renaming variables and not doing code changes outside of that.  But
if I review it by hand I would have seen that the variable was not used
and investigated what was going on.

> What might appear to be controversial is that I didn't simply remove
> the members. I haven't done that because I'm not yet satisfied that
> the structure's size is insignificant. As soon as I am happy that the
> size of the structure is not important, to runtime code execution,
> there'll be a patch which removes a number of 'not_used_...' members
> from a structure.
> 
> Alternatively if the size if important there might be a patch which
> renames a number of unused bitfield members to reserved_1, reserved_2,
> reserved_3....

That's a good question.  If a struct is part of the use space API or the
network protocol or defined by the hardware then we can't change the
layout.

One thing I look for is if the struct has pointers which aren't tagged
as __user pointers then it's internal to the kernel.  Unfortunately that
doesn't help here.  Network protocol is all endian specific and this
struct is not.  But again that doesn't help much because it could just
be a bug.  If the struct is __packed then obviously the layout matters.

So I don't know.  I think you're right that actually we can't change
the layout.  The code is really a mess, so it's possible I have misread.

regards,
dan carpenter