* Re: rt2x00: rt73usb doesn't receive PS Poll frames in the AP mode
From: Igor Perminov @ 2009-07-30 20:09 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1248794724.8113.12.camel@johannes.local>
On Tue, 28/07/2009 at 17:25 +0200, Johannes Berg wrote:
> On Tue, 2009-07-28 at 18:17 +0400, Igor Perminov wrote:
>
> > And in case we introduce the FIF_PSPOLL flag, what the exact semantics
> > will it have? When the FIF_CONTROL flag is passed to a driver, but the
> > FIF_PSPOLL one isn't, should the driver filter out PS Poll frames (a) or
> > not (b)?
>
> Like all filter flags, FIF_PSPOLL would mean "give us PSPOLL frames
> please", so (b).
And one more question.
How will a driver behave in case a device has no a separate hardware
filter for PS Poll frames? I.e. what value should the driver return from
configure_filter in total_flags?
In case there is one common filter for all control frames, it's an easy
thing. If FIF_CONTROL or FIF_PSPOLL are passed to driver's
configure_filter in total_flags, both of them should be set there and
the filter should be configured to pass through all control frames.
And suppose a device has two filters: one for ACK frames and one for all
other control frames.
Suppose FIF_CONTROL is passed in total_flags only. In that case the
driver sets FIF_PSPOLL there and configures both filters to pass through
frames. Right?
And what if FIF_PSPOLL is passed in total_flags only? In that case the
ACK filter should be configured to filter out ACK frames (otherwise it
would have performance overhead at least). And the second filter is
configured to pass through frames only (i.e. all control frames except
for ACK). So, the driver will receive not only PS Poll control frames,
but some others.
The question here is: should the driver set FIF_CONTROL in total_flags
or not in that case?
Igor
^ permalink raw reply
* Re: [PATCH] mac80211: use beacons for connection monitoring
From: Johannes Berg @ 2009-07-30 19:47 UTC (permalink / raw)
To: reinette chatre
Cc: Ben Greear, linville@tuxdriver.com,
linux-wireless@vger.kernel.org
In-Reply-To: <1248975923.1216.1074.camel@rc-desk>
[-- Attachment #1: Type: text/plain, Size: 3310 bytes --]
On Thu, 2009-07-30 at 10:45 -0700, reinette chatre wrote:
> I captured the exchange when this problem occurs using a third system.
> The card does indeed try several times to send a probe request and they
> are making it out over the air. The AP never responds.
>
> Is there perhaps anything in this exchange that can help us understand
> what is going on?
>
> No. Time Source Destination Protocol Info
> 163883 401.891153 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Probe Request, SN=980, FN=0, Flags=........, SSID="XXX"
> 163885 401.891482 00:14:f2:XX:XX:XX 00:16:ea:XX:XX:XX IEEE 802.11 Probe Response, SN=3557, FN=0, Flags=........, BI=100, SSID="XXX"
It's responding here,
> 165523 404.884405 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Probe Request, SN=981, FN=0, Flags=........, SSID="XXX"
> 165525 404.885265 00:14:f2:XX:XX:XX 00:16:ea:XX:XX:XX IEEE 802.11 Probe Response, SN=3827, FN=0, Flags=....R..., BI=100, SSID="XXX"
and here,
> 166981 407.884161 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Probe Request, SN=982, FN=0, Flags=........, SSID="XXX"
> 166983 407.884555 00:14:f2:XX:XX:XX 00:16:ea:XX:XX:XX IEEE 802.11 Probe Response, SN=4034, FN=0, Flags=........, BI=100, SSID="XXX"
and here,
> 168133 410.884167 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Probe Request, SN=983, FN=0, Flags=........, SSID="XXX"
> 168134 410.884430 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Probe Request, SN=983, FN=0, Flags=....R..., SSID="XXX"
> 168135 410.884643 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Probe Request, SN=983, FN=0, Flags=....R..., SSID="XXX"
> 168136 410.884904 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Probe Request, SN=983, FN=0, Flags=....R..., SSID="XXX"
> 168137 410.885073 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Probe Request, SN=983, FN=0, Flags=....R..., SSID="XXX"
> 168138 410.885330 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Probe Request, SN=983, FN=0, Flags=....R..., SSID="XXX"
> 168139 410.885580 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Probe Request, SN=983, FN=0, Flags=....R..., SSID="XXX"
> 168140 410.885769 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Probe Request, SN=983, FN=0, Flags=....R..., SSID="XXX"
> 168141 410.886618 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Probe Request, SN=983, FN=0, Flags=....R..., SSID="XXX"
> 168142 410.887087 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Probe Request, SN=983, FN=0, Flags=....R..., SSID="XXX"
> 168143 410.887308 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Probe Request, SN=983, FN=0, Flags=....R..., SSID="XXX"
> 168144 410.887532 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Probe Request, SN=983, FN=0, Flags=....R..., SSID="XXX"
but then it stops -- try to send that frame 12 times in quick
succession.
> 168191 411.084889 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Deauthentication, SN=984, FN=0, Flags=........
And then give up. Oddly, that frame is not retried?! I would expect that
to be retried too if the AP has gone south!?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH] mac80211: fix powersave
From: Johannes Berg @ 2009-07-30 19:43 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
Some of the recent MLME rework I did broke powersave
because the ps_sdata isn't assigned at the right time,
and the work item wasn't removed from the list before
calling ieee80211_recalc_ps(). To be more specific,
this broke the case where you'd enabled PS before
associating, either automatically or with iwconfig.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
Oops.
net/mac80211/mlme.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
--- wireless-testing.orig/net/mac80211/mlme.c 2009-07-27 22:35:02.000000000 +0200
+++ wireless-testing/net/mac80211/mlme.c 2009-07-30 21:23:52.000000000 +0200
@@ -916,12 +916,9 @@ static void ieee80211_set_associated(str
ieee80211_bss_info_change_notify(sdata, bss_info_changed);
- /* will be same as sdata */
- if (local->ps_sdata) {
- mutex_lock(&local->iflist_mtx);
- ieee80211_recalc_ps(local, -1);
- mutex_unlock(&local->iflist_mtx);
- }
+ mutex_lock(&local->iflist_mtx);
+ ieee80211_recalc_ps(local, -1);
+ mutex_unlock(&local->iflist_mtx);
netif_tx_start_all_queues(sdata->dev);
netif_carrier_on(sdata->dev);
@@ -1570,6 +1567,9 @@ ieee80211_rx_mgmt_assoc_resp(struct ieee
wk->bss->cbss.bssid,
ap_ht_cap_flags);
+ /* delete work item -- must be before set_associated for PS */
+ list_del(&wk->list);
+
/* set AID and assoc capability,
* ieee80211_set_associated() will tell the driver */
bss_conf->aid = aid;
@@ -1583,7 +1583,6 @@ ieee80211_rx_mgmt_assoc_resp(struct ieee
ieee80211_sta_rx_notify(sdata, (struct ieee80211_hdr *)mgmt);
mod_beacon_timer(sdata);
- list_del(&wk->list);
kfree(wk);
return RX_MGMT_CFG80211_ASSOC;
}
^ permalink raw reply
* Re: [PATCH] iwlwifi: don't export symbols not needed in other modules
From: Johannes Berg @ 2009-07-30 19:26 UTC (permalink / raw)
To: reinette chatre; +Cc: John Linville, linux-wireless
In-Reply-To: <1248979665.1216.1094.camel@rc-desk>
[-- Attachment #1: Type: text/plain, Size: 247 bytes --]
On Thu, 2009-07-30 at 11:47 -0700, reinette chatre wrote:
> No. If this is what you want then I think you also need to remove
> iwl_rx_ant_restriction.
Hm, I missed that, I actually have removed as part of my powersave
patch.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] rt2x00dev: cancel all work on disconnect
From: Michael Buesch @ 2009-07-30 18:58 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: Pavel Roskin, linux-wireless, John W. Linville, users
In-Reply-To: <200907302045.15400.IvDoorn@gmail.com>
On Thursday 30 July 2009 20:45:15 Ivo van Doorn wrote:
> Hi,
>
> I assume fixes the bug Michael reported on Linux-wireless yesterday?
I didn't test that, yet, but the patch looks sane anyway.
> The patch looks good, but I have some minor modification request:
>
> On Wednesday 29 July 2009, Pavel Roskin wrote:
> > Signed-off-by: Pavel Roskin <proski@gnu.org>
> > ---
> > drivers/net/wireless/rt2x00/rt2x00dev.c | 7 +++++++
> > 1 files changed, 7 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
> > index 658a63b..66b303b 100644
> > --- a/drivers/net/wireless/rt2x00/rt2x00dev.c
> > +++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
> > @@ -888,6 +888,13 @@ void rt2x00lib_remove_dev(struct rt2x00_dev *rt2x00dev)
> > clear_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags);
> >
> > /*
> > + * Cancel all work.
> > + */
> > + rt2x00link_stop_tuner(rt2x00dev);
>
> This one isn't needed. rt2x00lib_disable_radio() is doing this.
>
> > + cancel_work_sync(&rt2x00dev->filter_work);
> > + cancel_work_sync(&rt2x00dev->intf_work);
>
> Could you move these 2 until after the call to rt2x00lib_disable_radio()?
>
> > + /*
> > * Disable radio.
> > */
> > rt2x00lib_disable_radio(rt2x00dev);
>
> Thanks,
>
> Ivo
>
>
--
Greetings, Michael.
^ permalink raw reply
* [RFC PATCH v2] mac80211: FIF_PSPOLL filter flag
From: Igor Perminov @ 2009-07-30 18:50 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
When an interface is configured in the AP mode, the mac80211
implementation doesn't inform the driver to receive PS Poll frames.
It leads to inability to communicate with power-saving stations
reliably.
The FIF_CONTROL flag isn't passed by mac80211 to
ieee80211_ops.configure_filter when an interface is in the AP mode.
And it's ok, because we don't want to receive ACK frames and other
control ones, but only PS Poll ones.
This patch introduces the FIF_PSPOLL filter flag in addition to
FIF_CONTROL, which means for the driver "pass PS Poll frames".
This flag is passed to the driver:
A) When an interface is configured in the AP mode.
B) In all cases, when the FIF_CONTROL flag was passed earlier (in
addition to it).
Signed-off-by: Igor Perminov <igor.perminov@inbox.ru>
---
include/net/mac80211.h | 8 ++++++--
net/mac80211/ieee80211_i.h | 2 +-
net/mac80211/iface.c | 18 ++++++++++++++++--
net/mac80211/main.c | 3 +++
4 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index d4e09a0..5113bba 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1236,10 +1236,13 @@ ieee80211_get_alt_retry_rate(const struct ieee80211_hw *hw,
* mac80211 needs to do and the amount of CPU wakeups, so you should
* honour this flag if possible.
*
- * @FIF_CONTROL: pass control frames, if PROMISC_IN_BSS is not set then
- * only those addressed to this station
+ * @FIF_CONTROL: pass control frames (except for PS Poll), if PROMISC_IN_BSS
+ * is not set then only those addressed to this station.
*
* @FIF_OTHER_BSS: pass frames destined to other BSSes
+ *
+ * @FIF_PSPOLL: pass PS Poll frames, if PROMISC_IN_BSS is not set then only
+ * those addressed to this station.
*/
enum ieee80211_filter_flags {
FIF_PROMISC_IN_BSS = 1<<0,
@@ -1249,6 +1252,7 @@ enum ieee80211_filter_flags {
FIF_BCN_PRBRESP_PROMISC = 1<<4,
FIF_CONTROL = 1<<5,
FIF_OTHER_BSS = 1<<6,
+ FIF_PSPOLL = 1<<7,
};
/**
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index aec6853..ab6003d 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -621,7 +621,7 @@ struct ieee80211_local {
int open_count;
int monitors, cooked_mntrs;
/* number of interfaces with corresponding FIF_ flags */
- int fif_fcsfail, fif_plcpfail, fif_control, fif_other_bss;
+ int fif_fcsfail, fif_plcpfail, fif_control, fif_other_bss, fif_pspoll;
unsigned int filter_flags; /* FIF_* */
struct iw_statistics wstats;
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index a83087f..c5f4559 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -220,8 +220,10 @@ static int ieee80211_open(struct net_device *dev)
local->fif_fcsfail++;
if (sdata->u.mntr_flags & MONITOR_FLAG_PLCPFAIL)
local->fif_plcpfail++;
- if (sdata->u.mntr_flags & MONITOR_FLAG_CONTROL)
+ if (sdata->u.mntr_flags & MONITOR_FLAG_CONTROL) {
local->fif_control++;
+ local->fif_pspoll++;
+ }
if (sdata->u.mntr_flags & MONITOR_FLAG_OTHER_BSS)
local->fif_other_bss++;
@@ -244,7 +246,14 @@ static int ieee80211_open(struct net_device *dev)
spin_unlock_bh(&local->filter_lock);
ieee80211_start_mesh(sdata);
+ } else if (sdata->vif.type == NL80211_IFTYPE_AP) {
+ local->fif_pspoll++;
+
+ spin_lock_bh(&local->filter_lock);
+ ieee80211_configure_filter(local);
+ spin_unlock_bh(&local->filter_lock);
}
+
changed |= ieee80211_reset_erp_info(sdata);
ieee80211_bss_info_change_notify(sdata, changed);
ieee80211_enable_keys(sdata);
@@ -388,6 +397,9 @@ static int ieee80211_stop(struct net_device *dev)
if (sdata->flags & IEEE80211_SDATA_PROMISC)
atomic_dec(&local->iff_promiscs);
+ if (sdata->vif.type == NL80211_IFTYPE_AP)
+ local->fif_pspoll--;
+
netif_addr_lock_bh(dev);
spin_lock_bh(&local->filter_lock);
__dev_addr_unsync(&local->mc_list, &local->mc_count,
@@ -439,8 +451,10 @@ static int ieee80211_stop(struct net_device *dev)
local->fif_fcsfail--;
if (sdata->u.mntr_flags & MONITOR_FLAG_PLCPFAIL)
local->fif_plcpfail--;
- if (sdata->u.mntr_flags & MONITOR_FLAG_CONTROL)
+ if (sdata->u.mntr_flags & MONITOR_FLAG_CONTROL) {
+ local->fif_pspoll--;
local->fif_control--;
+ }
if (sdata->u.mntr_flags & MONITOR_FLAG_OTHER_BSS)
local->fif_other_bss--;
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 5e76dd1..c330235 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -77,6 +77,9 @@ void ieee80211_configure_filter(struct ieee80211_local *local)
if (local->fif_other_bss)
new_flags |= FIF_OTHER_BSS;
+ if (local->fif_pspoll)
+ new_flags |= FIF_PSPOLL;
+
changed_flags = local->filter_flags ^ new_flags;
/* be a bit nasty */
^ permalink raw reply related
* Re: [RFC PATCH] rt61pci: fix module reloading with power saving enabled
From: Ivo van Doorn @ 2009-07-30 18:47 UTC (permalink / raw)
To: Pavel Roskin; +Cc: linux-wireless, users
In-Reply-To: <1248846761.18329.20.camel@ct>
Hi,
On Wednesday 29 July 2009, Pavel Roskin wrote:
> Unloading rt61pci can leave the device in such state that reloading
> rt61pci would fail to reinitialize it. Bogus data would be read from
> the EEPROM and the RF version won't be recognized. Only reboot would
> return the device to a sane state.
>
> It appears that it happens if rt61pci is unloaded while power saving is
> active. To initialize the device properly, SOFT_RESET_CSR should be set
> to the same value as rt61pci_config_ps() uses to wake up the device.
>
> Signed-off-by: Pavel Roskin <proski@gnu.org>
> ---
>
> I don't know what 0x00000007 is and I don't want to make up a name for
> it.
I'll look it up in the specification document.
> rt61pci_config_ps() does other things, but this is the minimal required
> change. If anyone has a specification for rt61, it should mention
> SOFT_RESET_CSR and possibly other registers to be set before EEPROM may
> be accessed.
>
> Please note that unloading rt61pci (as well as rt73usb) can trigger an
> oops or panic in sysfs code that I didn't have a chance to fix yet.
> It's very elusive and manifests differently every time. Fortunately
> (for everyone not debugging it), it's rare.
>
>
> drivers/net/wireless/rt2x00/rt61pci.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt61pci.c b/drivers/net/wireless/rt2x00/rt61pci.c
> index fb95b8c..f615fe6 100644
> --- a/drivers/net/wireless/rt2x00/rt61pci.c
> +++ b/drivers/net/wireless/rt2x00/rt61pci.c
> @@ -2600,6 +2600,8 @@ static int rt61pci_probe_hw(struct rt2x00_dev *rt2x00dev)
> {
> int retval;
>
> + rt2x00pci_register_write(rt2x00dev, SOFT_RESET_CSR, 0x00000007);
> +
> /*
> * Allocate eeprom data.
> */
The only comment about the patch at this time is that it might require a nice comment. ;)
I'll also think that perhaps a more generic approach is required where rt2x00lib forces
PS to be disabled before probe_hw(), just in case other hardware also have these problems.
Thanks,
Ivo
^ permalink raw reply
* Re: [PATCH] iwlwifi: don't export symbols not needed in other modules
From: reinette chatre @ 2009-07-30 18:47 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, linux-wireless
In-Reply-To: <1248979011.23496.4.camel@johannes.local>
On Thu, 2009-07-30 at 11:36 -0700, Johannes Berg wrote:
> On Thu, 2009-07-30 at 11:28 -0700, reinette chatre wrote:
> > Hi Johannes,
> >
> > On Thu, 2009-07-30 at 02:58 -0700, Johannes Berg wrote:
> > > Even with the split into iwlcore/agn/3945 not all symbols
> > > that cross file boundaries are needed in other modules, a
> > > few are only used within iwlcore, for example.
> >
> > I think in this case we need to be explicit when talking about "need"
> > and "used". Yes, some of these exported symbols are only used within a
> > module and this needs to be fixed. At the same time, some of these may
> > be needed outside, but are just not currently used. Examples of the
> > latter are: iwl_remove_station, iwl_rx_ant_restriction, and
> > iwl_send_card_state. I think this is especially important for
> > iwl_remove_station and iwl_rx_ant_restriction because their partners
> > (iwl_add_station and iwl_tx_ant_restriction) are exported and used and I
> > think it will be clean if they are also, even if they are not currently
> > used.
>
> But they can easily be exported when used. That's done even for
> subsystem symbols, for instance some generic netlink stuff wasn't
> exported until it was needed in wimax.
>
> Is there a problem with adding the export back whenever it's needed?
No. If this is what you want then I think you also need to remove
iwl_rx_ant_restriction.
Reinette
^ permalink raw reply
* Re: [PATCH] orinoco: enable cfg80211 "set_channel" operation
From: Dave @ 2009-07-30 18:47 UTC (permalink / raw)
To: Holger Schurig
Cc: linux-wireless, Pavel Roskin, orinoco-devel, John W. Linville
In-Reply-To: <200907290916.31603.hs4233@mail.mn-solutions.de>
Holger Schurig wrote:
> On Tuesday 28 July 2009 18:27:54 Dave wrote:
>> You can also eliminate orinoco_ioctl_setfreq from wext.c with
>> this change.
>
> You mean this ?!?
Yes, except:
> @@ -1481,7 +1432,6 @@
> static const iw_handler orinoco_handler[] = {
> STD_IW_HANDLER(SIOCSIWCOMMIT, orinoco_ioctl_commit),
> STD_IW_HANDLER(SIOCGIWNAME, cfg80211_wext_giwname),
> - STD_IW_HANDLER(SIOCSIWFREQ, orinoco_ioctl_setfreq),
+ STD_IW_HANDLER(SIOCSIWFREQ, cfg80211_wext_setfreq ish),
> STD_IW_HANDLER(SIOCGIWFREQ, orinoco_ioctl_getfreq),
> STD_IW_HANDLER(SIOCSIWMODE, cfg80211_wext_siwmode),
> STD_IW_HANDLER(SIOCGIWMODE, cfg80211_wext_giwmode),
>
> I tried, but with then an "iwconfig eth1 channel 1" gave me an
> error. I did not investigate this further.
And as Johannes pointed out, we need to have the non-cfg80211 version so
adhoc connections can still be made via wext.
So the original patch is fine as is. Ack from me.
Dave.
^ permalink raw reply
* Re: [PATCH] rt2x00dev: cancel all work on disconnect
From: Ivo van Doorn @ 2009-07-30 18:45 UTC (permalink / raw)
To: Pavel Roskin; +Cc: linux-wireless, John W. Linville, users, Michael Buesch
In-Reply-To: <20090729200711.3784.16212.stgit@mj.roinet.com>
Hi,
I assume fixes the bug Michael reported on Linux-wireless yesterday?
The patch looks good, but I have some minor modification request:
On Wednesday 29 July 2009, Pavel Roskin wrote:
> Signed-off-by: Pavel Roskin <proski@gnu.org>
> ---
> drivers/net/wireless/rt2x00/rt2x00dev.c | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
> index 658a63b..66b303b 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00dev.c
> +++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
> @@ -888,6 +888,13 @@ void rt2x00lib_remove_dev(struct rt2x00_dev *rt2x00dev)
> clear_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags);
>
> /*
> + * Cancel all work.
> + */
> + rt2x00link_stop_tuner(rt2x00dev);
This one isn't needed. rt2x00lib_disable_radio() is doing this.
> + cancel_work_sync(&rt2x00dev->filter_work);
> + cancel_work_sync(&rt2x00dev->intf_work);
Could you move these 2 until after the call to rt2x00lib_disable_radio()?
> + /*
> * Disable radio.
> */
> rt2x00lib_disable_radio(rt2x00dev);
Thanks,
Ivo
^ permalink raw reply
* Re: [PATCH] iwlwifi: don't export symbols not needed in other modules
From: Johannes Berg @ 2009-07-30 18:36 UTC (permalink / raw)
To: reinette chatre; +Cc: John Linville, linux-wireless
In-Reply-To: <1248978482.1216.1087.camel@rc-desk>
[-- Attachment #1: Type: text/plain, Size: 1230 bytes --]
On Thu, 2009-07-30 at 11:28 -0700, reinette chatre wrote:
> Hi Johannes,
>
> On Thu, 2009-07-30 at 02:58 -0700, Johannes Berg wrote:
> > Even with the split into iwlcore/agn/3945 not all symbols
> > that cross file boundaries are needed in other modules, a
> > few are only used within iwlcore, for example.
>
> I think in this case we need to be explicit when talking about "need"
> and "used". Yes, some of these exported symbols are only used within a
> module and this needs to be fixed. At the same time, some of these may
> be needed outside, but are just not currently used. Examples of the
> latter are: iwl_remove_station, iwl_rx_ant_restriction, and
> iwl_send_card_state. I think this is especially important for
> iwl_remove_station and iwl_rx_ant_restriction because their partners
> (iwl_add_station and iwl_tx_ant_restriction) are exported and used and I
> think it will be clean if they are also, even if they are not currently
> used.
But they can easily be exported when used. That's done even for
subsystem symbols, for instance some generic netlink stuff wasn't
exported until it was needed in wimax.
Is there a problem with adding the export back whenever it's needed?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] iwlwifi: don't export symbols not needed in other modules
From: reinette chatre @ 2009-07-30 18:28 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, linux-wireless
In-Reply-To: <1248947897.8925.13.camel@johannes.local>
Hi Johannes,
On Thu, 2009-07-30 at 02:58 -0700, Johannes Berg wrote:
> Even with the split into iwlcore/agn/3945 not all symbols
> that cross file boundaries are needed in other modules, a
> few are only used within iwlcore, for example.
I think in this case we need to be explicit when talking about "need"
and "used". Yes, some of these exported symbols are only used within a
module and this needs to be fixed. At the same time, some of these may
be needed outside, but are just not currently used. Examples of the
latter are: iwl_remove_station, iwl_rx_ant_restriction, and
iwl_send_card_state. I think this is especially important for
iwl_remove_station and iwl_rx_ant_restriction because their partners
(iwl_add_station and iwl_tx_ant_restriction) are exported and used and I
think it will be clean if they are also, even if they are not currently
used.
I'm thus ok with the removal of symbols iwl_set_flags_for_band,
iwl_clear_isr_stats, iwl_leds_background, and iwl_rx_queue_reset.
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> ---
> drivers/net/wireless/iwlwifi/iwl-core.c | 3 ---
> drivers/net/wireless/iwlwifi/iwl-led.c | 1 -
> drivers/net/wireless/iwlwifi/iwl-rx.c | 1 -
> drivers/net/wireless/iwlwifi/iwl-sta.c | 1 -
> 4 files changed, 6 deletions(-)
>
> --- wireless-testing.orig/drivers/net/wireless/iwlwifi/iwl-core.c 2009-07-30 11:42:11.000000000 +0200
> +++ wireless-testing/drivers/net/wireless/iwlwifi/iwl-core.c 2009-07-30 11:51:28.000000000 +0200
> @@ -1139,7 +1139,6 @@ void iwl_set_flags_for_band(struct iwl_p
> priv->staging_rxon.flags &= ~RXON_FLG_CCK_MSK;
> }
> }
> -EXPORT_SYMBOL(iwl_set_flags_for_band);
>
> /*
> * initialize rxon structure with default values from eeprom
> @@ -2289,7 +2288,6 @@ int iwl_send_card_state(struct iwl_priv
>
> return iwl_send_cmd(priv, &cmd);
> }
> -EXPORT_SYMBOL(iwl_send_card_state);
>
> void iwl_rx_pm_sleep_notif(struct iwl_priv *priv,
> struct iwl_rx_mem_buffer *rxb)
> @@ -2333,7 +2331,6 @@ void iwl_clear_isr_stats(struct iwl_priv
> {
> memset(&priv->isr_stats, 0, sizeof(priv->isr_stats));
> }
> -EXPORT_SYMBOL(iwl_clear_isr_stats);
>
> int iwl_mac_conf_tx(struct ieee80211_hw *hw, u16 queue,
> const struct ieee80211_tx_queue_params *params)
> --- wireless-testing.orig/drivers/net/wireless/iwlwifi/iwl-led.c 2009-07-30 11:42:11.000000000 +0200
> +++ wireless-testing/drivers/net/wireless/iwlwifi/iwl-led.c 2009-07-30 11:50:58.000000000 +0200
> @@ -335,7 +335,6 @@ void iwl_leds_background(struct iwl_priv
> priv->last_blink_time = jiffies;
> priv->last_blink_rate = blink_idx;
> }
> -EXPORT_SYMBOL(iwl_leds_background);
>
> /* Register all led handler */
> int iwl_leds_register(struct iwl_priv *priv)
> --- wireless-testing.orig/drivers/net/wireless/iwlwifi/iwl-rx.c 2009-07-30 11:42:11.000000000 +0200
> +++ wireless-testing/drivers/net/wireless/iwlwifi/iwl-rx.c 2009-07-30 11:51:15.000000000 +0200
> @@ -406,7 +406,6 @@ void iwl_rx_queue_reset(struct iwl_priv
> rxq->free_count = 0;
> spin_unlock_irqrestore(&rxq->lock, flags);
> }
> -EXPORT_SYMBOL(iwl_rx_queue_reset);
>
> int iwl_rx_init(struct iwl_priv *priv, struct iwl_rx_queue *rxq)
> {
> --- wireless-testing.orig/drivers/net/wireless/iwlwifi/iwl-sta.c 2009-07-30 11:42:11.000000000 +0200
> +++ wireless-testing/drivers/net/wireless/iwlwifi/iwl-sta.c 2009-07-30 11:51:07.000000000 +0200
> @@ -464,7 +464,6 @@ out:
> spin_unlock_irqrestore(&priv->sta_lock, flags);
> return ret;
> }
> -EXPORT_SYMBOL(iwl_remove_station);
>
> /**
> * iwl_clear_stations_table - Clear the driver's station table
>
>
Reinette
^ permalink raw reply
* Re: [wireless] rt2870sta BUGs on shutdown, 2.6.30.2->git.today+git.wireless.today
From: Greg KH @ 2009-07-30 18:13 UTC (permalink / raw)
To: Dan Williams
Cc: Johannes Berg, Ivo van Doorn, Bartlomiej Zolnierkiewicz,
Luis Correia, Mike Galbraith, linux-wireless, LKML,
John W. Linville
In-Reply-To: <1248977083.24886.4.camel@localhost.localdomain>
On Thu, Jul 30, 2009 at 02:04:43PM -0400, Dan Williams wrote:
> On Thu, 2009-07-30 at 10:26 -0700, Greg KH wrote:
> > On Thu, Jul 30, 2009 at 07:11:02PM +0200, Johannes Berg wrote:
> > > On Thu, 2009-07-30 at 18:52 +0200, Ivo van Doorn wrote:
> > >
> > > > [some text expressing his frustration]
> > >
> > > This is exactly why I was against staging all the time. Now suddenly
> > > "The Crap" seems like a viable alternative. WAKE UP PEOPLE. The code is
> > > not useful. Just look at the code that Mike pasted into his email. That
> > > alone should be enough to send cold shivers down your spine!
> >
> > Hm, "useful" is in the eye of the beholder.
> >
> > There is no driver in the mainline kernel tree for this device, so a
> > "normal" user has no chance of getting it working, right? That's why
> > -staging is working, there is a semi-working driver, and most
> > importantly, people willing to help out getting it working better.
> >
> > The combination of the two is what works here.
> >
> > So please, I understand your frustration on a lack of people helping out
> > with out-of-tree wireless drivers that don't quite work properly, but
> > please, that has NOTHING to do with the staging drivers.
> >
> > Meanwhile, I'm off on the driver-devel list helping Mike fix this
> > problem, which seems simple enough to solve...
>
> Except that the energy you're now investing in fixing this could have
> gone into rt2x00, and we would come out ahead in the end. Instead, the
> energy is sapped away by something that will *never* be mainlined.
On the contrary, I would have never spent any time working on rt2x00 :)
And are you trying to tell people _what_ to work on here? That's a
slippery slope...
thanks,
greg k-h
^ permalink raw reply
* Re: [wireless] rt2870sta BUGs on shutdown, 2.6.30.2->git.today+git.wireless.today
From: Dan Williams @ 2009-07-30 18:04 UTC (permalink / raw)
To: Greg KH
Cc: Johannes Berg, Ivo van Doorn, Bartlomiej Zolnierkiewicz,
Luis Correia, Mike Galbraith, linux-wireless, LKML,
John W. Linville
In-Reply-To: <20090730172657.GA8266@kroah.com>
On Thu, 2009-07-30 at 10:26 -0700, Greg KH wrote:
> On Thu, Jul 30, 2009 at 07:11:02PM +0200, Johannes Berg wrote:
> > On Thu, 2009-07-30 at 18:52 +0200, Ivo van Doorn wrote:
> >
> > > [some text expressing his frustration]
> >
> > This is exactly why I was against staging all the time. Now suddenly
> > "The Crap" seems like a viable alternative. WAKE UP PEOPLE. The code is
> > not useful. Just look at the code that Mike pasted into his email. That
> > alone should be enough to send cold shivers down your spine!
>
> Hm, "useful" is in the eye of the beholder.
>
> There is no driver in the mainline kernel tree for this device, so a
> "normal" user has no chance of getting it working, right? That's why
> -staging is working, there is a semi-working driver, and most
> importantly, people willing to help out getting it working better.
>
> The combination of the two is what works here.
>
> So please, I understand your frustration on a lack of people helping out
> with out-of-tree wireless drivers that don't quite work properly, but
> please, that has NOTHING to do with the staging drivers.
>
> Meanwhile, I'm off on the driver-devel list helping Mike fix this
> problem, which seems simple enough to solve...
Except that the energy you're now investing in fixing this could have
gone into rt2x00, and we would come out ahead in the end. Instead, the
energy is sapped away by something that will *never* be mainlined.
Dan
> > What staging has achieved here is giving the crap vendor code a
> > blessing, receiving it welcomingly and forgivingly instead of saying
> > "well screw you, go ahead and ship this to your users but don't ever say
> > you support Linux well" ... now even some hackers and just just "dumb
> > users" think that the crap in staging could possibly at some point
> > become useful code!
>
> Odd, I don't seem to be giving anyone such a "blessing", you are reading
> way too much into this. The fact is this vendor does code drops and
> runs away all the time, despite the code being in the staging tree or
> not. Without it in the staging tree users would be worse off, not
> better, there is no pressure able to be applied here at all, so please
> stop thinking that.
>
> > It won't. EVER. No matter _how_ much you clean it up, it will NEVER fit
> > into the code scheme that everything else wireless has adopted.
>
> never say never, it will happen, just give us time :)
>
> In the meanwhile, people like Bart and others are doing real work on
> getting the staging code into shape and working for real users. Who are
> you to tell them to not do such work?
>
> thanks,
>
> greg "i love crap" k-h
> --
> 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
^ permalink raw reply
* Re: [PATCH] mac80211: use beacons for connection monitoring
From: reinette chatre @ 2009-07-30 17:45 UTC (permalink / raw)
To: Johannes Berg
Cc: Ben Greear, linville@tuxdriver.com,
linux-wireless@vger.kernel.org
In-Reply-To: <1248949853.29062.3.camel@johannes.local>
On Thu, 2009-07-30 at 03:30 -0700, Johannes Berg wrote:
> On Wed, 2009-07-29 at 14:39 -0700, Ben Greear wrote:
> > On 07/29/2009 02:32 PM, Reinette Chatre wrote:
> > > From: Reinette Chatre<reinette.chatre@intel.com>
> > >
> > > The connection monitor currently relies on probe requests paired
> > > with probe responses to ensure that a connection is alive. This is
> > > fragile in some environments where probe responses can get lost.
> > > When we receive beacons we can also consider the connection to be
> > > alive, so cancel connection poll instance when we receive a beacon.
> >
> > I'm chasing a similar problem while working on virtual STA device
> > support in ath5k. I was also going to try sending up to 3 polls before
> > giving up on the connection. Does that seems like a valid thing to do?
>
> That seems somewhat better, yeah.
>
> I suspect the real cause of the issue is something else though, like the
> probe request not going out properly or the card being in a kind of
> 'temporary lock-up' state where it's not really doing anything for the
> time being -- I've never had a problem on any other (than iwlwifi)
> hardware.
I captured the exchange when this problem occurs using a third system.
The card does indeed try several times to send a probe request and they
are making it out over the air. The AP never responds.
Is there perhaps anything in this exchange that can help us understand
what is going on?
No. Time Source Destination Protocol Info
163883 401.891153 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Probe Request, SN=980, FN=0, Flags=........, SSID="XXX"
163885 401.891482 00:14:f2:XX:XX:XX 00:16:ea:XX:XX:XX IEEE 802.11 Probe Response, SN=3557, FN=0, Flags=........, BI=100, SSID="XXX"
165523 404.884405 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Probe Request, SN=981, FN=0, Flags=........, SSID="XXX"
165525 404.885265 00:14:f2:XX:XX:XX 00:16:ea:XX:XX:XX IEEE 802.11 Probe Response, SN=3827, FN=0, Flags=....R..., BI=100, SSID="XXX"
166981 407.884161 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Probe Request, SN=982, FN=0, Flags=........, SSID="XXX"
166983 407.884555 00:14:f2:XX:XX:XX 00:16:ea:XX:XX:XX IEEE 802.11 Probe Response, SN=4034, FN=0, Flags=........, BI=100, SSID="XXX"
168133 410.884167 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Probe Request, SN=983, FN=0, Flags=........, SSID="XXX"
168134 410.884430 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Probe Request, SN=983, FN=0, Flags=....R..., SSID="XXX"
168135 410.884643 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Probe Request, SN=983, FN=0, Flags=....R..., SSID="XXX"
168136 410.884904 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Probe Request, SN=983, FN=0, Flags=....R..., SSID="XXX"
168137 410.885073 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Probe Request, SN=983, FN=0, Flags=....R..., SSID="XXX"
168138 410.885330 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Probe Request, SN=983, FN=0, Flags=....R..., SSID="XXX"
168139 410.885580 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Probe Request, SN=983, FN=0, Flags=....R..., SSID="XXX"
168140 410.885769 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Probe Request, SN=983, FN=0, Flags=....R..., SSID="XXX"
168141 410.886618 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Probe Request, SN=983, FN=0, Flags=....R..., SSID="XXX"
168142 410.887087 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Probe Request, SN=983, FN=0, Flags=....R..., SSID="XXX"
168143 410.887308 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Probe Request, SN=983, FN=0, Flags=....R..., SSID="XXX"
168144 410.887532 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Probe Request, SN=983, FN=0, Flags=....R..., SSID="XXX"
168191 411.084889 00:16:ea:XX:XX:XX 00:14:f2:XX:XX:XX IEEE 802.11 Deauthentication, SN=984, FN=0, Flags=........
Reinette
^ permalink raw reply
* Re: pull request: wireless-2.6 2009-07-29
From: David Miller @ 2009-07-30 17:36 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20090729203007.GB10056@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 29 Jul 2009 16:30:07 -0400
> Here is a small collection of fixes intended for 2.6.31. Several of
> them are small fixes dug-out by the usual static analysis suspects.
> There are also a couple of iwlwifi fixes that the Intel team thinks are
> important -- they look reasonably safe to me and they should only effect
> their drivers. Their are also some small fixes from Luis and Johannes.
Pulled, thanks John.
^ permalink raw reply
* [PATCH v3 3/3] cfg80211: enable country IE support to all cfg80211 drivers
From: Luis R. Rodriguez @ 2009-07-30 17:30 UTC (permalink / raw)
To: linville, johannes; +Cc: linux-wireless, Luis R. Rodriguez
Since the bss is always set now once we are connected, if the
bss has its own information element we refer to it and pass that
instead of relying on mac80211's parsing.
Now all cfg80211 drivers get country IE support, automatically.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
Fixes comment for ieee80211_bss_get_ie() usage.
include/net/cfg80211.h | 14 --------------
net/mac80211/mlme.c | 6 +-----
net/wireless/reg.c | 1 -
net/wireless/reg.h | 15 +++++++++++++++
net/wireless/sme.c | 16 ++++++++++++++++
5 files changed, 32 insertions(+), 20 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index e1b9235..fa72997 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1514,20 +1514,6 @@ unsigned int cfg80211_classify8021d(struct sk_buff *skb);
extern int regulatory_hint(struct wiphy *wiphy, const char *alpha2);
/**
- * regulatory_hint_11d - hints a country IE as a regulatory domain
- * @wiphy: the wireless device giving the hint (used only for reporting
- * conflicts)
- * @country_ie: pointer to the country IE
- * @country_ie_len: length of the country IE
- *
- * We will intersect the rd with the what CRDA tells us should apply
- * for the alpha2 this country IE belongs to, this prevents APs from
- * sending us incorrect or outdated information against a country.
- */
-extern void regulatory_hint_11d(struct wiphy *wiphy,
- u8 *country_ie,
- u8 country_ie_len);
-/**
* wiphy_apply_custom_regulatory - apply a custom driver regulatory domain
* @wiphy: the wireless device we want to process the regulatory domain on
* @regd: the custom regulatory domain to use for this wiphy
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 0779ba1..5ff1496 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1846,12 +1846,8 @@ static void ieee80211_rx_mgmt_beacon(struct ieee80211_sub_if_data *sdata,
bssid, ap_ht_cap_flags);
}
+ /* Note: country IE parsing is done for us by cfg80211 */
if (elems.country_elem) {
- /* Note we are only reviewing this on beacons
- * for the BSSID we are associated to */
- regulatory_hint_11d(local->hw.wiphy,
- elems.country_elem, elems.country_elem_len);
-
/* TODO: IBSS also needs this */
if (elems.pwr_constr_elem)
ieee80211_handle_pwr_constr(sdata,
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 14e0c87..06abd7a 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1911,7 +1911,6 @@ free_rd_out:
out:
mutex_unlock(®_mutex);
}
-EXPORT_SYMBOL(regulatory_hint_11d);
static bool freq_is_chan_12_13_14(u16 freq)
{
diff --git a/net/wireless/reg.h b/net/wireless/reg.h
index e37829a..662a9da 100644
--- a/net/wireless/reg.h
+++ b/net/wireless/reg.h
@@ -36,4 +36,19 @@ int regulatory_hint_found_beacon(struct wiphy *wiphy,
struct ieee80211_channel *beacon_chan,
gfp_t gfp);
+/**
+ * regulatory_hint_11d - hints a country IE as a regulatory domain
+ * @wiphy: the wireless device giving the hint (used only for reporting
+ * conflicts)
+ * @country_ie: pointer to the country IE
+ * @country_ie_len: length of the country IE
+ *
+ * We will intersect the rd with the what CRDA tells us should apply
+ * for the alpha2 this country IE belongs to, this prevents APs from
+ * sending us incorrect or outdated information against a country.
+ */
+void regulatory_hint_11d(struct wiphy *wiphy,
+ u8 *country_ie,
+ u8 country_ie_len);
+
#endif /* __NET_WIRELESS_REG_H */
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index 3728d2b..bc0fb7d 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -13,6 +13,7 @@
#include <net/cfg80211.h>
#include <net/rtnetlink.h>
#include "nl80211.h"
+#include "reg.h"
struct cfg80211_conn {
struct cfg80211_connect_params params;
@@ -320,6 +321,7 @@ void __cfg80211_connect_result(struct net_device *dev, const u8 *bssid,
struct cfg80211_bss *bss)
{
struct wireless_dev *wdev = dev->ieee80211_ptr;
+ u8 *country_ie;
#ifdef CONFIG_WIRELESS_EXT
union iwreq_data wrqu;
#endif
@@ -401,6 +403,20 @@ void __cfg80211_connect_result(struct net_device *dev, const u8 *bssid,
wdev->sme_state = CFG80211_SME_CONNECTED;
cfg80211_upload_connect_keys(wdev);
+
+ country_ie = (u8 *) ieee80211_bss_get_ie(bss, WLAN_EID_COUNTRY);
+
+ if (!country_ie)
+ return;
+
+ /*
+ * ieee80211_bss_get_ie() ensures we can access:
+ * - country_ie + 2, the start of the country ie data, and
+ * - and country_ie[1] which is the IE length
+ */
+ regulatory_hint_11d(wdev->wiphy,
+ country_ie + 2,
+ country_ie[1]);
}
void cfg80211_connect_result(struct net_device *dev, const u8 *bssid,
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH v2 3/3] cfg80211: enable country IE support to all cfg80211 drivers
From: Johannes Berg @ 2009-07-30 17:28 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <1248974386-8168-4-git-send-email-lrodriguez@atheros.com>
[-- Attachment #1: Type: text/plain, Size: 5192 bytes --]
On Thu, 2009-07-30 at 10:19 -0700, Luis R. Rodriguez wrote:
> Since the bss is always set now once we are connected, if the
> bss has its own information element we refer to it and pass that
> instead of relying on mac80211's parsing.
>
> Now all cfg80211 drivers get country IE support, automatically.
Cool, thanks.
Acked-by: Johannes Berg <johannes@sipsolutions.net>
>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
> include/net/cfg80211.h | 14 --------------
> net/mac80211/mlme.c | 6 +-----
> net/wireless/reg.c | 1 -
> net/wireless/reg.h | 15 +++++++++++++++
> net/wireless/sme.c | 16 ++++++++++++++++
> 5 files changed, 32 insertions(+), 20 deletions(-)
>
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index e1b9235..fa72997 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -1514,20 +1514,6 @@ unsigned int cfg80211_classify8021d(struct sk_buff *skb);
> extern int regulatory_hint(struct wiphy *wiphy, const char *alpha2);
>
> /**
> - * regulatory_hint_11d - hints a country IE as a regulatory domain
> - * @wiphy: the wireless device giving the hint (used only for reporting
> - * conflicts)
> - * @country_ie: pointer to the country IE
> - * @country_ie_len: length of the country IE
> - *
> - * We will intersect the rd with the what CRDA tells us should apply
> - * for the alpha2 this country IE belongs to, this prevents APs from
> - * sending us incorrect or outdated information against a country.
> - */
> -extern void regulatory_hint_11d(struct wiphy *wiphy,
> - u8 *country_ie,
> - u8 country_ie_len);
> -/**
> * wiphy_apply_custom_regulatory - apply a custom driver regulatory domain
> * @wiphy: the wireless device we want to process the regulatory domain on
> * @regd: the custom regulatory domain to use for this wiphy
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index 0779ba1..5ff1496 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -1846,12 +1846,8 @@ static void ieee80211_rx_mgmt_beacon(struct ieee80211_sub_if_data *sdata,
> bssid, ap_ht_cap_flags);
> }
>
> + /* Note: country IE parsing is done for us by cfg80211 */
> if (elems.country_elem) {
> - /* Note we are only reviewing this on beacons
> - * for the BSSID we are associated to */
> - regulatory_hint_11d(local->hw.wiphy,
> - elems.country_elem, elems.country_elem_len);
> -
> /* TODO: IBSS also needs this */
> if (elems.pwr_constr_elem)
> ieee80211_handle_pwr_constr(sdata,
> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
> index 14e0c87..06abd7a 100644
> --- a/net/wireless/reg.c
> +++ b/net/wireless/reg.c
> @@ -1911,7 +1911,6 @@ free_rd_out:
> out:
> mutex_unlock(®_mutex);
> }
> -EXPORT_SYMBOL(regulatory_hint_11d);
>
> static bool freq_is_chan_12_13_14(u16 freq)
> {
> diff --git a/net/wireless/reg.h b/net/wireless/reg.h
> index e37829a..662a9da 100644
> --- a/net/wireless/reg.h
> +++ b/net/wireless/reg.h
> @@ -36,4 +36,19 @@ int regulatory_hint_found_beacon(struct wiphy *wiphy,
> struct ieee80211_channel *beacon_chan,
> gfp_t gfp);
>
> +/**
> + * regulatory_hint_11d - hints a country IE as a regulatory domain
> + * @wiphy: the wireless device giving the hint (used only for reporting
> + * conflicts)
> + * @country_ie: pointer to the country IE
> + * @country_ie_len: length of the country IE
> + *
> + * We will intersect the rd with the what CRDA tells us should apply
> + * for the alpha2 this country IE belongs to, this prevents APs from
> + * sending us incorrect or outdated information against a country.
> + */
> +void regulatory_hint_11d(struct wiphy *wiphy,
> + u8 *country_ie,
> + u8 country_ie_len);
> +
> #endif /* __NET_WIRELESS_REG_H */
> diff --git a/net/wireless/sme.c b/net/wireless/sme.c
> index 3728d2b..bc0fb7d 100644
> --- a/net/wireless/sme.c
> +++ b/net/wireless/sme.c
> @@ -13,6 +13,7 @@
> #include <net/cfg80211.h>
> #include <net/rtnetlink.h>
> #include "nl80211.h"
> +#include "reg.h"
>
> struct cfg80211_conn {
> struct cfg80211_connect_params params;
> @@ -320,6 +321,7 @@ void __cfg80211_connect_result(struct net_device *dev, const u8 *bssid,
> struct cfg80211_bss *bss)
> {
> struct wireless_dev *wdev = dev->ieee80211_ptr;
> + u8 *country_ie;
> #ifdef CONFIG_WIRELESS_EXT
> union iwreq_data wrqu;
> #endif
> @@ -401,6 +403,20 @@ void __cfg80211_connect_result(struct net_device *dev, const u8 *bssid,
>
> wdev->sme_state = CFG80211_SME_CONNECTED;
> cfg80211_upload_connect_keys(wdev);
> +
> + country_ie = (u8 *) ieee80211_bss_get_ie(bss, WLAN_EID_COUNTRY);
> +
> + if (!country_ie)
> + return;
> +
> + /*
> + * ieee80211_bss_get()_ie ensures we can access:
> + * - country_ie + 2, the start of the country ie data, and
> + * - and country_ie[1] which is the IE length
> + */
> + regulatory_hint_11d(wdev->wiphy,
> + country_ie + 2,
> + country_ie[1]);
> }
>
> void cfg80211_connect_result(struct net_device *dev, const u8 *bssid,
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] cfg80211: decouple regulatory variables from cfg80211_mutex
From: Johannes Berg @ 2009-07-30 17:28 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <1248974386-8168-3-git-send-email-lrodriguez@atheros.com>
[-- Attachment #1: Type: text/plain, Size: 11171 bytes --]
On Thu, 2009-07-30 at 10:19 -0700, Luis R. Rodriguez wrote:
> We change regulatory code to be protected by its own regulatory
> mutex and alleviate cfg80211_mutex to only be used to protect
> cfg80211_rdev_list, the registered device list.
>
> By doing this we will be able to work on regulatory core components
> without having to have hog up the cfg80211_mutex. An example here is
> we no longer need to use the cfg80211_mutex during driver specific
> wiphy_apply_custom_regulatory(). We also no longer need it for the
> the country IE regulatory hint; by doing so we end up curing this
> new lockdep warning:
Nice.
Acked-by: Johannes Berg <johannes@sipsolutions.net>
> =======================================================
> [ INFO: possible circular locking dependency detected ]
> 2.6.31-rc4-wl #12
> -------------------------------------------------------
> phy1/1709 is trying to acquire lock:
> (cfg80211_mutex){+.+.+.}, at: [<ffffffffa00af852>] regulatory_hint_11d+0x32/0x3f0 [cfg80211]
>
> but task is already holding lock:
> (&ifmgd->mtx){+.+.+.}, at: [<ffffffffa0144228>] ieee80211_sta_work+0x108/0x10f0 [mac80211]
>
> which lock already depends on the new lock.
>
> the existing dependency chain (in reverse order) is:
>
> -> #3 (&ifmgd->mtx){+.+.+.}:
> [<ffffffff810857b6>] __lock_acquire+0xd76/0x12b0
> [<ffffffff81085dd3>] lock_acquire+0xe3/0x120
> [<ffffffff814eeae4>] mutex_lock_nested+0x44/0x350
> [<ffffffffa0141bb8>] ieee80211_mgd_auth+0x108/0x1f0 [mac80211]
> [<ffffffffa0148563>] ieee80211_auth+0x13/0x20 [mac80211]
> [<ffffffffa00bc3a1>] __cfg80211_mlme_auth+0x1b1/0x2a0 [cfg80211]
> [<ffffffffa00bc516>] cfg80211_mlme_auth+0x86/0xc0 [cfg80211]
> [<ffffffffa00b368d>] nl80211_authenticate+0x21d/0x230 [cfg80211]
> [<ffffffff81416ba6>] genl_rcv_msg+0x1b6/0x1f0
> [<ffffffff81415c39>] netlink_rcv_skb+0x89/0xb0
> [<ffffffff814169d9>] genl_rcv+0x29/0x40
> [<ffffffff8141591d>] netlink_unicast+0x29d/0x2b0
> [<ffffffff81416514>] netlink_sendmsg+0x214/0x300
> [<ffffffff813e4407>] sock_sendmsg+0x107/0x130
> [<ffffffff813e45b9>] sys_sendmsg+0x189/0x320
> [<ffffffff81011f82>] system_call_fastpath+0x16/0x1b
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> -> #2 (&wdev->mtx){+.+.+.}:
> [<ffffffff810857b6>] __lock_acquire+0xd76/0x12b0
> [<ffffffff81085dd3>] lock_acquire+0xe3/0x120
> [<ffffffff814eeae4>] mutex_lock_nested+0x44/0x350
> [<ffffffffa00ab304>] cfg80211_netdev_notifier_call+0x1a4/0x390 [cfg80211]
> [<ffffffff814f3dff>] notifier_call_chain+0x3f/0x80
> [<ffffffff81075a91>] raw_notifier_call_chain+0x11/0x20
> [<ffffffff813f665a>] dev_open+0x10a/0x120
> [<ffffffff813f59bd>] dev_change_flags+0x9d/0x1e0
> [<ffffffff8144eb6e>] devinet_ioctl+0x6fe/0x760
> [<ffffffff81450204>] inet_ioctl+0x94/0xc0
> [<ffffffff813e25fa>] sock_ioctl+0x6a/0x290
> [<ffffffff8111e911>] vfs_ioctl+0x31/0xa0
> [<ffffffff8111ea9a>] do_vfs_ioctl+0x8a/0x5c0
> [<ffffffff8111f069>] sys_ioctl+0x99/0xa0
> [<ffffffff81011f82>] system_call_fastpath+0x16/0x1b
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> -> #1 (&rdev->mtx){+.+.+.}:
> [<ffffffff810857b6>] __lock_acquire+0xd76/0x12b0
> [<ffffffff81085dd3>] lock_acquire+0xe3/0x120
> [<ffffffff814eeae4>] mutex_lock_nested+0x44/0x350
> [<ffffffffa00ac4d0>] cfg80211_get_dev_from_ifindex+0x60/0x90 [cfg80211]
> [<ffffffffa00b21ff>] get_rdev_dev_by_info_ifindex+0x6f/0xa0 [cfg80211]
> [<ffffffffa00b51eb>] nl80211_set_interface+0x3b/0x260 [cfg80211]
> [<ffffffff81416ba6>] genl_rcv_msg+0x1b6/0x1f0
> [<ffffffff81415c39>] netlink_rcv_skb+0x89/0xb0
> [<ffffffff814169d9>] genl_rcv+0x29/0x40
> [<ffffffff8141591d>] netlink_unicast+0x29d/0x2b0
> [<ffffffff81416514>] netlink_sendmsg+0x214/0x300
> [<ffffffff813e4407>] sock_sendmsg+0x107/0x130
> [<ffffffff813e45b9>] sys_sendmsg+0x189/0x320
> [<ffffffff81011f82>] system_call_fastpath+0x16/0x1b
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> other info that might help us debug this:
>
> 3 locks held by phy1/1709:
> #0: ((wiphy_name(local->hw.wiphy))){+.+.+.}, at: [<ffffffff8106b45d>] worker_thread+0x19d/0x340
> #1: (&ifmgd->work){+.+.+.}, at: [<ffffffff8106b45d>] worker_thread+0x19d/0x340
> #2: (&ifmgd->mtx){+.+.+.}, at: [<ffffffffa0144228>] ieee80211_sta_work+0x108/0x10f0 [mac80211]
>
> Reported-by: Reinette Chatre <reinette.chatre@intel.com>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
> net/wireless/core.c | 4 +---
> net/wireless/reg.c | 46 +++++++++++++++++++++++++++++++++++++---------
> 2 files changed, 38 insertions(+), 12 deletions(-)
>
> diff --git a/net/wireless/core.c b/net/wireless/core.c
> index 755cdf1..d8dbd7f 100644
> --- a/net/wireless/core.c
> +++ b/net/wireless/core.c
> @@ -34,9 +34,7 @@ MODULE_DESCRIPTION("wireless configuration support");
> LIST_HEAD(cfg80211_rdev_list);
>
> /*
> - * This is used to protect the cfg80211_rdev_list, cfg80211_regdomain,
> - * country_ie_regdomain, the reg_beacon_list and the the last regulatory
> - * request receipt (last_request).
> + * This is used to protect the cfg80211_rdev_list
> */
> DEFINE_MUTEX(cfg80211_mutex);
>
> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
> index 2d1d183..14e0c87 100644
> --- a/net/wireless/reg.c
> +++ b/net/wireless/reg.c
> @@ -62,6 +62,16 @@ const struct ieee80211_regdomain *cfg80211_regdomain;
> */
> static const struct ieee80211_regdomain *country_ie_regdomain;
>
> +/*
> + * Protects static reg.c components:
> + * - cfg80211_world_regdom
> + * - cfg80211_regdom
> + * - country_ie_regdomain
> + * - last_request
> + */
> +DEFINE_MUTEX(reg_mutex);
> +#define assert_reg_lock() WARN_ON(!mutex_is_locked(®_mutex))
> +
> /* Used to queue up regulatory hints */
> static LIST_HEAD(reg_requests_list);
> static spinlock_t reg_requests_lock;
> @@ -1293,7 +1303,7 @@ static void handle_channel_custom(struct wiphy *wiphy,
> struct ieee80211_supported_band *sband;
> struct ieee80211_channel *chan;
>
> - assert_cfg80211_lock();
> + assert_reg_lock();
>
> sband = wiphy->bands[band];
> BUG_ON(chan_idx >= sband->n_channels);
> @@ -1342,14 +1352,14 @@ void wiphy_apply_custom_regulatory(struct wiphy *wiphy,
> enum ieee80211_band band;
> unsigned int bands_set = 0;
>
> - mutex_lock(&cfg80211_mutex);
> + mutex_lock(®_mutex);
> for (band = 0; band < IEEE80211_NUM_BANDS; band++) {
> if (!wiphy->bands[band])
> continue;
> handle_band_custom(wiphy, band, regd);
> bands_set++;
> }
> - mutex_unlock(&cfg80211_mutex);
> + mutex_unlock(®_mutex);
>
> /*
> * no point in calling this if it won't have any effect
> @@ -1495,7 +1505,7 @@ static int ignore_request(struct wiphy *wiphy,
> * Returns zero if all went fine, %-EALREADY if a regulatory domain had
> * already been set or other standard error codes.
> *
> - * Caller must hold &cfg80211_mutex
> + * Caller must hold &cfg80211_mutex and ®_mutex
> */
> static int __regulatory_hint(struct wiphy *wiphy,
> struct regulatory_request *pending_request)
> @@ -1570,6 +1580,7 @@ static void reg_process_hint(struct regulatory_request *reg_request)
> BUG_ON(!reg_request->alpha2);
>
> mutex_lock(&cfg80211_mutex);
> + mutex_lock(®_mutex);
>
> if (wiphy_idx_valid(reg_request->wiphy_idx))
> wiphy = wiphy_idx_to_wiphy(reg_request->wiphy_idx);
> @@ -1585,6 +1596,7 @@ static void reg_process_hint(struct regulatory_request *reg_request)
> if (r == -EALREADY && wiphy && wiphy->strict_regulatory)
> wiphy_update_regulatory(wiphy, reg_request->initiator);
> out:
> + mutex_unlock(®_mutex);
> mutex_unlock(&cfg80211_mutex);
> }
>
> @@ -1613,6 +1625,10 @@ static void reg_process_pending_beacon_hints(void)
> struct cfg80211_registered_device *rdev;
> struct reg_beacon *pending_beacon, *tmp;
>
> + /*
> + * No need to hold the reg_mutex here as we just touch wiphys
> + * and do not read or access regulatory variables.
> + */
> mutex_lock(&cfg80211_mutex);
>
> /* This goes through the _pending_ beacon list */
> @@ -1734,12 +1750,13 @@ int regulatory_hint(struct wiphy *wiphy, const char *alpha2)
> }
> EXPORT_SYMBOL(regulatory_hint);
>
> +/* Caller must hold reg_mutex */
> static bool reg_same_country_ie_hint(struct wiphy *wiphy,
> u32 country_ie_checksum)
> {
> struct wiphy *request_wiphy;
>
> - assert_cfg80211_lock();
> + assert_reg_lock();
>
> if (unlikely(last_request->initiator !=
> NL80211_REGDOM_SET_BY_COUNTRY_IE))
> @@ -1772,7 +1789,7 @@ void regulatory_hint_11d(struct wiphy *wiphy,
> enum environment_cap env = ENVIRON_ANY;
> struct regulatory_request *request;
>
> - mutex_lock(&cfg80211_mutex);
> + mutex_lock(®_mutex);
>
> if (unlikely(!last_request))
> goto out;
> @@ -1883,7 +1900,7 @@ void regulatory_hint_11d(struct wiphy *wiphy,
> request->country_ie_checksum = checksum;
> request->country_ie_env = env;
>
> - mutex_unlock(&cfg80211_mutex);
> + mutex_unlock(®_mutex);
>
> queue_regulatory_request(request);
>
> @@ -1892,7 +1909,7 @@ void regulatory_hint_11d(struct wiphy *wiphy,
> free_rd_out:
> kfree(rd);
> out:
> - mutex_unlock(&cfg80211_mutex);
> + mutex_unlock(®_mutex);
> }
> EXPORT_SYMBOL(regulatory_hint_11d);
>
> @@ -2225,10 +2242,13 @@ int set_regdom(const struct ieee80211_regdomain *rd)
>
> assert_cfg80211_lock();
>
> + mutex_lock(®_mutex);
> +
> /* Note that this doesn't update the wiphys, this is done below */
> r = __set_regdom(rd);
> if (r) {
> kfree(rd);
> + mutex_unlock(®_mutex);
> return r;
> }
>
> @@ -2243,6 +2263,8 @@ int set_regdom(const struct ieee80211_regdomain *rd)
>
> nl80211_send_reg_change_event(last_request);
>
> + mutex_unlock(®_mutex);
> +
> return r;
> }
>
> @@ -2253,16 +2275,20 @@ void reg_device_remove(struct wiphy *wiphy)
>
> assert_cfg80211_lock();
>
> + mutex_lock(®_mutex);
> +
> kfree(wiphy->regd);
>
> if (last_request)
> request_wiphy = wiphy_idx_to_wiphy(last_request->wiphy_idx);
>
> if (!request_wiphy || request_wiphy != wiphy)
> - return;
> + goto out;
>
> last_request->wiphy_idx = WIPHY_IDX_STALE;
> last_request->country_ie_env = ENVIRON_ANY;
> +out:
> + mutex_unlock(®_mutex);
> }
>
> int regulatory_init(void)
> @@ -2323,6 +2349,7 @@ void regulatory_exit(void)
> cancel_work_sync(®_work);
>
> mutex_lock(&cfg80211_mutex);
> + mutex_lock(®_mutex);
>
> reset_regdomains();
>
> @@ -2361,5 +2388,6 @@ void regulatory_exit(void)
> }
> spin_unlock(®_requests_lock);
>
> + mutex_unlock(®_mutex);
> mutex_unlock(&cfg80211_mutex);
> }
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] cfg80211: use goto out on 11d reg hint failure
From: Johannes Berg @ 2009-07-30 17:27 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <1248974386-8168-2-git-send-email-lrodriguez@atheros.com>
[-- Attachment #1: Type: text/plain, Size: 815 bytes --]
On Thu, 2009-07-30 at 10:19 -0700, Luis R. Rodriguez wrote:
> This does not change functionality.
>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
> ---
> net/wireless/reg.c | 6 ++----
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
> index fb40428..2d1d183 100644
> --- a/net/wireless/reg.c
> +++ b/net/wireless/reg.c
> @@ -1774,10 +1774,8 @@ void regulatory_hint_11d(struct wiphy *wiphy,
>
> mutex_lock(&cfg80211_mutex);
>
> - if (unlikely(!last_request)) {
> - mutex_unlock(&cfg80211_mutex);
> - return;
> - }
> + if (unlikely(!last_request))
> + goto out;
>
> /* IE len must be evenly divisible by 2 */
> if (country_ie_len & 0x01)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [wireless] rt2870sta BUGs on shutdown, 2.6.30.2->git.today+git.wireless.today
From: Greg KH @ 2009-07-30 17:26 UTC (permalink / raw)
To: Johannes Berg
Cc: Ivo van Doorn, Bartlomiej Zolnierkiewicz, Luis Correia,
Mike Galbraith, linux-wireless, LKML, John W. Linville
In-Reply-To: <1248973862.22552.4.camel@johannes.local>
On Thu, Jul 30, 2009 at 07:11:02PM +0200, Johannes Berg wrote:
> On Thu, 2009-07-30 at 18:52 +0200, Ivo van Doorn wrote:
>
> > [some text expressing his frustration]
>
> This is exactly why I was against staging all the time. Now suddenly
> "The Crap" seems like a viable alternative. WAKE UP PEOPLE. The code is
> not useful. Just look at the code that Mike pasted into his email. That
> alone should be enough to send cold shivers down your spine!
Hm, "useful" is in the eye of the beholder.
There is no driver in the mainline kernel tree for this device, so a
"normal" user has no chance of getting it working, right? That's why
-staging is working, there is a semi-working driver, and most
importantly, people willing to help out getting it working better.
The combination of the two is what works here.
So please, I understand your frustration on a lack of people helping out
with out-of-tree wireless drivers that don't quite work properly, but
please, that has NOTHING to do with the staging drivers.
Meanwhile, I'm off on the driver-devel list helping Mike fix this
problem, which seems simple enough to solve...
> What staging has achieved here is giving the crap vendor code a
> blessing, receiving it welcomingly and forgivingly instead of saying
> "well screw you, go ahead and ship this to your users but don't ever say
> you support Linux well" ... now even some hackers and just just "dumb
> users" think that the crap in staging could possibly at some point
> become useful code!
Odd, I don't seem to be giving anyone such a "blessing", you are reading
way too much into this. The fact is this vendor does code drops and
runs away all the time, despite the code being in the staging tree or
not. Without it in the staging tree users would be worse off, not
better, there is no pressure able to be applied here at all, so please
stop thinking that.
> It won't. EVER. No matter _how_ much you clean it up, it will NEVER fit
> into the code scheme that everything else wireless has adopted.
never say never, it will happen, just give us time :)
In the meanwhile, people like Bart and others are doing real work on
getting the staging code into shape and working for real users. Who are
you to tell them to not do such work?
thanks,
greg "i love crap" k-h
^ permalink raw reply
* [PATCH v2 3/3] cfg80211: enable country IE support to all cfg80211 drivers
From: Luis R. Rodriguez @ 2009-07-30 17:22 UTC (permalink / raw)
To: linville, johannes; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <1248974562-8315-1-git-send-email-lrodriguez@atheros.com>
Since the bss is always set now once we are connected, if the
bss has its own information element we refer to it and pass that
instead of relying on mac80211's parsing.
Now all cfg80211 drivers get country IE support, automatically.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
include/net/cfg80211.h | 14 --------------
net/mac80211/mlme.c | 6 +-----
net/wireless/reg.c | 1 -
net/wireless/reg.h | 15 +++++++++++++++
net/wireless/sme.c | 16 ++++++++++++++++
5 files changed, 32 insertions(+), 20 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index e1b9235..fa72997 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1514,20 +1514,6 @@ unsigned int cfg80211_classify8021d(struct sk_buff *skb);
extern int regulatory_hint(struct wiphy *wiphy, const char *alpha2);
/**
- * regulatory_hint_11d - hints a country IE as a regulatory domain
- * @wiphy: the wireless device giving the hint (used only for reporting
- * conflicts)
- * @country_ie: pointer to the country IE
- * @country_ie_len: length of the country IE
- *
- * We will intersect the rd with the what CRDA tells us should apply
- * for the alpha2 this country IE belongs to, this prevents APs from
- * sending us incorrect or outdated information against a country.
- */
-extern void regulatory_hint_11d(struct wiphy *wiphy,
- u8 *country_ie,
- u8 country_ie_len);
-/**
* wiphy_apply_custom_regulatory - apply a custom driver regulatory domain
* @wiphy: the wireless device we want to process the regulatory domain on
* @regd: the custom regulatory domain to use for this wiphy
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 0779ba1..5ff1496 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1846,12 +1846,8 @@ static void ieee80211_rx_mgmt_beacon(struct ieee80211_sub_if_data *sdata,
bssid, ap_ht_cap_flags);
}
+ /* Note: country IE parsing is done for us by cfg80211 */
if (elems.country_elem) {
- /* Note we are only reviewing this on beacons
- * for the BSSID we are associated to */
- regulatory_hint_11d(local->hw.wiphy,
- elems.country_elem, elems.country_elem_len);
-
/* TODO: IBSS also needs this */
if (elems.pwr_constr_elem)
ieee80211_handle_pwr_constr(sdata,
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 14e0c87..06abd7a 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1911,7 +1911,6 @@ free_rd_out:
out:
mutex_unlock(®_mutex);
}
-EXPORT_SYMBOL(regulatory_hint_11d);
static bool freq_is_chan_12_13_14(u16 freq)
{
diff --git a/net/wireless/reg.h b/net/wireless/reg.h
index e37829a..662a9da 100644
--- a/net/wireless/reg.h
+++ b/net/wireless/reg.h
@@ -36,4 +36,19 @@ int regulatory_hint_found_beacon(struct wiphy *wiphy,
struct ieee80211_channel *beacon_chan,
gfp_t gfp);
+/**
+ * regulatory_hint_11d - hints a country IE as a regulatory domain
+ * @wiphy: the wireless device giving the hint (used only for reporting
+ * conflicts)
+ * @country_ie: pointer to the country IE
+ * @country_ie_len: length of the country IE
+ *
+ * We will intersect the rd with the what CRDA tells us should apply
+ * for the alpha2 this country IE belongs to, this prevents APs from
+ * sending us incorrect or outdated information against a country.
+ */
+void regulatory_hint_11d(struct wiphy *wiphy,
+ u8 *country_ie,
+ u8 country_ie_len);
+
#endif /* __NET_WIRELESS_REG_H */
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index 3728d2b..bc0fb7d 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -13,6 +13,7 @@
#include <net/cfg80211.h>
#include <net/rtnetlink.h>
#include "nl80211.h"
+#include "reg.h"
struct cfg80211_conn {
struct cfg80211_connect_params params;
@@ -320,6 +321,7 @@ void __cfg80211_connect_result(struct net_device *dev, const u8 *bssid,
struct cfg80211_bss *bss)
{
struct wireless_dev *wdev = dev->ieee80211_ptr;
+ u8 *country_ie;
#ifdef CONFIG_WIRELESS_EXT
union iwreq_data wrqu;
#endif
@@ -401,6 +403,20 @@ void __cfg80211_connect_result(struct net_device *dev, const u8 *bssid,
wdev->sme_state = CFG80211_SME_CONNECTED;
cfg80211_upload_connect_keys(wdev);
+
+ country_ie = (u8 *) ieee80211_bss_get_ie(bss, WLAN_EID_COUNTRY);
+
+ if (!country_ie)
+ return;
+
+ /*
+ * ieee80211_bss_get()_ie ensures we can access:
+ * - country_ie + 2, the start of the country ie data, and
+ * - and country_ie[1] which is the IE length
+ */
+ regulatory_hint_11d(wdev->wiphy,
+ country_ie + 2,
+ country_ie[1]);
}
void cfg80211_connect_result(struct net_device *dev, const u8 *bssid,
--
1.6.0.4
^ permalink raw reply related
* [PATCH v2 2/3] cfg80211: decouple regulatory variables from cfg80211_mutex
From: Luis R. Rodriguez @ 2009-07-30 17:22 UTC (permalink / raw)
To: linville, johannes; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <1248974562-8315-1-git-send-email-lrodriguez@atheros.com>
We change regulatory code to be protected by its own regulatory
mutex and alleviate cfg80211_mutex to only be used to protect
cfg80211_rdev_list, the registered device list.
By doing this we will be able to work on regulatory core components
without having to have hog up the cfg80211_mutex. An example here is
we no longer need to use the cfg80211_mutex during driver specific
wiphy_apply_custom_regulatory(). We also no longer need it for the
the country IE regulatory hint; by doing so we end up curing this
new lockdep warning:
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.31-rc4-wl #12
-------------------------------------------------------
phy1/1709 is trying to acquire lock:
(cfg80211_mutex){+.+.+.}, at: [<ffffffffa00af852>] regulatory_hint_11d+0x32/0x3f0 [cfg80211]
but task is already holding lock:
(&ifmgd->mtx){+.+.+.}, at: [<ffffffffa0144228>] ieee80211_sta_work+0x108/0x10f0 [mac80211]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (&ifmgd->mtx){+.+.+.}:
[<ffffffff810857b6>] __lock_acquire+0xd76/0x12b0
[<ffffffff81085dd3>] lock_acquire+0xe3/0x120
[<ffffffff814eeae4>] mutex_lock_nested+0x44/0x350
[<ffffffffa0141bb8>] ieee80211_mgd_auth+0x108/0x1f0 [mac80211]
[<ffffffffa0148563>] ieee80211_auth+0x13/0x20 [mac80211]
[<ffffffffa00bc3a1>] __cfg80211_mlme_auth+0x1b1/0x2a0 [cfg80211]
[<ffffffffa00bc516>] cfg80211_mlme_auth+0x86/0xc0 [cfg80211]
[<ffffffffa00b368d>] nl80211_authenticate+0x21d/0x230 [cfg80211]
[<ffffffff81416ba6>] genl_rcv_msg+0x1b6/0x1f0
[<ffffffff81415c39>] netlink_rcv_skb+0x89/0xb0
[<ffffffff814169d9>] genl_rcv+0x29/0x40
[<ffffffff8141591d>] netlink_unicast+0x29d/0x2b0
[<ffffffff81416514>] netlink_sendmsg+0x214/0x300
[<ffffffff813e4407>] sock_sendmsg+0x107/0x130
[<ffffffff813e45b9>] sys_sendmsg+0x189/0x320
[<ffffffff81011f82>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
-> #2 (&wdev->mtx){+.+.+.}:
[<ffffffff810857b6>] __lock_acquire+0xd76/0x12b0
[<ffffffff81085dd3>] lock_acquire+0xe3/0x120
[<ffffffff814eeae4>] mutex_lock_nested+0x44/0x350
[<ffffffffa00ab304>] cfg80211_netdev_notifier_call+0x1a4/0x390 [cfg80211]
[<ffffffff814f3dff>] notifier_call_chain+0x3f/0x80
[<ffffffff81075a91>] raw_notifier_call_chain+0x11/0x20
[<ffffffff813f665a>] dev_open+0x10a/0x120
[<ffffffff813f59bd>] dev_change_flags+0x9d/0x1e0
[<ffffffff8144eb6e>] devinet_ioctl+0x6fe/0x760
[<ffffffff81450204>] inet_ioctl+0x94/0xc0
[<ffffffff813e25fa>] sock_ioctl+0x6a/0x290
[<ffffffff8111e911>] vfs_ioctl+0x31/0xa0
[<ffffffff8111ea9a>] do_vfs_ioctl+0x8a/0x5c0
[<ffffffff8111f069>] sys_ioctl+0x99/0xa0
[<ffffffff81011f82>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
-> #1 (&rdev->mtx){+.+.+.}:
[<ffffffff810857b6>] __lock_acquire+0xd76/0x12b0
[<ffffffff81085dd3>] lock_acquire+0xe3/0x120
[<ffffffff814eeae4>] mutex_lock_nested+0x44/0x350
[<ffffffffa00ac4d0>] cfg80211_get_dev_from_ifindex+0x60/0x90 [cfg80211]
[<ffffffffa00b21ff>] get_rdev_dev_by_info_ifindex+0x6f/0xa0 [cfg80211]
[<ffffffffa00b51eb>] nl80211_set_interface+0x3b/0x260 [cfg80211]
[<ffffffff81416ba6>] genl_rcv_msg+0x1b6/0x1f0
[<ffffffff81415c39>] netlink_rcv_skb+0x89/0xb0
[<ffffffff814169d9>] genl_rcv+0x29/0x40
[<ffffffff8141591d>] netlink_unicast+0x29d/0x2b0
[<ffffffff81416514>] netlink_sendmsg+0x214/0x300
[<ffffffff813e4407>] sock_sendmsg+0x107/0x130
[<ffffffff813e45b9>] sys_sendmsg+0x189/0x320
[<ffffffff81011f82>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
other info that might help us debug this:
3 locks held by phy1/1709:
#0: ((wiphy_name(local->hw.wiphy))){+.+.+.}, at: [<ffffffff8106b45d>] worker_thread+0x19d/0x340
#1: (&ifmgd->work){+.+.+.}, at: [<ffffffff8106b45d>] worker_thread+0x19d/0x340
#2: (&ifmgd->mtx){+.+.+.}, at: [<ffffffffa0144228>] ieee80211_sta_work+0x108/0x10f0 [mac80211]
Reported-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
net/wireless/core.c | 4 +---
net/wireless/reg.c | 46 +++++++++++++++++++++++++++++++++++++---------
2 files changed, 38 insertions(+), 12 deletions(-)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 755cdf1..d8dbd7f 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -34,9 +34,7 @@ MODULE_DESCRIPTION("wireless configuration support");
LIST_HEAD(cfg80211_rdev_list);
/*
- * This is used to protect the cfg80211_rdev_list, cfg80211_regdomain,
- * country_ie_regdomain, the reg_beacon_list and the the last regulatory
- * request receipt (last_request).
+ * This is used to protect the cfg80211_rdev_list
*/
DEFINE_MUTEX(cfg80211_mutex);
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 2d1d183..14e0c87 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -62,6 +62,16 @@ const struct ieee80211_regdomain *cfg80211_regdomain;
*/
static const struct ieee80211_regdomain *country_ie_regdomain;
+/*
+ * Protects static reg.c components:
+ * - cfg80211_world_regdom
+ * - cfg80211_regdom
+ * - country_ie_regdomain
+ * - last_request
+ */
+DEFINE_MUTEX(reg_mutex);
+#define assert_reg_lock() WARN_ON(!mutex_is_locked(®_mutex))
+
/* Used to queue up regulatory hints */
static LIST_HEAD(reg_requests_list);
static spinlock_t reg_requests_lock;
@@ -1293,7 +1303,7 @@ static void handle_channel_custom(struct wiphy *wiphy,
struct ieee80211_supported_band *sband;
struct ieee80211_channel *chan;
- assert_cfg80211_lock();
+ assert_reg_lock();
sband = wiphy->bands[band];
BUG_ON(chan_idx >= sband->n_channels);
@@ -1342,14 +1352,14 @@ void wiphy_apply_custom_regulatory(struct wiphy *wiphy,
enum ieee80211_band band;
unsigned int bands_set = 0;
- mutex_lock(&cfg80211_mutex);
+ mutex_lock(®_mutex);
for (band = 0; band < IEEE80211_NUM_BANDS; band++) {
if (!wiphy->bands[band])
continue;
handle_band_custom(wiphy, band, regd);
bands_set++;
}
- mutex_unlock(&cfg80211_mutex);
+ mutex_unlock(®_mutex);
/*
* no point in calling this if it won't have any effect
@@ -1495,7 +1505,7 @@ static int ignore_request(struct wiphy *wiphy,
* Returns zero if all went fine, %-EALREADY if a regulatory domain had
* already been set or other standard error codes.
*
- * Caller must hold &cfg80211_mutex
+ * Caller must hold &cfg80211_mutex and ®_mutex
*/
static int __regulatory_hint(struct wiphy *wiphy,
struct regulatory_request *pending_request)
@@ -1570,6 +1580,7 @@ static void reg_process_hint(struct regulatory_request *reg_request)
BUG_ON(!reg_request->alpha2);
mutex_lock(&cfg80211_mutex);
+ mutex_lock(®_mutex);
if (wiphy_idx_valid(reg_request->wiphy_idx))
wiphy = wiphy_idx_to_wiphy(reg_request->wiphy_idx);
@@ -1585,6 +1596,7 @@ static void reg_process_hint(struct regulatory_request *reg_request)
if (r == -EALREADY && wiphy && wiphy->strict_regulatory)
wiphy_update_regulatory(wiphy, reg_request->initiator);
out:
+ mutex_unlock(®_mutex);
mutex_unlock(&cfg80211_mutex);
}
@@ -1613,6 +1625,10 @@ static void reg_process_pending_beacon_hints(void)
struct cfg80211_registered_device *rdev;
struct reg_beacon *pending_beacon, *tmp;
+ /*
+ * No need to hold the reg_mutex here as we just touch wiphys
+ * and do not read or access regulatory variables.
+ */
mutex_lock(&cfg80211_mutex);
/* This goes through the _pending_ beacon list */
@@ -1734,12 +1750,13 @@ int regulatory_hint(struct wiphy *wiphy, const char *alpha2)
}
EXPORT_SYMBOL(regulatory_hint);
+/* Caller must hold reg_mutex */
static bool reg_same_country_ie_hint(struct wiphy *wiphy,
u32 country_ie_checksum)
{
struct wiphy *request_wiphy;
- assert_cfg80211_lock();
+ assert_reg_lock();
if (unlikely(last_request->initiator !=
NL80211_REGDOM_SET_BY_COUNTRY_IE))
@@ -1772,7 +1789,7 @@ void regulatory_hint_11d(struct wiphy *wiphy,
enum environment_cap env = ENVIRON_ANY;
struct regulatory_request *request;
- mutex_lock(&cfg80211_mutex);
+ mutex_lock(®_mutex);
if (unlikely(!last_request))
goto out;
@@ -1883,7 +1900,7 @@ void regulatory_hint_11d(struct wiphy *wiphy,
request->country_ie_checksum = checksum;
request->country_ie_env = env;
- mutex_unlock(&cfg80211_mutex);
+ mutex_unlock(®_mutex);
queue_regulatory_request(request);
@@ -1892,7 +1909,7 @@ void regulatory_hint_11d(struct wiphy *wiphy,
free_rd_out:
kfree(rd);
out:
- mutex_unlock(&cfg80211_mutex);
+ mutex_unlock(®_mutex);
}
EXPORT_SYMBOL(regulatory_hint_11d);
@@ -2225,10 +2242,13 @@ int set_regdom(const struct ieee80211_regdomain *rd)
assert_cfg80211_lock();
+ mutex_lock(®_mutex);
+
/* Note that this doesn't update the wiphys, this is done below */
r = __set_regdom(rd);
if (r) {
kfree(rd);
+ mutex_unlock(®_mutex);
return r;
}
@@ -2243,6 +2263,8 @@ int set_regdom(const struct ieee80211_regdomain *rd)
nl80211_send_reg_change_event(last_request);
+ mutex_unlock(®_mutex);
+
return r;
}
@@ -2253,16 +2275,20 @@ void reg_device_remove(struct wiphy *wiphy)
assert_cfg80211_lock();
+ mutex_lock(®_mutex);
+
kfree(wiphy->regd);
if (last_request)
request_wiphy = wiphy_idx_to_wiphy(last_request->wiphy_idx);
if (!request_wiphy || request_wiphy != wiphy)
- return;
+ goto out;
last_request->wiphy_idx = WIPHY_IDX_STALE;
last_request->country_ie_env = ENVIRON_ANY;
+out:
+ mutex_unlock(®_mutex);
}
int regulatory_init(void)
@@ -2323,6 +2349,7 @@ void regulatory_exit(void)
cancel_work_sync(®_work);
mutex_lock(&cfg80211_mutex);
+ mutex_lock(®_mutex);
reset_regdomains();
@@ -2361,5 +2388,6 @@ void regulatory_exit(void)
}
spin_unlock(®_requests_lock);
+ mutex_unlock(®_mutex);
mutex_unlock(&cfg80211_mutex);
}
--
1.6.0.4
^ permalink raw reply related
* [PATCH v2 1/3] cfg80211: use goto out on 11d reg hint failure
From: Luis R. Rodriguez @ 2009-07-30 17:22 UTC (permalink / raw)
To: linville, johannes; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <1248974562-8315-1-git-send-email-lrodriguez@atheros.com>
This does not change functionality.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
net/wireless/reg.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index fb40428..2d1d183 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1774,10 +1774,8 @@ void regulatory_hint_11d(struct wiphy *wiphy,
mutex_lock(&cfg80211_mutex);
- if (unlikely(!last_request)) {
- mutex_unlock(&cfg80211_mutex);
- return;
- }
+ if (unlikely(!last_request))
+ goto out;
/* IE len must be evenly divisible by 2 */
if (country_ie_len & 0x01)
--
1.6.0.4
^ permalink raw reply related
* [PATCH v2 0/3] wireless: fix 11d lockdep and move 11d hint to cfg80211
From: Luis R. Rodriguez @ 2009-07-30 17:22 UTC (permalink / raw)
To: linville, johannes; +Cc: linux-wireless, Luis R. Rodriguez
This cures the lockdep warning, now with a mutex instead of a spin_lock
to allow sleeping during the driver reg notifier, and we finish the
move of the regulatory_hint_11d() to cfg80211. We also add some missing
lock calls and remove the cfg80211 mutex usage from the driver custom
regulatory settings wiphy_apply_custom_regulatory(). This caller is now
used internally within cfg80211 automatically for all cfg80211 drivers.
Luis R. Rodriguez (3):
cfg80211: use goto out on 11d reg hint failure
cfg80211: decouple regulatory variables from cfg80211_mutex
cfg80211: enable country IE support to all cfg80211 drivers
Sorry -- forgot to address John...
include/net/cfg80211.h | 14 ------------
net/mac80211/mlme.c | 6 +----
net/wireless/core.c | 4 +--
net/wireless/reg.c | 53 +++++++++++++++++++++++++++++++++++------------
net/wireless/reg.h | 15 +++++++++++++
net/wireless/sme.c | 16 ++++++++++++++
6 files changed, 72 insertions(+), 36 deletions(-)
^ permalink raw reply
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