On Wed, Aug 29, 2018 at 04:21:54PM -0500, Larry Finger wrote:
> On 08/29/2018 04:14 PM, Joe Perches wrote:
> > On Wed, 2018-08-29 at 21:35 +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.
> >
> > Hi John.
> >
> > Other than the somewhat useful code style cleanups, is there
> > a point at which you will feel comfortable doing actual code
> > changes to this driver?
> >
> > Perhaps support for the chipset could be converted to use
> > mac80211 and moved into the directory with the other realtek
> > drivers in drivers/net/wireless/realtek/rtl8xxxu/...
> >
> > Larry? What do you think?
>
> First of all, if a variable is not used, then it should be removed, not
> merely renamed to satisfy checkpatch.
>
> All the Realtek USB devices should be added to rtl8xxxu, not merely moved
> into that directory. Jes Sorensen created a well-designed driver the is
> structured to permit addition of different initialization routines, etc.
> That said, the conversion will not be easy. In addition, it will require
> having your hands on a real device - a requirement that I cannot meet for
> the RTL8192U.
>
> Larry
>
Oops... it probably doesn't look like it, at the moment, but 'actual code
changes to this driver' was where I'm hoping to get to. There's a lot of
stuff in the header files, including member variables, which are not used
in the code. I was hoping to strip these out incrementally to minimise
the amount of source code that has to be understood. I'm not familiar
with the overall network, or 80211, subsystem architecture, but it's hard
to see why this driver has it's own private ieee80211.h file.
I totally agree that the unused variables should be removed, and they
will be, if we can accept that they are in fact unused && size doesn't
matter. The structure in question 'struct ht_capability_ele' is used
in, what I consider to be, a strange way in the file ieee80211_wx.c.
struct ht_capability_ele *ht_cap = NULL;
...
ht_cap = (struct ht_capability_ele *)&network->bssht.bdHTCapBuf[4];
...
ht_cap = (struct ht_capability_ele *)&network->bssht.bdHTCapBuf[0];
I have been trying to find a datasheet for this device but to date me
query strings haven't given me much joy. I must try and get my hands on the
device in question.
Thank ye for your comments, and sorry for the "somewhat useful" changes
to date, but doing these changes is letting me get the hang of this code,
which I refuse to comment on because there are probably guidelines on using
naughty language on here. ;) When I see lines like these two:
ht_cap = (struct ht_capability_ele *)&network->bssht.bdHTCapBuf[4];
...
ht_cap = (struct ht_capability_ele *)&network->bssht.bdHTCapBuf[0];
I think that size might very well matter for the moment. The BSS_HT
structure is farther down the header file so when I clean up that struct
things might be clearer. I can only hope.
jwhitmore
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
