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@xxxxxxxxx>
> > > ---
> > > 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.
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....
Perhaps I should have held off this patch set until I had satisfied
myself that the size either, does or does not, matter and combine all
changes into one series of patches. On the other hand I've added an
extra step which can be reviewed and clearly see the incremental
changes. I'm happy enough for the whole patch set to be rejected
for the moment, but I'd be even happier if on review somebody pointed
out that a member which I have decided is unused in the code is
actually used and a patch gets rejected on those grounds. If
everybody accepts this series, that asserts that members are unused,
the next step is easy either way.
jwhitmore
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
