The files ieee80211_tx.c in the directories
drivers/staging/rtl8192su/ieee80211 and drivers/staging/rtl8192e/ieee80211
both contain the following code in the function
ieee80211_query_protectionmode:
if (ieee->mode == IW_MODE_MASTER)
goto NO_PROTECTION;
Elsewhere in these files when there is a comparison against an IW_MODE
value, the field that is compared is iw_mode. Should that be the case
here as well?
thanks,
julia
On Mon, 2009-08-17 at 18:35 -0700, Greg KH wrote:
> On Tue, Aug 18, 2009 at 09:13:41AM +0800, Zhu Yi wrote:
> > On Mon, 2009-08-17 at 19:50 +0800, Gábor Stefanik wrote:
> > > On Mon, Aug 17, 2009 at 10:03 AM, Julia Lawall<[email protected]> wrote:
> > > > The files ieee80211_tx.c in the directories
> > > > drivers/staging/rtl8192su/ieee80211 and
> > > drivers/staging/rtl8192e/ieee80211
> > > > both contain the following code in the function
> > > > ieee80211_query_protectionmode:
> > > >
> > > > if (ieee->mode == IW_MODE_MASTER)
> > > > goto NO_PROTECTION;
> > > >
> > > > Elsewhere in these files when there is a comparison against an
> > > IW_MODE
> > > > value, the field that is compared is iw_mode. Should that be the
> > > case
> > > > here as well?
> > > >
> > > > thanks,
> > > > julia
> > >
> > > I don't know; rtl8192su & rtl8192e use a modified version of the
> > > libipw stack, rather than the mac80211 stack found behind non-staging
> > > drivers.
> >
> > This is clearly a bug. The question is: who is maintaining this driver
> > and why it doesn't use/extend ieee80211/libipw?
>
> I maintain it, and I am working to convert it to use the existing
> ieee80211 stack that is in the kernel. Remember, these are drivers in
> the staging tree, they are usually "crap" :)
When you say "ieee80211" you mean mac80211, right?
Dan
On Mon, Aug 17, 2009 at 10:03 AM, Julia Lawall<[email protected]> wrote:
> The files ieee80211_tx.c in the directories
> drivers/staging/rtl8192su/ieee80211 and drivers/staging/rtl8192e/ieee80211
> both contain the following code in the function
> ieee80211_query_protectionmode:
>
> ? ? ? if (ieee->mode == IW_MODE_MASTER)
> ? ? ? ? ? ? ? ? ? ? ? ?goto NO_PROTECTION;
>
> Elsewhere in these files when there is a comparison against an IW_MODE
> value, the field that is compared is iw_mode. ?Should that be the case
> here as well?
>
> thanks,
> julia
I don't know; rtl8192su & rtl8192e use a modified version of the
libipw stack, rather than the mac80211 stack found behind non-staging
drivers.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
On Wed, Aug 19, 2009 at 11:32:08AM -0500, Dan Williams wrote:
> On Mon, 2009-08-17 at 18:35 -0700, Greg KH wrote:
> > On Tue, Aug 18, 2009 at 09:13:41AM +0800, Zhu Yi wrote:
> > > On Mon, 2009-08-17 at 19:50 +0800, G?bor Stefanik wrote:
> > > > On Mon, Aug 17, 2009 at 10:03 AM, Julia Lawall<[email protected]> wrote:
> > > > > The files ieee80211_tx.c in the directories
> > > > > drivers/staging/rtl8192su/ieee80211 and
> > > > drivers/staging/rtl8192e/ieee80211
> > > > > both contain the following code in the function
> > > > > ieee80211_query_protectionmode:
> > > > >
> > > > > if (ieee->mode == IW_MODE_MASTER)
> > > > > goto NO_PROTECTION;
> > > > >
> > > > > Elsewhere in these files when there is a comparison against an
> > > > IW_MODE
> > > > > value, the field that is compared is iw_mode. Should that be the
> > > > case
> > > > > here as well?
> > > > >
> > > > > thanks,
> > > > > julia
> > > >
> > > > I don't know; rtl8192su & rtl8192e use a modified version of the
> > > > libipw stack, rather than the mac80211 stack found behind non-staging
> > > > drivers.
> > >
> > > This is clearly a bug. The question is: who is maintaining this driver
> > > and why it doesn't use/extend ieee80211/libipw?
> >
> > I maintain it, and I am working to convert it to use the existing
> > ieee80211 stack that is in the kernel. Remember, these are drivers in
> > the staging tree, they are usually "crap" :)
>
> When you say "ieee80211" you mean mac80211, right?
Sorry, yes, whatever the wireless stack in the main kernel is called
these days :)
thanks,
greg k-h
On Mon, 2009-08-17 at 19:50 +0800, Gábor Stefanik wrote:
> On Mon, Aug 17, 2009 at 10:03 AM, Julia Lawall<[email protected]> wrote:
> > The files ieee80211_tx.c in the directories
> > drivers/staging/rtl8192su/ieee80211 and
> drivers/staging/rtl8192e/ieee80211
> > both contain the following code in the function
> > ieee80211_query_protectionmode:
> >
> > if (ieee->mode == IW_MODE_MASTER)
> > goto NO_PROTECTION;
> >
> > Elsewhere in these files when there is a comparison against an
> IW_MODE
> > value, the field that is compared is iw_mode. Should that be the
> case
> > here as well?
> >
> > thanks,
> > julia
>
> I don't know; rtl8192su & rtl8192e use a modified version of the
> libipw stack, rather than the mac80211 stack found behind non-staging
> drivers.
This is clearly a bug. The question is: who is maintaining this driver
and why it doesn't use/extend ieee80211/libipw?
Thanks,
-yi
On Tue, Aug 18, 2009 at 09:13:41AM +0800, Zhu Yi wrote:
> On Mon, 2009-08-17 at 19:50 +0800, G?bor Stefanik wrote:
> > On Mon, Aug 17, 2009 at 10:03 AM, Julia Lawall<[email protected]> wrote:
> > > The files ieee80211_tx.c in the directories
> > > drivers/staging/rtl8192su/ieee80211 and
> > drivers/staging/rtl8192e/ieee80211
> > > both contain the following code in the function
> > > ieee80211_query_protectionmode:
> > >
> > > if (ieee->mode == IW_MODE_MASTER)
> > > goto NO_PROTECTION;
> > >
> > > Elsewhere in these files when there is a comparison against an
> > IW_MODE
> > > value, the field that is compared is iw_mode. Should that be the
> > case
> > > here as well?
> > >
> > > thanks,
> > > julia
> >
> > I don't know; rtl8192su & rtl8192e use a modified version of the
> > libipw stack, rather than the mac80211 stack found behind non-staging
> > drivers.
>
> This is clearly a bug. The question is: who is maintaining this driver
> and why it doesn't use/extend ieee80211/libipw?
I maintain it, and I am working to convert it to use the existing
ieee80211 stack that is in the kernel. Remember, these are drivers in
the staging tree, they are usually "crap" :)
thanks,
greg k-h
On Wed, 2009-08-19 at 09:33 -0700, Greg KH wrote:
> On Wed, Aug 19, 2009 at 11:32:08AM -0500, Dan Williams wrote:
> > On Mon, 2009-08-17 at 18:35 -0700, Greg KH wrote:
> > > On Tue, Aug 18, 2009 at 09:13:41AM +0800, Zhu Yi wrote:
> > > > On Mon, 2009-08-17 at 19:50 +0800, Gábor Stefanik wrote:
> > > > > On Mon, Aug 17, 2009 at 10:03 AM, Julia Lawall<[email protected]> wrote:
> > > > > > The files ieee80211_tx.c in the directories
> > > > > > drivers/staging/rtl8192su/ieee80211 and
> > > > > drivers/staging/rtl8192e/ieee80211
> > > > > > both contain the following code in the function
> > > > > > ieee80211_query_protectionmode:
> > > > > >
> > > > > > if (ieee->mode == IW_MODE_MASTER)
> > > > > > goto NO_PROTECTION;
> > > > > >
> > > > > > Elsewhere in these files when there is a comparison against an
> > > > > IW_MODE
> > > > > > value, the field that is compared is iw_mode. Should that be the
> > > > > case
> > > > > > here as well?
> > > > > >
> > > > > > thanks,
> > > > > > julia
> > > > >
> > > > > I don't know; rtl8192su & rtl8192e use a modified version of the
> > > > > libipw stack, rather than the mac80211 stack found behind non-staging
> > > > > drivers.
> > > >
> > > > This is clearly a bug. The question is: who is maintaining this driver
> > > > and why it doesn't use/extend ieee80211/libipw?
> > >
> > > I maintain it, and I am working to convert it to use the existing
> > > ieee80211 stack that is in the kernel. Remember, these are drivers in
> > > the staging tree, they are usually "crap" :)
> >
> > When you say "ieee80211" you mean mac80211, right?
>
> Sorry, yes, whatever the wireless stack in the main kernel is called
> these days :)
We used to have the ieee80211 that rtl* forked its internal ieee80211
off of, but we just successfully made that code private to ipw2x00 (now
called "libipw") earlier this year. Wanted to make sure any effort was
correctly targeting mac80211 instead of libipw.
Dan