linux.git/drivers/net/wireless/b43, branch v4.0 Linux kernel source tree b43: fix support for 5 GHz only BCM43228 model 2015-03-03T15:03:09+00:00 Rafał Miłecki zajec5@gmail.com 2015-03-02T16:18:55+00:00 0ff66cffde47de51c155ebdd2356403276c04cc4 It was incorrectly detected as 2 GHz device. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Cc: stable@vger.kernel.org # 3.17+ Signed-off-by: Kalle Valo <kvalo@codeaurora.org> 
It was incorrectly detected as 2 GHz device.

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Cc: stable@vger.kernel.org # 3.17+
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
treewide: Remove unnecessary SSB_DEVTABLE_END macro 2015-02-11T22:38:29+00:00 Joe Perches joe@perches.com 2015-02-10T21:19:24+00:00 673e2baaa6d986e2fcd9c867661d8113f6c7dc7b Use the normal {} instead of a macro to terminate an array. Remove the macro too. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
Use the normal {} instead of a macro to terminate an array.

Remove the macro too.

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
treewide: Remove unnecessary BCMA_CORETABLE_END macro 2015-02-11T22:38:28+00:00 Joe Perches joe@perches.com 2015-02-10T20:55:03+00:00 f7219b527b5710ae0c4add8faa4d0ea529722cb5 Use the normal {} instead of a macro to terminate an array. Remove the macro too. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
Use the normal {} instead of a macro to terminate an array.

Remove the macro too.

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
b43: AC-PHY: prepare place for developing new PHY support 2015-01-29T08:54:43+00:00 Rafał Miłecki zajec5@gmail.com 2015-01-25T17:01:37+00:00 3f7bb3f34cc880bc35f6c278be16cd8afee7c524 There are new (not anymore?) Broadcom 802.11ac wireless cards based on chipsets like BCM4352 and BCM4360. They use a new PHY type (called simply AC) that will require new specific code. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> 
There are new (not anymore?) Broadcom 802.11ac wireless cards based on
chipsets like BCM4352 and BCM4360. They use a new PHY type (called
simply AC) that will require new specific code.

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
b43: support bcma core reset on AC-PHY hardware 2015-01-29T08:54:43+00:00 Rafał Miłecki zajec5@gmail.com 2015-01-25T13:39:34+00:00 86144b01a25185ec092b9301e340ca4f7a8c0d92 AC-PHY hardware includes new control 0x3 bits that need to be set to the 0x1 by default. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> 
AC-PHY hardware includes new control 0x3 bits that need to be set to the
0x1 by default.

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
b43: Fix locking FIXME in beacon update top half 2015-01-29T08:28:05+00:00 Michael Büsch m@bues.ch 2015-01-26T17:26:17+00:00 a75d46a4f405eb19ff780410b968c8092af3fb1d b43 has a FIXME about locking in the mac80211 set-beacon-int callback for a long time. As it turns out there actually is a tiny race window that could result in a use-after-free bug of the 'current_beacon' memory. Nobody ever reported this, so it probably never happened. Fix this by adding a spin lock that protects the current_beacon access. We must not be in atomic context while accessing hardware (due to SDIO), so the beacon update bottom half has to clone the skb and release the lock before writing it to hardware. Let's all hope that this stops the troll who is trying to submit incorrect fixes for this issue repeatedly. And let's hope that I'm not a troll, too, who just hides even more evil code in an even more complex attempt to fix the issue. Signed-off-by: Michael Buesch <m@bues.ch> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> 
b43 has a FIXME about locking in the mac80211 set-beacon-int callback for a long time.
As it turns out there actually is a tiny race window that could result in
a use-after-free bug of the 'current_beacon' memory.
Nobody ever reported this, so it probably never happened.

Fix this by adding a spin lock that protects the current_beacon access.
We must not be in atomic context while accessing hardware (due to SDIO),
so the beacon update bottom half has to clone the skb and release the lock
before writing it to hardware.

Let's all hope that this stops the troll who is trying to submit incorrect
fixes for this issue repeatedly.
And let's hope that I'm not a troll, too, who just hides even more evil code
in an even more complex attempt to fix the issue.

Signed-off-by: Michael Buesch <m@bues.ch>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
b43: stop leds during suspend 2015-01-23T17:40:40+00:00 Sabrina Dubroca sd@queasysnail.net 2015-01-19T14:34:32+00:00 6b47aacaa4491ab04630ab0aec10d10e6ac9e14f Call b43_leds_stop during suspend to avoid this WARN: WARNING: CPU: 1 PID: 0 at net/mac80211/util.c:755 ieee80211_can_queue_work.isra.11+0x35/0x50 [mac80211]() queueing ieee80211 work while going to suspend [...] Call Trace: [<c165fb2a>] dump_stack+0x48/0x69 [<c1052f7b>] warn_slowpath_common+0x8b/0xc0 [<f9c30225>] ? ieee80211_can_queue_work.isra.11+0x35/0x50 [mac80211] [<f9c30225>] ? ieee80211_can_queue_work.isra.11+0x35/0x50 [mac80211] [<c1052fe3>] warn_slowpath_fmt+0x33/0x40 [<f9c30225>] ieee80211_can_queue_work.isra.11+0x35/0x50 [mac80211] [<f9c30260>] ieee80211_queue_work+0x20/0x40 [mac80211] [<f9f25d78>] b43_led_brightness_set+0x28/0x30 [b43] [<c14f3835>] led_timer_function+0xd5/0xe0 [<c10cb534>] call_timer_fn+0xa4/0x4a0 Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> 
Call b43_leds_stop during suspend to avoid this WARN:

WARNING: CPU: 1 PID: 0 at net/mac80211/util.c:755 ieee80211_can_queue_work.isra.11+0x35/0x50 [mac80211]()
queueing ieee80211 work while going to suspend

 [...]

Call Trace:
 [<c165fb2a>] dump_stack+0x48/0x69
 [<c1052f7b>] warn_slowpath_common+0x8b/0xc0
 [<f9c30225>] ? ieee80211_can_queue_work.isra.11+0x35/0x50 [mac80211]
 [<f9c30225>] ? ieee80211_can_queue_work.isra.11+0x35/0x50 [mac80211]
 [<c1052fe3>] warn_slowpath_fmt+0x33/0x40
 [<f9c30225>] ieee80211_can_queue_work.isra.11+0x35/0x50 [mac80211]
 [<f9c30260>] ieee80211_queue_work+0x20/0x40 [mac80211]
 [<f9f25d78>] b43_led_brightness_set+0x28/0x30 [b43]
 [<c14f3835>] led_timer_function+0xd5/0xe0
 [<c10cb534>] call_timer_fn+0xa4/0x4a0

Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Merge tag 'mac80211-next-for-john-2014-11-20' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next 2014-11-20T21:09:30+00:00 John W. Linville linville@tuxdriver.com 2014-11-20T21:09:30+00:00 9a638ddfb09e5aa17158842c95526e1aa79f92e6 Johannes Berg <johannes@sipsolutions.net> says: "It has been a while since my last pull request, so we accumulated another relatively large set of changes: * TDLS off-channel support set from Arik/Liad, with some support patches I did * custom regulatory fixes from Arik * minstrel VHT fix (and a small optimisation) from Felix * add back radiotap vendor namespace support (myself) * random MAC address scanning for cfg80211/mac80211/hwsim (myself) * CSA improvements (Luca) * WoWLAN Net Detect (wake on network found) support (Luca) * and lots of other smaller changes from many people" Signed-off-by: John W. Linville <linville@tuxdriver.com> 
Johannes Berg <johannes@sipsolutions.net> says:

"It has been a while since my last pull request, so we accumulated
another relatively large set of changes:
 * TDLS off-channel support set from Arik/Liad, with some support
   patches I did
 * custom regulatory fixes from Arik
 * minstrel VHT fix (and a small optimisation) from Felix
 * add back radiotap vendor namespace support (myself)
 * random MAC address scanning for cfg80211/mac80211/hwsim (myself)
 * CSA improvements (Luca)
 * WoWLAN Net Detect (wake on network found) support (Luca)
 * and lots of other smaller changes from many people"

Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211: allow drivers to support NL80211_SCAN_FLAG_RANDOM_ADDR 2014-11-19T17:46:09+00:00 Johannes Berg johannes.berg@intel.com 2014-06-12T20:24:31+00:00 a344d6778a98e4c19ac871f369e399e6356edcb3 Allow drivers to support NL80211_SCAN_FLAG_RANDOM_ADDR with software based scanning and generate a random MAC address for them for every scan request with the flag. Signed-off-by: Johannes Berg <johannes.berg@intel.com> 
Allow drivers to support NL80211_SCAN_FLAG_RANDOM_ADDR with software
based scanning and generate a random MAC address for them for every
scan request with the flag.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
b43: fix NULL pointer dereference in b43_phy_copy() 2014-11-10T18:10:24+00:00 Hauke Mehrtens hauke@hauke-m.de 2014-11-08T12:59:42+00:00 9c3a6670863033df421c8e46f79f383cf3a922ee phy_read and phy_write are not set for every phy any more sine this: commit d342b95dd735014a590f9051b1ba227eb54ca8f6 Author: Rafał Miłecki <zajec5@gmail.com> Date: Thu Jul 31 21:59:43 2014 +0200 b43: don't duplicate common PHY read/write ops b43_phy_copy() accesses phy_read and phy_write directly and will fail with some phys. This patch fixes the regression by using the b43_phy_read() and b43_phy_write() functions which should be used for read and write access. This should fix this bug report: https://bugzilla.kernel.org/show_bug.cgi?id=87731 Reported-by: Volker Kempter <v.kempter@pe.tu-clausthal.de> Tested-by: Volker Kempter <v.kempter@pe.tu-clausthal.de> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
phy_read and phy_write are not set for every phy any more sine this:
commit d342b95dd735014a590f9051b1ba227eb54ca8f6
Author: Rafał Miłecki <zajec5@gmail.com>
Date:   Thu Jul 31 21:59:43 2014 +0200

    b43: don't duplicate common PHY read/write ops

b43_phy_copy() accesses phy_read and phy_write directly and will fail
with some phys. This patch fixes the regression by using the
b43_phy_read() and b43_phy_write() functions which should be used for
read and write access.

This should fix this bug report:
https://bugzilla.kernel.org/show_bug.cgi?id=87731

Reported-by: Volker Kempter <v.kempter@pe.tu-clausthal.de>
Tested-by: Volker Kempter <v.kempter@pe.tu-clausthal.de>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>