linux.git/net/wireless, branch v3.6-rc4

cfg80211: process pending events when unregistering net device

2012-08-06T18:29:58+00:00

libertas currently calls cfg80211_disconnected() when it is being
brought down. This causes an event to be allocated, but since the
wdev is already removed from the rdev by the time that the event
processing work executes, the event is never processed or freed.
http://article.gmane.org/gmane.linux.kernel.wireless.general/95666

Fix this leak, and other possible situations, by processing the event
queue when a device is being unregistered. Thanks to Johannes Berg for
the suggestion.

Signed-off-by: Daniel Drake 
Cc: stable@vger.kernel.org
Reviewed-by: Johannes Berg 
Signed-off-by: John W. Linville

cfg80211: Clear "beacon_found" on regulatory restore

2012-08-02T13:34:22+00:00

Restore the default state to the "beacon_found" flag when
the channel flags are restored.  Otherwise, we can end up
with a channel that we can no longer transmit on even when
we can see beacons on that channel.

Signed-off-by: Paul Stewart 
Signed-off-by: Johannes Berg

cfg80211: add channel flag to prohibit OFDM operation

2012-08-02T13:30:49+00:00

Currently the only way for wireless drivers to tell whether or not OFDM
is allowed on the current channel is to check the regulatory
information. However, this requires hodling cfg80211_mutex, which is not
visible to the drivers.

Other regulatory restrictions are provided as flags in the channel
definition, so let's do similarly with OFDM. This patch adds a new flag,
IEEE80211_CHAN_NO_OFDM, to tell drivers that OFDM on a channel is not
allowed. This flag is set on any channels for which regulatory indicates
that OFDM is prohibited.

Signed-off-by: Seth Forshee 
Tested-by: Arend van Spriel 
Signed-off-by: Johannes Berg

Merge remote-tracking branch 'wireless/master' into mac80211

2012-07-30T07:13:03+00:00

wireless: reg: restore previous behaviour of chan->max_power calculations

2012-07-25T14:11:12+00:00

commit eccc068e8e84c8fe997115629925e0422a98e4de
Author: Hong Wu 
Date:   Wed Jan 11 20:33:39 2012 +0200

    wireless: Save original maximum regulatory transmission power for the calucation of the local maximum transmit pow

changed the way we calculate chan->max_power as min(chan->max_power,
chan->max_reg_power). That broke rt2x00 (and perhaps some other
drivers) that do not set chan->max_power. It is not so easy to fix this
problem correctly in rt2x00.

According to commit eccc068e8 changelog, change claim only to save
maximum regulatory power - changing setting of chan->max_power was side
effect. This patch restore previous calculations of chan->max_power and
do not touch chan->max_reg_power.

Cc: stable@vger.kernel.org # 3.4+
Signed-off-by: Stanislaw Gruszka 
Acked-by: Luis R. Rodriguez 
Signed-off-by: Johannes Berg

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem

2012-07-20T16:30:48+00:00

cfg80211: Fix mutex locking in reg_last_request_cell_base

2012-07-18T15:03:15+00:00

should fix the following issue

	[ 3229.815012] [ BUG: lock held when returning to user space! ]
	[ 3229.815016] 3.5.0-rc7-wl #28 Tainted: G        W  O
	[ 3229.815017]
	------------------------------------------------
	[ 3229.815019] wpa_supplicant/5783 is leaving the kernel with locks still held!
	[ 3229.815022] 1 lock held by wpa_supplicant/5783:
	[ 3229.815023]  #0: (reg_mutex){+.+.+.}, at: []
	reg_last_request_cell_base+0x1d/0x60 [cfg80211]

Cc: Luis Rodriguez 
Signed-off-by: Mohammed Shafi Shajakhan 
Tested-by: Luciano Coelho 
Signed-off-by: Johannes Berg

cfg80211: remove regulatory_update()

2012-07-17T10:16:41+00:00

regulatory_update() just calls wiphy_update_regulatory().
wiphy_update_regulatory() assumes you already have
the reg_mutex held so just move the call within locking
context and kill the superfluous regulatory_update().

Signed-off-by: Luis R. Rodriguez 
Signed-off-by: Johannes Berg

cfg80211: make regulatory_update() static

2012-07-17T10:16:40+00:00

Now that we have wiphy_regulatory_register() we can
tuck away the core's regulatory_update() call there
and make it static.

Signed-off-by: Luis R. Rodriguez 
Signed-off-by: Johannes Berg

cfg80211: rename reg_device_remove() to wiphy_regulatory_deregister()

2012-07-17T10:16:39+00:00

This makes it clearer what we're doing. This now makes a bit
more sense given that regardless of the wiphy if the cell
base station hint feature is supported we will be modifying the
way the regulatory core behaves.

Signed-off-by: Luis R. Rodriguez 
Signed-off-by: Johannes Berg