* Re: [PATCH] p54usb: Remove duplicate Medion MD40900 device id
From: Leann Ogasawara @ 2010-06-15 17:59 UTC (permalink / raw)
To: John W. Linville; +Cc: Larry Finger, flamingice, linux-wireless, Ben Collins
In-Reply-To: <20100614185549.GB2216@tuxdriver.com>
On Mon, 2010-06-14 at 14:55 -0400, John W. Linville wrote:
> On Thu, Jun 10, 2010 at 06:23:19PM -0500, Larry Finger wrote:
> > On 06/10/2010 05:28 PM, Leann Ogasawara wrote:
> > > The Medion MD40900 device id [0x0cde, 0x0006] is defined twice. Remove
> > > the duplicate.
> > >
> > > Originally-by: Ben Collins <ben.collins@ubuntu.com>
> > > Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
> > > ---
> > > drivers/net/wireless/p54/p54usb.c | 1 -
> > > 1 files changed, 0 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/drivers/net/wireless/p54/p54usb.c b/drivers/net/wireless/p54/p54usb.c
> > > index 7307325..d6d8713 100644
> > > --- a/drivers/net/wireless/p54/p54usb.c
> > > +++ b/drivers/net/wireless/p54/p54usb.c
> > > @@ -69,7 +69,6 @@ static struct usb_device_id p54u_table[] __devinitdata = {
> > > {USB_DEVICE(0x0915, 0x2002)}, /* Cohiba Proto board */
> > > {USB_DEVICE(0x0baf, 0x0118)}, /* U.S. Robotics U5 802.11g Adapter*/
> > > {USB_DEVICE(0x0bf8, 0x1009)}, /* FUJITSU E-5400 USB D1700*/
> > > - {USB_DEVICE(0x0cde, 0x0006)}, /* Medion MD40900 */
> > > {USB_DEVICE(0x0cde, 0x0008)}, /* Sagem XG703A */
> > > {USB_DEVICE(0x0cde, 0x0015)}, /* Zcomax XG-705A */
> > > {USB_DEVICE(0x0d8e, 0x3762)}, /* DLink DWL-G120 Cohiba */
> >
> > Do you know for certain that this device is a Version 1 chip, and for
> > that reason, you are removing it from the version 2 list?
> >
> > If not, NACK.
>
> So, I guess you are concerned about the groupings because of the
> different firmwares or something like that? Perhaps a comment that
> says "this could be a version 2 device" is just as handy? Since the
> driver prints the name of the firmware it wants, is there any real
> need for grouping the IDs?
>
> OTOH, is there any actual harm from the duplicate entry? It "seems"
> wrong to me too, but I guess it does no harm...?
I don't believe there is any harm from the duplicate entry, it just
seemed unnecessary.
> Leann and/or Ben, was this just tidying-up? I'm guessing there wasn't
> an actual bug involved?
Indeed, this was just a patch we'd been carrying to tidy things up.
There was no actual bug involved. I'd be happy to send a v2 of the
patch which comments out the duplicate entry and adds a note as to why.
Or I'd be fine just leaving the code as is and we'll drop the patch
we're carrying locally in Ubuntu.
Thanks,
Leann
^ permalink raw reply
* Re: [PATCH] zd1211rw: ignore unknown regulatory domain.
From: Gábor Stefanik @ 2010-06-15 17:40 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Kouhei Sutou, Stephen Chen, David Quan, linux-wireless,
Michael Green
In-Reply-To: <AANLkTinEMAQu33Tlv81-Cdx9fLZK-a-7uJlbAo7te2_w@mail.gmail.com>
On Sun, Jun 13, 2010 at 10:23 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> Note: this e-mail is on a public mailing list!
>
> On Sat, Jun 12, 2010 at 10:52 PM, Kouhei Sutou <kou@clear-code.com> wrote:
>> Hi,
>>
>> I'm using PLANEX GW-US54GXS (2019:5303) and it works with
>> the attached patch. Could you consider to merge the attached
>> patch?
>>
>> Problem: GW-US54GXS uses zd1211rw but zd1211rw doesn't have
>> a regulatory domain reported by GW-US54GXS (0x49).
>>
>> Solutions:
>>
>> (1) add a new regulatory domain (0x49). Here is a patch to
>> use the approach:
>
> Stephen, David, does 0x49 map to JP for zd1211 ? Are there other ones?
> Here is our list so far:
>
> #define ZD_REGDOMAIN_FCC 0x10
> #define ZD_REGDOMAIN_IC 0x20
> #define ZD_REGDOMAIN_ETSI 0x30
> #define ZD_REGDOMAIN_SPAIN 0x31
> #define ZD_REGDOMAIN_FRANCE 0x32
> #define ZD_REGDOMAIN_JAPAN_ADD 0x40
> #define ZD_REGDOMAIN_JAPAN 0x41
>
> This is what they map to:
>
> static struct zd_reg_alpha2_map reg_alpha2_map[] = {
> { ZD_REGDOMAIN_FCC, "US" },
> { ZD_REGDOMAIN_IC, "CA" },
> { ZD_REGDOMAIN_ETSI, "DE" }, /* Generic ETSI, use most restrictive */
Note: This one is causing me problems here in Hungary, as it keeps
resetting my regdomain to Germany. I believe we should implement
allowing the user to choose regdomain in this case, but allowing only
regdomains in ETSI.
> { ZD_REGDOMAIN_JAPAN, "JP" },
> { ZD_REGDOMAIN_JAPAN_ADD, "JP" },
> { ZD_REGDOMAIN_SPAIN, "ES" },
> { ZD_REGDOMAIN_FRANCE, "FR" },
> };
>
> Kouhei, if no regulatory domain is found, instead we should world
> roam, we cannot allow letting the user change regulatory domains at
> their whim. We can, however let them choose one to help compliance,
> but you can only help compliance once you know your actual regulatory
> domain.
>
> Luis
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH] zd1211rw: ignore unknown regulatory domain.
From: Luis R. Rodriguez @ 2010-06-15 15:22 UTC (permalink / raw)
To: Kouhei Sutou; +Cc: Stephen.Chen, David.Quan, linux-wireless, Michael.Green
In-Reply-To: <20100615.232558.867740727379709943.kou@clear-code.com>
On Tue, Jun 15, 2010 at 7:25 AM, Kouhei Sutou <kou@clear-code.com> wrote:
> Hi,
>
> In <AANLkTinEMAQu33Tlv81-Cdx9fLZK-a-7uJlbAo7te2_w@mail.gmail.com>
> "Re: [PATCH] zd1211rw: ignore unknown regulatory domain." on Sun, 13 Jun 2010 13:23:20 -0700,
> "Luis R. Rodriguez" <mcgrof@gmail.com> wrote:
>
>>> I'm using PLANEX GW-US54GXS (2019:5303) and it works with
>>> the attached patch. Could you consider to merge the attached
>>> patch?
>>>
>>> Problem: GW-US54GXS uses zd1211rw but zd1211rw doesn't have
>>> a regulatory domain reported by GW-US54GXS (0x49).
>>>
>>> Solutions:
>>>
>>> (1) add a new regulatory domain (0x49). Here is a patch to
>>> use the approach:
>>
>> Stephen, David, does 0x49 map to JP for zd1211 ? Are there other ones?
>> Here is our list so far:
> ...
>> Kouhei, if no regulatory domain is found, instead we should world
>> roam, we cannot allow letting the user change regulatory domains at
>> their whim. We can, however let them choose one to help compliance,
>> but you can only help compliance once you know your actual regulatory
>> domain.
>
> Luis, thanks for your input.
> It seems that we can't use GW-US54GXS until 0x49 regulatory
> domain is registered to zd1211rw. Is it right?
>
> If it is right, what I can do for GW-US54GXS? Should I wait
> a response from Stephen and/or David?
We spoke and 0x49 - > JP is ok, can you send a patch for that?
Luis
^ permalink raw reply
* Re: [RFC] Changes in mac80211 to make at76c50x-usb working again
From: Kalle Valo @ 2010-06-15 14:26 UTC (permalink / raw)
To: Johannes Berg
Cc: John W. Linville, Sebastian Smolorz, linux-wireless,
Marcel Holtmann
In-Reply-To: <1276609006.3648.233.camel@jlt3.sipsolutions.net>
On 15 June 2010 16:36, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2010-06-15 at 09:26 -0400, John W. Linville wrote:
>> On Tue, Jun 15, 2010 at 02:16:36PM +0200, Sebastian Smolorz wrote:
>> > the at76c50x-usb driver fails to authenticate with an AP.
>
> We need more information on how it fails.
I debugged this a long time ago. The problem is that firmware's
CMD_JOIN only works if bssid is correct one. I remember trying
ff:ff:ff:ff:ff:ff, but that didn't work for some reason. The join
command needs to be sent before association, otherwise transmission
won't work at all. And if I use a random bssid the firmware will
filter the replies. But I tested this a long time ago, I might
remember something wrong.
I was thinking a hack which would get bssid from association frames
and then send CMD_JOIN, before the association frame. IMHO no need to
change mac80211 because of this old hardware.
Kalle
^ permalink raw reply
* Re: [PATCH] zd1211rw: ignore unknown regulatory domain.
From: Kouhei Sutou @ 2010-06-15 14:25 UTC (permalink / raw)
To: mcgrof; +Cc: Stephen.Chen, David.Quan, linux-wireless, Michael.Green
In-Reply-To: <AANLkTinEMAQu33Tlv81-Cdx9fLZK-a-7uJlbAo7te2_w@mail.gmail.com>
Hi,
In <AANLkTinEMAQu33Tlv81-Cdx9fLZK-a-7uJlbAo7te2_w@mail.gmail.com>
"Re: [PATCH] zd1211rw: ignore unknown regulatory domain." on Sun, 13 Jun 2010 13:23:20 -0700,
"Luis R. Rodriguez" <mcgrof@gmail.com> wrote:
>> I'm using PLANEX GW-US54GXS (2019:5303) and it works with
>> the attached patch. Could you consider to merge the attached
>> patch?
>>
>> Problem: GW-US54GXS uses zd1211rw but zd1211rw doesn't have
>> a regulatory domain reported by GW-US54GXS (0x49).
>>
>> Solutions:
>>
>> (1) add a new regulatory domain (0x49). Here is a patch to
>> use the approach:
>
> Stephen, David, does 0x49 map to JP for zd1211 ? Are there other ones?
> Here is our list so far:
...
> Kouhei, if no regulatory domain is found, instead we should world
> roam, we cannot allow letting the user change regulatory domains at
> their whim. We can, however let them choose one to help compliance,
> but you can only help compliance once you know your actual regulatory
> domain.
Luis, thanks for your input.
It seems that we can't use GW-US54GXS until 0x49 regulatory
domain is registered to zd1211rw. Is it right?
If it is right, what I can do for GW-US54GXS? Should I wait
a response from Stephen and/or David?
Thanks,
--
kou
^ permalink raw reply
* Re: [RFC] Changes in mac80211 to make at76c50x-usb working again
From: Johannes Berg @ 2010-06-15 14:21 UTC (permalink / raw)
To: Sebastian Smolorz
Cc: John W. Linville, kalle.valo, linux-wireless, Marcel Holtmann
In-Reply-To: <201006151611.56061.Sebastian.Smolorz@gmx.de>
On Tue, 2010-06-15 at 16:11 +0200, Sebastian Smolorz wrote:
> Johannes Berg wrote:
> > On Tue, 2010-06-15 at 15:49 +0200, Sebastian Smolorz wrote:
> > > Johannes Berg wrote:
> > > > On Tue, 2010-06-15 at 09:26 -0400, John W. Linville wrote:
> > > > > On Tue, Jun 15, 2010 at 02:16:36PM +0200, Sebastian Smolorz wrote:
> > > > > > Hi,
> > > > > >
> > > > > > the at76c50x-usb driver fails to authenticate with an AP.
> > > >
> > > > We need more information on how it fails.
> > >
> > > The problem is that the following if-statement is never true:
> Hm, for me it works. Alternatively:
> http://lxr.free-electrons.com/source/drivers/net/wireless/at76c50x-usb.c#L1986
That works. However, that if statement _will_ be true?
I suppose at76 has some issue where it won't send out frames before
knowing the BSSID?
johannes
^ permalink raw reply
* Re: [RFC] Changes in mac80211 to make at76c50x-usb working again
From: Sebastian Smolorz @ 2010-06-15 14:11 UTC (permalink / raw)
To: Johannes Berg
Cc: John W. Linville, kalle.valo, linux-wireless, Marcel Holtmann
In-Reply-To: <1276610211.3648.234.camel@jlt3.sipsolutions.net>
Johannes Berg wrote:
> On Tue, 2010-06-15 at 15:49 +0200, Sebastian Smolorz wrote:
> > Johannes Berg wrote:
> > > On Tue, 2010-06-15 at 09:26 -0400, John W. Linville wrote:
> > > > On Tue, Jun 15, 2010 at 02:16:36PM +0200, Sebastian Smolorz wrote:
> > > > > Hi,
> > > > >
> > > > > the at76c50x-usb driver fails to authenticate with an AP.
> > >
> > > We need more information on how it fails.
> >
> > The problem is that the following if-statement is never true:
> >
> > http://lxr.linux.no/#linux+v2.6.34/drivers/net/wireless/at76c50x-usb.c#L1986
>
> That link doesn't work.
Hm, for me it works. Alternatively:
http://lxr.free-electrons.com/source/drivers/net/wireless/at76c50x-usb.c#L1986
Anyway, it is line 1986 in drivers/net/wireless/at76c50x-usb.c, kernel version 2.6.34.
--
Sebastian
^ permalink raw reply
* Re: [RFC] Changes in mac80211 to make at76c50x-usb working again
From: Johannes Berg @ 2010-06-15 13:56 UTC (permalink / raw)
To: Sebastian Smolorz
Cc: John W. Linville, kalle.valo, linux-wireless, Marcel Holtmann
In-Reply-To: <201006151549.41963.Sebastian.Smolorz@gmx.de>
On Tue, 2010-06-15 at 15:49 +0200, Sebastian Smolorz wrote:
> Johannes Berg wrote:
> > On Tue, 2010-06-15 at 09:26 -0400, John W. Linville wrote:
> > > On Tue, Jun 15, 2010 at 02:16:36PM +0200, Sebastian Smolorz wrote:
> > > > Hi,
> > > >
> > > > the at76c50x-usb driver fails to authenticate with an AP.
> >
> > We need more information on how it fails.
>
> The problem is that the following if-statement is never true:
>
> http://lxr.linux.no/#linux+v2.6.34/drivers/net/wireless/at76c50x-usb.c#L1986
That link doesn't work.
johannes
^ permalink raw reply
* Re: [PATCH 1/3] Libertas: cfg80211 support
From: Holger Schurig @ 2010-06-15 13:48 UTC (permalink / raw)
To: Johannes Berg; +Cc: dkiran, linux-wireless
In-Reply-To: <1276519238.3926.20.camel@jlt3.sipsolutions.net>
I'm o.k. with being mentioned in the commit log message.
After all, I *intended* that someone picks this up and continued to work on
it, while I'm off to other projects due to my job. That makes me only able to
work in an on-and-off style with kernel stuff.
^ permalink raw reply
* Re: [RFC] Changes in mac80211 to make at76c50x-usb working again
From: Sebastian Smolorz @ 2010-06-15 13:49 UTC (permalink / raw)
To: Johannes Berg
Cc: John W. Linville, kalle.valo, linux-wireless, Marcel Holtmann
In-Reply-To: <1276609006.3648.233.camel@jlt3.sipsolutions.net>
Johannes Berg wrote:
> On Tue, 2010-06-15 at 09:26 -0400, John W. Linville wrote:
> > On Tue, Jun 15, 2010 at 02:16:36PM +0200, Sebastian Smolorz wrote:
> > > Hi,
> > >
> > > the at76c50x-usb driver fails to authenticate with an AP.
>
> We need more information on how it fails.
The problem is that the following if-statement is never true:
http://lxr.linux.no/#linux+v2.6.34/drivers/net/wireless/at76c50x-usb.c#L1986
What else information do you need? dmesg output, debugfs trace?
>
> > > The last working
> > > major kernel version was 2.6.30. I investigated the problem and found
> > > out that the driver needs to send a join command (CMD_JOIN) prior to
> > > the actual authentication process. For the join command, the driver
> > > needs to know the bssid of the AP. The problem is now that the
> > > mac80211 layer does not inform the driver about the bssid prior to
> > > the authentication. So we have a chicken-and-egg dilemma.
--
Sebastian
^ permalink raw reply
* Re: [RFC] Changes in mac80211 to make at76c50x-usb working again
From: Johannes Berg @ 2010-06-15 13:36 UTC (permalink / raw)
To: John W. Linville
Cc: Sebastian Smolorz, kalle.valo, linux-wireless, Marcel Holtmann
In-Reply-To: <20100615132619.GB12885@tuxdriver.com>
On Tue, 2010-06-15 at 09:26 -0400, John W. Linville wrote:
> On Tue, Jun 15, 2010 at 02:16:36PM +0200, Sebastian Smolorz wrote:
> > Hi,
> >
> > the at76c50x-usb driver fails to authenticate with an AP.
We need more information on how it fails.
> > The last working
> > major kernel version was 2.6.30. I investigated the problem and found out
> > that the driver needs to send a join command (CMD_JOIN) prior to the actual
> > authentication process. For the join command, the driver needs to know the
> > bssid of the AP. The problem is now that the mac80211 layer does not inform
> > the driver about the bssid prior to the authentication. So we have a
> > chicken-and-egg dilemma.
> [1] http://thread.gmane.org/gmane.linux.kernel.wireless.general/32598
> [2] http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1995
>
> Cc: Marcel Holtmann <marcel@holtmann.org>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
>
> It would be best to avoid reintroducing the bug mentioned in that
> commit. Perhaps ensuring that iwlwifi's sta_notify is correct would
> be worthwhile?
mac80211's sta_notify was since fixed.
> What other issues might be introduced from setting a non-zero BSSID
> when not associated? Will that limit scan results for any devices?
> Trigger a premature auth or assoc? Etc?
I still think this is the wrong thing to do though.
What if you want to implement fast roaming? In that case, you still have
to authenticate to one AP while associated with another, etc.
johannes
^ permalink raw reply
* Re: [RFC] Changes in mac80211 to make at76c50x-usb working again
From: John W. Linville @ 2010-06-15 13:26 UTC (permalink / raw)
To: Sebastian Smolorz
Cc: kalle.valo, linux-wireless, Marcel Holtmann, Johannes Berg
In-Reply-To: <201006151416.36686.Sebastian.Smolorz@gmx.de>
On Tue, Jun 15, 2010 at 02:16:36PM +0200, Sebastian Smolorz wrote:
> Hi,
>
> the at76c50x-usb driver fails to authenticate with an AP. The last working
> major kernel version was 2.6.30. I investigated the problem and found out
> that the driver needs to send a join command (CMD_JOIN) prior to the actual
> authentication process. For the join command, the driver needs to know the
> bssid of the AP. The problem is now that the mac80211 layer does not inform
> the driver about the bssid prior to the authentication. So we have a
> chicken-and-egg dilemma.
>
> The following patch solves the described problem. As it modifies generic
> mac80211 code and thus has influence on all drivers I'm open for comments on
> how to make a proper, probably less intrusive patch.
>
> Sebastian
Hey, thanks for giving attention to this! See below...
> ---
> diff --git a/net/mac80211/main.c b/net/mac80211/main.c
> index a1bf46c..6c34b4f 100644
> --- a/net/mac80211/main.c
> +++ b/net/mac80211/main.c
> @@ -180,17 +180,9 @@ void ieee80211_bss_info_change_notify(struct ieee80211_sub_if_data *sdata,
> if (!changed)
> return;
>
> - if (sdata->vif.type == NL80211_IFTYPE_STATION) {
> - /*
> - * While not associated, claim a BSSID of all-zeroes
> - * so that drivers don't do any weird things with the
> - * BSSID at that time.
> - */
> - if (sdata->vif.bss_conf.assoc)
> - sdata->vif.bss_conf.bssid = sdata->u.mgd.bssid;
> - else
> - sdata->vif.bss_conf.bssid = zero;
> - } else if (sdata->vif.type == NL80211_IFTYPE_ADHOC)
> + if (sdata->vif.type == NL80211_IFTYPE_STATION)
> + sdata->vif.bss_conf.bssid = sdata->u.mgd.bssid;
> + else if (sdata->vif.type == NL80211_IFTYPE_ADHOC)
> sdata->vif.bss_conf.bssid = sdata->u.ibss.bssid;
> else if (sdata->vif.type == NL80211_IFTYPE_AP)
> sdata->vif.bss_conf.bssid = sdata->vif.addr;
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index 4dad08f..b06b175 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -2042,6 +2042,9 @@ int ieee80211_mgd_auth(struct ieee80211_sub_if_data *sdata,
> wk->sdata = sdata;
> wk->done = ieee80211_probe_auth_done;
>
> + memcpy(sdata->u.mgd.bssid, req->bss->bssid, ETH_ALEN);
> + ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BSSID);
> +
> ieee80211_add_work(wk);
> return 0;
> }
FWIW, the code being removed from ieee80211_bss_info_change_notify
above was introduced by the following commit:
commit 9cef873798dfcdc10ff40b02abf1de935ceeba85
Author: Johannes Berg <johannes@sipsolutions.net>
Date: Thu May 14 13:10:14 2009 +0200
mac80211: fix managed mode BSSID handling
Currently, we will ask the driver to configure right away
when somebody changes the desired BSSID. That's totally
strange because then we will configure the driver without
even knowing whether the BSS exists. Change this to only
configure the BSSID when associated, and configure a zero
BSSID when not associated.
As a side effect, this fixes an issue with the iwlwifi
driver which doesn't implement sta_notify properly and
uses the BSSID instead and gets very confused if the
BSSID is cleared before we disassociate, which results
in the warning Marcel posted [1] and iwlwifi bug 1995 [2].
[1] http://thread.gmane.org/gmane.linux.kernel.wireless.general/32598
[2] http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1995
Cc: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It would be best to avoid reintroducing the bug mentioned in that
commit. Perhaps ensuring that iwlwifi's sta_notify is correct would
be worthwhile?
What other issues might be introduced from setting a non-zero BSSID
when not associated? Will that limit scan results for any devices?
Trigger a premature auth or assoc? Etc?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [RFC] Changes in mac80211 to make at76c50x-usb working again
From: Sebastian Smolorz @ 2010-06-15 12:16 UTC (permalink / raw)
To: kalle.valo; +Cc: linux-wireless
Hi,
the at76c50x-usb driver fails to authenticate with an AP. The last working
major kernel version was 2.6.30. I investigated the problem and found out
that the driver needs to send a join command (CMD_JOIN) prior to the actual
authentication process. For the join command, the driver needs to know the
bssid of the AP. The problem is now that the mac80211 layer does not inform
the driver about the bssid prior to the authentication. So we have a
chicken-and-egg dilemma.
The following patch solves the described problem. As it modifies generic
mac80211 code and thus has influence on all drivers I'm open for comments on
how to make a proper, probably less intrusive patch.
Sebastian
---
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index a1bf46c..6c34b4f 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -180,17 +180,9 @@ void ieee80211_bss_info_change_notify(struct ieee80211_sub_if_data *sdata,
if (!changed)
return;
- if (sdata->vif.type == NL80211_IFTYPE_STATION) {
- /*
- * While not associated, claim a BSSID of all-zeroes
- * so that drivers don't do any weird things with the
- * BSSID at that time.
- */
- if (sdata->vif.bss_conf.assoc)
- sdata->vif.bss_conf.bssid = sdata->u.mgd.bssid;
- else
- sdata->vif.bss_conf.bssid = zero;
- } else if (sdata->vif.type == NL80211_IFTYPE_ADHOC)
+ if (sdata->vif.type == NL80211_IFTYPE_STATION)
+ sdata->vif.bss_conf.bssid = sdata->u.mgd.bssid;
+ else if (sdata->vif.type == NL80211_IFTYPE_ADHOC)
sdata->vif.bss_conf.bssid = sdata->u.ibss.bssid;
else if (sdata->vif.type == NL80211_IFTYPE_AP)
sdata->vif.bss_conf.bssid = sdata->vif.addr;
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 4dad08f..b06b175 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2042,6 +2042,9 @@ int ieee80211_mgd_auth(struct ieee80211_sub_if_data *sdata,
wk->sdata = sdata;
wk->done = ieee80211_probe_auth_done;
+ memcpy(sdata->u.mgd.bssid, req->bss->bssid, ETH_ALEN);
+ ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BSSID);
+
ieee80211_add_work(wk);
return 0;
}
^ permalink raw reply related
* Re: [RFC PATCH] iw: Add support for setting transmit power
From: Julian Calaby @ 2010-06-15 11:50 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless
In-Reply-To: <1276593467-28309-1-git-send-email-juuso.oikarinen@nokia.com>
On Tue, Jun 15, 2010 at 19:17, Juuso Oikarinen
<juuso.oikarinen@nokia.com> wrote:
> This patch adds the "set tx_power" command to allow specifying the transmit
> power level to the WLAN stack. The transmit power configuration consists of
> a mode (automatic, fixed, limited) and the limit mBm value.
>
> Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
> ---
> Makefile | 3 ++-
> nl80211.h | 27 ++++++++++++++++++++++++++-
> 2 files changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index d303f45..cbb9504 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -17,7 +17,8 @@ CFLAGS += -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing
> OBJS = iw.o genl.o event.o info.o phy.o \
> interface.o ibss.o station.o survey.o util.o \
> mesh.o mpath.o scan.o reg.o version.o \
> - reason.o status.o connect.o link.o offch.o ps.o cqm.o
> + reason.o status.o connect.o link.o offch.o ps.o cqm.o \
> + txpower.o
> OBJS += sections.o
> ALL = iw
>
Call me stupid, but is there a txpower.c?
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
.Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* Re: [ath5k-devel] [PATCH] ath5k: disable all tasklets while resetting
From: Bob Copeland @ 2010-06-15 11:21 UTC (permalink / raw)
To: Bruno Randolf; +Cc: Johannes Berg, ath5k-devel, linux-wireless, linville
In-Reply-To: <201006151354.43744.br1@einfach.org>
On Tue, Jun 15, 2010 at 01:54:43PM +0900, Bruno Randolf wrote:
> if we disable interrupts in the chip (ath5k_hw_set_imr) , the hardware does
> not generate any interrupts. so no tasklets will get scheduled...
The tasklet might already be scheduled on another CPU:
cpu0 cpu1
ath5k_reset()
ath5k_intr()
ath5k_hw_set_imr(0)
synchronize_irq()
// spins until irq finishes
tasklet_schedule(foo)
tasklet_disable(foo)
// reset here
tasklet_action() // spins
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [PATCH v2] iw: Configure basic rates when joining ibss network
From: Johannes Berg @ 2010-06-15 10:05 UTC (permalink / raw)
To: Teemu Paasikivi; +Cc: linux-wireless
In-Reply-To: <1276595169-3669-1-git-send-email-ext-teemu.3.paasikivi@nokia.com>
On Tue, 2010-06-15 at 12:46 +0300, Teemu Paasikivi wrote:
> + /* basic rates */
> + if (argc > 1 && strcmp(argv[0], "basic-rates") == 0) {
> if (argc) {
> +COMMAND(ibss, join,
> + "<SSID> <freq in MHz> [fixed-freq] [<fixed bssid>] "
> + "[basic-rates <rate in Mbps,rate2,...>] [key d:0:abcde]",
that doesn't match?
johannes
^ permalink raw reply
* Re: [RFC PATCH] nl80211/cfg80211/mac80211: Add support for setting transmit power
From: Juuso Oikarinen @ 2010-06-15 9:46 UTC (permalink / raw)
To: ext Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1276594195.3648.54.camel@jlt3.sipsolutions.net>
On Tue, 2010-06-15 at 11:29 +0200, ext Johannes Berg wrote:
> On Tue, 2010-06-15 at 12:17 +0300, Juuso Oikarinen wrote:
>
> > + * @NL80211_CMD_SET_TX_POWER: Set the used transmit power level (using
> > + * %NL80211_ATTR_TX_POWER_SETTING and %NL80211_ATTR_TX_POWER_LEVEL).
>
> We have a lot of such settings (RTS threshold, coverage class, ...) done
> with SET_WIPHY, shouldn't this also be done there?
Ok, I will look into that.
> > + /*
> > + * Though the nl80211 supports negative mBm values, the interface
> > + * below it does not, for now.
> > + */
> > + if (mbm < 0) {
> > + err = -EOPNOTSUPP;
> > + goto out;
> > + }
> > +
> > + rtnl_lock();
> > +
> > + err = get_rdev_dev_by_info_ifindex(info, &rdev, &dev);
> > + if (err)
> > + goto unlock_rdev;
> > +
> > + wdev = dev->ieee80211_ptr;
> > +
> > + if (!rdev->ops->set_tx_power) {
> > + return -EOPNOTSUPP;
> > + goto unlock_rdev;
> > + }
> > +
> > + err = rdev->ops->set_tx_power(wdev->wiphy, type, MBM_TO_DBM(mbm));
>
> I think the API mismatch should be handled in mac80211 rather than
> cfg80211, that goes for both the negative values (actually, shouldn't
> that be non-positive for mac80211?) and mBm vs. dBm -- and mac80211
> should probably reject fractional dBm values for now.
Ok. If I adjust the cfg80211 ops function for this, I'll need to see
about full-mac drivers also implementing the function besides the
mac80211. I'll look into it.
-Juuso
> johannes
>
^ permalink raw reply
* [PATCH v2] iw: Configure basic rates when joining ibss network
From: Teemu Paasikivi @ 2010-06-15 9:46 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Teemu Paasikivi
This patch adds option to configure basic rates when joining ibss network.
Signed-off-by: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com>
---
ibss.c | 35 ++++++++++++++++++++++++++++++++++-
1 files changed, 34 insertions(+), 1 deletions(-)
diff --git a/ibss.c b/ibss.c
index 4715ac8..9260a9f 100644
--- a/ibss.c
+++ b/ibss.c
@@ -18,6 +18,11 @@ static int join_ibss(struct nl80211_state *state,
{
char *end;
unsigned char abssid[6];
+ unsigned char rates[NL80211_MAX_SUPP_RATES];
+ int n_rates = 0;
+ char *value = NULL, *sptr = NULL;
+ float rate;
+
if (argc < 2)
return 1;
@@ -41,6 +46,32 @@ static int join_ibss(struct nl80211_state *state,
argc--;
}
+ /* basic rates */
+ if (argc > 1 && strcmp(argv[0], "basic-rates") == 0) {
+ argv++;
+ argc--;
+
+ value = strtok_r(argv[0], ",", &sptr);
+
+ while (value && n_rates < NL80211_MAX_SUPP_RATES) {
+ rate = strtod(value, &end);
+ rates[n_rates] = rate * 2;
+
+ /* filter out suspicious values */
+ if (*end != '\0' || !rates[n_rates] ||
+ rate*2 != rates[n_rates])
+ return 1;
+
+ n_rates++;
+ value = strtok_r(NULL, ",", &sptr);
+ }
+
+ NLA_PUT(msg, NL80211_ATTR_BSS_BASIC_RATES, n_rates, rates);
+
+ argv++;
+ argc--;
+ }
+
if (argc) {
if (mac_addr_a2n(abssid, argv[0]) == 0) {
NLA_PUT(msg, NL80211_ATTR_MAC, 6, abssid);
@@ -73,7 +104,9 @@ static int leave_ibss(struct nl80211_state *state,
COMMAND(ibss, leave, NULL,
NL80211_CMD_LEAVE_IBSS, 0, CIB_NETDEV, leave_ibss,
"Leave the current IBSS cell.");
-COMMAND(ibss, join, "<SSID> <freq in MHz> [fixed-freq] [<fixed bssid>] [key d:0:abcde]",
+COMMAND(ibss, join,
+ "<SSID> <freq in MHz> [fixed-freq] [<fixed bssid>] "
+ "[basic-rates <rate in Mbps,rate2,...>] [key d:0:abcde]",
NL80211_CMD_JOIN_IBSS, 0, CIB_NETDEV, join_ibss,
"Join the IBSS cell with the given SSID, if it doesn't exist create\n"
"it on the given frequency. When fixed frequency is requested, don't\n"
--
1.5.6.3
^ permalink raw reply related
* Re: [RFC PATCH] nl80211/cfg80211/mac80211: Add support for setting transmit power
From: Johannes Berg @ 2010-06-15 9:29 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless
In-Reply-To: <1276593453-27818-1-git-send-email-juuso.oikarinen@nokia.com>
On Tue, 2010-06-15 at 12:17 +0300, Juuso Oikarinen wrote:
> + * @NL80211_CMD_SET_TX_POWER: Set the used transmit power level (using
> + * %NL80211_ATTR_TX_POWER_SETTING and %NL80211_ATTR_TX_POWER_LEVEL).
We have a lot of such settings (RTS threshold, coverage class, ...) done
with SET_WIPHY, shouldn't this also be done there?
> + /*
> + * Though the nl80211 supports negative mBm values, the interface
> + * below it does not, for now.
> + */
> + if (mbm < 0) {
> + err = -EOPNOTSUPP;
> + goto out;
> + }
> +
> + rtnl_lock();
> +
> + err = get_rdev_dev_by_info_ifindex(info, &rdev, &dev);
> + if (err)
> + goto unlock_rdev;
> +
> + wdev = dev->ieee80211_ptr;
> +
> + if (!rdev->ops->set_tx_power) {
> + return -EOPNOTSUPP;
> + goto unlock_rdev;
> + }
> +
> + err = rdev->ops->set_tx_power(wdev->wiphy, type, MBM_TO_DBM(mbm));
I think the API mismatch should be handled in mac80211 rather than
cfg80211, that goes for both the negative values (actually, shouldn't
that be non-positive for mac80211?) and mBm vs. dBm -- and mac80211
should probably reject fractional dBm values for now.
johannes
^ permalink raw reply
* [RFC PATCH] iw: Add support for setting transmit power
From: Juuso Oikarinen @ 2010-06-15 9:17 UTC (permalink / raw)
To: linux-wireless
This patch adds the "set tx_power" command to allow specifying the transmit
power level to the WLAN stack. The transmit power configuration consists of
a mode (automatic, fixed, limited) and the limit mBm value.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
---
Makefile | 3 ++-
nl80211.h | 27 ++++++++++++++++++++++++++-
2 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index d303f45..cbb9504 100644
--- a/Makefile
+++ b/Makefile
@@ -17,7 +17,8 @@ CFLAGS += -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing
OBJS = iw.o genl.o event.o info.o phy.o \
interface.o ibss.o station.o survey.o util.o \
mesh.o mpath.o scan.o reg.o version.o \
- reason.o status.o connect.o link.o offch.o ps.o cqm.o
+ reason.o status.o connect.o link.o offch.o ps.o cqm.o \
+ txpower.o
OBJS += sections.o
ALL = iw
diff --git a/nl80211.h b/nl80211.h
index b7c77f9..c98a3a1 100644
--- a/nl80211.h
+++ b/nl80211.h
@@ -132,7 +132,7 @@
* %NL80211_ATTR_REG_RULE_POWER_MAX_ANT_GAIN and
* %NL80211_ATTR_REG_RULE_POWER_MAX_EIRP.
* @NL80211_CMD_REQ_SET_REG: ask the wireless core to set the regulatory domain
- * to the the specified ISO/IEC 3166-1 alpha2 country code. The core will
+ * to the specified ISO/IEC 3166-1 alpha2 country code. The core will
* store this as a valid request and then query userspace for it.
*
* @NL80211_CMD_GET_MESH_PARAMS: Get mesh networking properties for the
@@ -340,6 +340,7 @@
* no other interfaces are operating to avoid disturbing the operation
* of any other interfaces, and other interfaces will again take
* precedence when they are used.
+ * @NL80211_CMD_SET_TX_POWER: Set transmit power level and management type.
*
* @NL80211_CMD_MAX: highest used command number
* @__NL80211_CMD_AFTER_LAST: internal use
@@ -441,6 +442,8 @@ enum nl80211_commands {
NL80211_CMD_SET_CHANNEL,
+ NL80211_CMD_SET_TX_POWER,
+
/* add new commands above here */
/* used to define NL80211_CMD_MAX below */
@@ -725,6 +728,13 @@ enum nl80211_commands {
* @NL80211_ATTR_AP_ISOLATE: (AP mode) Do not forward traffic between stations
* connected to this BSS.
*
+ * @NL80211_ATTR_TX_POWER_SETTING: Setting of the transmit power, see
+ * &enum nl80211_tx_power_setting for the possible values. This is
+ * currently used with @NL80211_CMD_SET_TX_POWER to specify the transmit
+ * power.
+ * @NL80211_ATTR_TX_POWER_LEVEL: Trasnmit power level in signed mBm format. This
+ * is currently used with @NL80211_CMD_SET_TX_POWER to specify the transmit
+ * power.
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -882,6 +892,9 @@ enum nl80211_attrs {
NL80211_ATTR_AP_ISOLATE,
+ NL80211_ATTR_TX_POWER_SETTING,
+ NL80211_ATTR_TX_POWER_LEVEL,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
@@ -1624,6 +1637,18 @@ enum nl80211_ps_state {
};
/**
+ * enum nl80211_tx_power_setting - TX power adjustment
+ * @TX_POWER_AUTOMATIC: automatic TX power handling
+ * @TX_POWER_LIMITED: limit TX power to the specified level
+ * @TX_POWER_FIXED: fix TX power to the specified level
+ */
+enum nl80211_tx_power_setting {
+ NL80211_TX_POWER_AUTOMATIC,
+ NL80211_TX_POWER_LIMITED,
+ NL80211_TX_POWER_FIXED,
+};
+
+/**
* enum nl80211_attr_cqm - connection quality monitor attributes
* @__NL80211_ATTR_CQM_INVALID: invalid
* @NL80211_ATTR_CQM_RSSI_THOLD: RSSI threshold in dBm. This value specifies
--
1.6.3.3
^ permalink raw reply related
* [RFC PATCH] nl80211/cfg80211/mac80211: Add support for setting transmit power
From: Juuso Oikarinen @ 2010-06-15 9:17 UTC (permalink / raw)
To: linux-wireless
This patch adds an interface to adjust the transmit power level. Using this
interface the transmit power mode (automatic, limited or fixed) can be set
along with the power level to be enforced.
The power level is specified with a signed mBm unit value, which allows for
greater accuracy and smaller power levels.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
---
include/linux/nl80211.h | 24 ++++++++++++++++
include/net/cfg80211.h | 15 +---------
net/mac80211/cfg.c | 8 ++--
net/wireless/nl80211.c | 66 ++++++++++++++++++++++++++++++++++++++++++++
net/wireless/wext-compat.c | 8 ++--
5 files changed, 99 insertions(+), 22 deletions(-)
diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
index 64fb32b..047d28c 100644
--- a/include/linux/nl80211.h
+++ b/include/linux/nl80211.h
@@ -340,6 +340,8 @@
* no other interfaces are operating to avoid disturbing the operation
* of any other interfaces, and other interfaces will again take
* precedence when they are used.
+ * @NL80211_CMD_SET_TX_POWER: Set the used transmit power level (using
+ * %NL80211_ATTR_TX_POWER_SETTING and %NL80211_ATTR_TX_POWER_LEVEL).
*
* @NL80211_CMD_MAX: highest used command number
* @__NL80211_CMD_AFTER_LAST: internal use
@@ -441,6 +443,8 @@ enum nl80211_commands {
NL80211_CMD_SET_CHANNEL,
+ NL80211_CMD_SET_TX_POWER,
+
/* add new commands above here */
/* used to define NL80211_CMD_MAX below */
@@ -725,6 +729,11 @@ enum nl80211_commands {
* @NL80211_ATTR_AP_ISOLATE: (AP mode) Do not forward traffic between stations
* connected to this BSS.
*
+ * @NL80211_ATTR_TX_POWER_SETTING: Setting of the transmit power, see
+ * &enum nl80211_tx_power_setting for the possible values. This is
+ * currently used with @NL80211_CMD_SET_TX_POWER.
+ * @NL80211_ATTR_TX_POWER_LEVEL: Trasnmit power level in signed mBm format. This
+ * is currently used with @NL80211_CMD_SET_TX_POWER.
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -882,6 +891,9 @@ enum nl80211_attrs {
NL80211_ATTR_AP_ISOLATE,
+ NL80211_ATTR_TX_POWER_SETTING,
+ NL80211_ATTR_TX_POWER_LEVEL,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
@@ -1624,6 +1636,18 @@ enum nl80211_ps_state {
};
/**
+ * enum nl80211_tx_power_setting - TX power adjustment
+ * @TX_POWER_AUTOMATIC: automatic TX power handling
+ * @TX_POWER_LIMITED: limit TX power to the specified level
+ * @TX_POWER_FIXED: fix TX power to the specified level
+ */
+enum nl80211_tx_power_setting {
+ NL80211_TX_POWER_AUTOMATIC,
+ NL80211_TX_POWER_LIMITED,
+ NL80211_TX_POWER_FIXED,
+};
+
+/**
* enum nl80211_attr_cqm - connection quality monitor attributes
* @__NL80211_ATTR_CQM_INVALID: invalid
* @NL80211_ATTR_CQM_RSSI_THOLD: RSSI threshold in dBm. This value specifies
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 22ab9d8..4db30f8 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -873,19 +873,6 @@ enum wiphy_params_flags {
WIPHY_PARAM_COVERAGE_CLASS = 1 << 4,
};
-/**
- * enum tx_power_setting - TX power adjustment
- *
- * @TX_POWER_AUTOMATIC: the dbm parameter is ignored
- * @TX_POWER_LIMITED: limit TX power by the dbm parameter
- * @TX_POWER_FIXED: fix TX power to the dbm parameter
- */
-enum tx_power_setting {
- TX_POWER_AUTOMATIC,
- TX_POWER_LIMITED,
- TX_POWER_FIXED,
-};
-
/*
* cfg80211_bitrate_mask - masks for bitrate control
*/
@@ -1147,7 +1134,7 @@ struct cfg80211_ops {
int (*set_wiphy_params)(struct wiphy *wiphy, u32 changed);
int (*set_tx_power)(struct wiphy *wiphy,
- enum tx_power_setting type, int dbm);
+ enum nl80211_tx_power_setting type, int dbm);
int (*get_tx_power)(struct wiphy *wiphy, int *dbm);
int (*set_wds_peer)(struct wiphy *wiphy, struct net_device *dev,
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 952845e..c1c149e 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1329,22 +1329,22 @@ static int ieee80211_set_wiphy_params(struct wiphy *wiphy, u32 changed)
}
static int ieee80211_set_tx_power(struct wiphy *wiphy,
- enum tx_power_setting type, int dbm)
+ enum nl80211_tx_power_setting type, int dbm)
{
struct ieee80211_local *local = wiphy_priv(wiphy);
struct ieee80211_channel *chan = local->hw.conf.channel;
u32 changes = 0;
switch (type) {
- case TX_POWER_AUTOMATIC:
+ case NL80211_TX_POWER_AUTOMATIC:
local->user_power_level = -1;
break;
- case TX_POWER_LIMITED:
+ case NL80211_TX_POWER_LIMITED:
if (dbm < 0)
return -EINVAL;
local->user_power_level = dbm;
break;
- case TX_POWER_FIXED:
+ case NL80211_TX_POWER_FIXED:
if (dbm < 0)
return -EINVAL;
/* TODO: move to cfg80211 when it knows the channel */
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 90ab3c8..32b3352 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -153,6 +153,8 @@ static const struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] = {
[NL80211_ATTR_CQM] = { .type = NLA_NESTED, },
[NL80211_ATTR_LOCAL_STATE_CHANGE] = { .type = NLA_FLAG },
[NL80211_ATTR_AP_ISOLATE] = { .type = NLA_U8 },
+ [NL80211_ATTR_TX_POWER_SETTING] = { .type = NLA_U32 },
+ [NL80211_ATTR_TX_POWER_LEVEL] = { .type = NLA_U32 },
};
/* policy for the attributes */
@@ -4968,6 +4970,64 @@ out:
return err;
}
+static int nl80211_set_tx_power(struct sk_buff *skb, struct genl_info *info)
+{
+ struct cfg80211_registered_device *rdev;
+ struct wireless_dev *wdev;
+ struct net_device *dev;
+ enum nl80211_tx_power_setting type;
+ int mbm = 0;
+ int err;
+
+ if (!info->attrs[NL80211_ATTR_TX_POWER_SETTING]) {
+ err = -EINVAL;
+ goto out;
+ }
+
+ type = nla_get_u32(info->attrs[NL80211_ATTR_TX_POWER_SETTING]);
+
+ if (!info->attrs[NL80211_ATTR_TX_POWER_LEVEL] &&
+ (type != NL80211_TX_POWER_AUTOMATIC)) {
+ err = -EINVAL;
+ goto out;
+ }
+
+ if (type != NL80211_TX_POWER_AUTOMATIC)
+ mbm = nla_get_u32(info->attrs[NL80211_ATTR_TX_POWER_LEVEL]);
+
+ /*
+ * Though the nl80211 supports negative mBm values, the interface
+ * below it does not, for now.
+ */
+ if (mbm < 0) {
+ err = -EOPNOTSUPP;
+ goto out;
+ }
+
+ rtnl_lock();
+
+ err = get_rdev_dev_by_info_ifindex(info, &rdev, &dev);
+ if (err)
+ goto unlock_rdev;
+
+ wdev = dev->ieee80211_ptr;
+
+ if (!rdev->ops->set_tx_power) {
+ return -EOPNOTSUPP;
+ goto unlock_rdev;
+ }
+
+ err = rdev->ops->set_tx_power(wdev->wiphy, type, MBM_TO_DBM(mbm));
+
+unlock_rdev:
+ cfg80211_unlock_rdev(rdev);
+ dev_put(dev);
+ rtnl_unlock();
+
+out:
+ return err;
+}
+
static struct genl_ops nl80211_ops[] = {
{
.cmd = NL80211_CMD_GET_WIPHY,
@@ -5284,6 +5344,12 @@ static struct genl_ops nl80211_ops[] = {
.policy = nl80211_policy,
.flags = GENL_ADMIN_PERM,
},
+ {
+ .cmd = NL80211_CMD_SET_TX_POWER,
+ .doit = nl80211_set_tx_power,
+ .policy = nl80211_policy,
+ .flags = GENL_ADMIN_PERM,
+ },
};
static struct genl_multicast_group nl80211_mlme_mcgrp = {
diff --git a/net/wireless/wext-compat.c b/net/wireless/wext-compat.c
index 9634299..3dfe8ed 100644
--- a/net/wireless/wext-compat.c
+++ b/net/wireless/wext-compat.c
@@ -829,7 +829,7 @@ int cfg80211_wext_siwtxpower(struct net_device *dev,
{
struct wireless_dev *wdev = dev->ieee80211_ptr;
struct cfg80211_registered_device *rdev = wiphy_to_dev(wdev->wiphy);
- enum tx_power_setting type;
+ enum nl80211_tx_power_setting type;
int dbm = 0;
if ((data->txpower.flags & IW_TXPOW_TYPE) != IW_TXPOW_DBM)
@@ -852,7 +852,7 @@ int cfg80211_wext_siwtxpower(struct net_device *dev,
if (data->txpower.value < 0)
return -EINVAL;
dbm = data->txpower.value;
- type = TX_POWER_FIXED;
+ type = NL80211_TX_POWER_FIXED;
/* TODO: do regulatory check! */
} else {
/*
@@ -860,10 +860,10 @@ int cfg80211_wext_siwtxpower(struct net_device *dev,
* passed in from userland.
*/
if (data->txpower.value < 0) {
- type = TX_POWER_AUTOMATIC;
+ type = NL80211_TX_POWER_AUTOMATIC;
} else {
dbm = data->txpower.value;
- type = TX_POWER_LIMITED;
+ type = NL80211_TX_POWER_LIMITED;
}
}
} else {
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] iw: Configure basic rates when joining ibss network
From: Teemu Paasikivi @ 2010-06-15 8:50 UTC (permalink / raw)
To: ext Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1276586335.3648.3.camel@jlt3.sipsolutions.net>
On Tue, 2010-06-15 at 09:18 +0200, ext Johannes Berg wrote:
> On Tue, 2010-06-15 at 09:24 +0300, Teemu Paasikivi wrote:
>
> > @@ -41,6 +46,31 @@ static int join_ibss(struct nl80211_state *state,
> > argc--;
> > }
> >
> > + /* basic rates */
> > + if (argc > 1 && strcmp(argv[0], "basic-rates") == 0) {
> > + argv++;
> > + argc--;
> > +
> > + value = strtok_r(argv[0], ",", &sptr);
> > +
> > + while (value && n_rates < NL80211_MAX_SUPP_RATES) {
> > + rate = atof(value);
>
> should that use strtod() to check you didn't give "1a,2b,6c,11d"?
>
Sure, it can be used. I think I'll change it to use that. I was just
wondering that how much the values given by the user should/could be
checked here.
> johannes
>
Br,
Teemu
^ permalink raw reply
* Re: [PATCH] ath9k: Modify LED blinking pattern during wifi activity.
From: Johannes Berg @ 2010-06-15 7:32 UTC (permalink / raw)
To: Vivek Natarajan; +Cc: linville, linux-wireless
In-Reply-To: <1276579217-6837-1-git-send-email-vnatarajan@atheros.com>
On Tue, 2010-06-15 at 10:50 +0530, Vivek Natarajan wrote:
> case LED_FULL:
I wonder if you can just use different triggers which may be easier?
Look at what I suggested earlier for integrating the LEDs with iwlwifi:
http://thread.gmane.org/gmane.linux.kernel.wireless.general/51218/focus=51520
Up to you, of course. I would love to do the iwlwifi stuff I suggested
but simply don't have time for it right now.
johannes
^ permalink raw reply
* Re: [PATCH] iw: Configure basic rates when joining ibss network
From: Johannes Berg @ 2010-06-15 7:18 UTC (permalink / raw)
To: Teemu Paasikivi; +Cc: linux-wireless
In-Reply-To: <1276583053-30638-1-git-send-email-ext-teemu.3.paasikivi@nokia.com>
On Tue, 2010-06-15 at 09:24 +0300, Teemu Paasikivi wrote:
> @@ -41,6 +46,31 @@ static int join_ibss(struct nl80211_state *state,
> argc--;
> }
>
> + /* basic rates */
> + if (argc > 1 && strcmp(argv[0], "basic-rates") == 0) {
> + argv++;
> + argc--;
> +
> + value = strtok_r(argv[0], ",", &sptr);
> +
> + while (value && n_rates < NL80211_MAX_SUPP_RATES) {
> + rate = atof(value);
should that use strtod() to check you didn't give "1a,2b,6c,11d"?
johannes
^ permalink raw reply
* [PATCH] iw: Configure basic rates when joining ibss network
From: Teemu Paasikivi @ 2010-06-15 6:24 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Teemu Paasikivi
This patch adds option to configure basic rates when joining ibss network.
Signed-off-by: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com>
---
ibss.c | 34 +++++++++++++++++++++++++++++++++-
1 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/ibss.c b/ibss.c
index 4715ac8..cf57cf0 100644
--- a/ibss.c
+++ b/ibss.c
@@ -18,6 +18,11 @@ static int join_ibss(struct nl80211_state *state,
{
char *end;
unsigned char abssid[6];
+ unsigned char rates[NL80211_MAX_SUPP_RATES];
+ int n_rates = 0;
+ char *value = NULL, *sptr = NULL;
+ float rate;
+
if (argc < 2)
return 1;
@@ -41,6 +46,31 @@ static int join_ibss(struct nl80211_state *state,
argc--;
}
+ /* basic rates */
+ if (argc > 1 && strcmp(argv[0], "basic-rates") == 0) {
+ argv++;
+ argc--;
+
+ value = strtok_r(argv[0], ",", &sptr);
+
+ while (value && n_rates < NL80211_MAX_SUPP_RATES) {
+ rate = atof(value);
+ rates[n_rates] = rate * 2;
+
+ /* filter out suspicious values */
+ if (!rates[n_rates] || rate*2 != rates[n_rates])
+ return 1;
+
+ n_rates++;
+ value = strtok_r(NULL, ",", &sptr);
+ }
+
+ NLA_PUT(msg, NL80211_ATTR_BSS_BASIC_RATES, n_rates, rates);
+
+ argv++;
+ argc--;
+ }
+
if (argc) {
if (mac_addr_a2n(abssid, argv[0]) == 0) {
NLA_PUT(msg, NL80211_ATTR_MAC, 6, abssid);
@@ -73,7 +103,9 @@ static int leave_ibss(struct nl80211_state *state,
COMMAND(ibss, leave, NULL,
NL80211_CMD_LEAVE_IBSS, 0, CIB_NETDEV, leave_ibss,
"Leave the current IBSS cell.");
-COMMAND(ibss, join, "<SSID> <freq in MHz> [fixed-freq] [<fixed bssid>] [key d:0:abcde]",
+COMMAND(ibss, join,
+ "<SSID> <freq in MHz> [fixed-freq] [<fixed bssid>] "
+ "[basic-rates <rate in Mbps,rate2,...>] [key d:0:abcde]",
NL80211_CMD_JOIN_IBSS, 0, CIB_NETDEV, join_ibss,
"Join the IBSS cell with the given SSID, if it doesn't exist create\n"
"it on the given frequency. When fixed frequency is requested, don't\n"
--
1.5.6.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox