summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/b43/main.c
AgeCommit message (Collapse)Author
2015-06-08b43: fix support for 14e4:4321 PCI dev with BCM4321 chipsetRafał Miłecki
It seems Broadcom released two devices with conflicting device id. There are for sure 14e4:4321 PCI devices with BCM4321 (N-PHY) chipset, they can be found in routers, e.g. Netgear WNR834Bv2. However, according to Broadcom public sources 0x4321 is also used for 5 GHz BCM4306 (G-PHY). It's unsure if they meant PCI device id, or "virtual" id (from SPROM). To distinguish these devices lets check PHY type (G vs. N). Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Cc: <stable@vger.kernel.org> # 3.16+ Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2015-04-24mac80211: remove support for IFF_PROMISCJohannes Berg
This support is essentially useless as typically networks are encrypted, frames will be filtered by hardware, and rate scaling will be done with the intended recipient in mind. For real monitoring of the network, the monitor mode support should be used instead. Removing it removes a lot of corner cases. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-04-01Merge tag 'wireless-drivers-next-for-davem-2015-04-01' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== Major changes: ath9k: * add Active Interference Cancellation, a method implemented in the HW to counter WLAN RX > sensitivity degradation when BT is transmitting at the same time. This feature is supported by cards like WB222 based on AR9462. iwlwifi: * Location Aware Regulatory was added by Arik * 8000 device family work * update to the BT Coex firmware API brmcfmac: * add new BCM43455 and BCM43457 SDIO device support * add new BCM43430 SDIO device support wil6210: * take care of AP bridging * fix NAPI behavior * found approach to achieve 4*n+2 alignment of Rx frames rt2x00: * add new rt2800usb device DWA 130 rtlwifi: * add USB ID for D-Link DWA-131 * add USB ID ASUS N10 WiFi dongle mwifiex: * throughput enhancements ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2015-03-20Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller
Conflicts: drivers/net/ethernet/emulex/benet/be_main.c net/core/sysctl_net_core.c net/ipv4/inet_diag.c The be_main.c conflict resolution was really tricky. The conflict hunks generated by GIT were very unhelpful, to say the least. It split functions in half and moved them around, when the real actual conflict only existed solely inside of one function, that being be_map_pci_bars(). So instead, to resolve this, I checked out be_main.c from the top of net-next, then I applied the be_main.c changes from 'net' since the last time I merged. And this worked beautifully. The inet_diag.c and sysctl_net_core.c conflicts were simple overlapping changes, and were easily to resolve. Signed-off-by: David S. Miller <davem@davemloft.net>
2015-03-13bcma: move PCI IRQ control function to host specific codeRafał Miłecki
This function isn't really related to any bus core. It touches PCI device config registers only, so move it to the (PCI) host file. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2015-03-06Merge tag 'wireless-drivers-next-for-davem-2015-03-06' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Major changes: brcmfmac: * sdio improvements * add a debugfs file so users can provide us all the revinfo we could ask for iwlwifi: * add triggers for firmware dump collection * remove support for -9.ucode * new statitics API * rate control improvements ath9k: * add per-vif TX power capability * BT coexistance fixes ath10k: * qca6174: enable STA transmit beamforming (TxBF) support * disable multi-vif power save by default bcma: * enable support for PCIe Gen 2 host devices Signed-off-by: David S. Miller <davem@davemloft.net>
2015-03-03wireless: Use eth_<foo>_addr instead of memsetJoe Perches
Use the built-in function instead of memset. Miscellanea: Add #include <linux/etherdevice.h> where appropriate Use ETH_ALEN instead of 6 Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-03-03b43: fix support for 5 GHz only BCM43228 modelRafał Miłecki
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>
2015-03-02bcma: change IRQ control function to accept bus as an argumentRafał Miłecki
It doesn't operate on PCI core, but PCI host device, so there is no point of passing core related struct. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2015-03-02bcma: add helpers bringing PCIe hosted bus up / downRafał Miłecki
Bringing PCIe hosted bus up requires operating on host-related core. Since we plan to support PCIe Gen 2 devices we should provide a helper picking the correct one (PCIE or PCIE2). Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2015-02-11treewide: Remove unnecessary SSB_DEVTABLE_END macroJoe Perches
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>
2015-02-11treewide: Remove unnecessary BCMA_CORETABLE_END macroJoe Perches
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>
2015-01-29b43: AC-PHY: prepare place for developing new PHY supportRafał Miłecki
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>
2015-01-29b43: support bcma core reset on AC-PHY hardwareRafał Miłecki
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>
2015-01-29b43: Fix locking FIXME in beacon update top halfMichael Büsch
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>
2015-01-23b43: stop leds during suspendSabrina Dubroca
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>
2014-11-19mac80211: allow drivers to support NL80211_SCAN_FLAG_RANDOM_ADDRJohannes Berg
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>
2014-09-15b43: add support for setting the beacon listen intervalHauke Mehrtens
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-15b43: add missing rateHauke Mehrtens
The OFDM reate 9MB was not set here Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-15b43: tell ucode the phy type and versionHauke Mehrtens
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-15b43: tell the ucode the mac capabilitiesHauke Mehrtens
This is based on code form brcmsmac. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-15b43: Implement PHY PLL resetRafał Miłecki
We should reset PLL after changing MAC frequency. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-11b43: HT-PHY: Set MAC frequency to correct valuesRafał Miłecki
I misunderstood original Broadcom comment and used wrong values. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-08-25b43: flush some writes on Broadcom MIPS SoCsRafał Miłecki
Access to PHY and radio registers is indirect on Broadcom hardware and it seems that addressing on some MIPS SoCs may require flushing. So far this problem was noticed on 0x4716 SoC only (marketing names: BCM4717, BCM4718). Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-07-29b43: add support for BCM43131 chipset with N-PHY rev 17Rafał Miłecki
It contains radio 0x2057 rev 14 just like a BCM43217, so it doesn't require any magic. The main difference is that BCM4313 is 1x1:1. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-07-23b43: enable 5 GHz support for N-PHY devicesRafał Miłecki
This has been tested on 14e4:4328 (BCM4321), 14e4:432b (BCM4322), 14e4:4353 (BCM43224) and 14e4:4359 (BCM43228) which is an almost complete list of 5 GHz capable device (only BCM43222 is missing). Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-07-23b43: register limited amount of 5G channels for BCM43228Rafał Miłecki
We don't have all needed channel tables due to RE process for this device. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-07-22b43: extract one more radio parameter: versionRafał Miłecki
Some radios may share the same ID and revision but differ by a version. E.g. radio in BCM5357B0 is version 1 and requires specific handling. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-07-22b43: enable radio 0x2057 rev 14 support (AKA BCM43217)Rafał Miłecki
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-07-18b43: use one shared function for setting MAC frequencyRafał Miłecki
By the way add few chipsets that were tracked with "wl" dumps. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-07-15b43: don't warn about no 5 GHz support on 2.4 GHz devicesRafał Miłecki
This could be a bit confusing to see warning about lacking support for 5 GHz band if your device supports 2.4 GHz only. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-07-15b43: enable radio 0x2057 rev 9 (AKA BCM43228) supportRafał Miłecki
Support for N-PHY rev 8 with 0x2057 rev 5 is almost ready, but we still need to figure out how to handle rev 9 first. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-07-15b43; N-PHY: write most of the missing code for revs 7+Rafał Miłecki
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-07-15b43: always print info about radio (manuf, id, revision)Rafał Miłecki
Type of radio has a major meaning for the driver. There is quite some code that does initialization/calibration depending on the radio rev. Knowing radio params is quite important to provide help to users, so print it even with debugging disabled. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-07-10Merge branch 'master' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless
2014-07-07b43: fix reading info about radio for new devices (cores 40 & 42)Rafał Miłecki
This changes b43-phy0: Found Radio: Manuf 0x17F, Version 0x7769, Revision 4 to the b43-phy0: Found Radio: Manuf 0x17F, Version 0x2069, Revision 4 which matches what closed source driver reports: $ wl revinfo radiorev 0x42069000 Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-07-01b43: add more bcma coresRafał Miłecki
This adds some cores with 0x2057 radio which will be supported soon as well as core 40 that I missed in the earlier firmware patch. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-07-01b43: treat LCNXN-PHY as extra N-PHY devicesRafał Miłecki
LCNXN is simply a continuation of N, e.g. code handling LCNXN revs 0 and 1 is mostly the same as for N-PHY revs 7+. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-06-25b43: update list and code making a selection of firmware filesRafał Miłecki
Clean ucode selection, fix choice of firmware for LCN, drop some goto-s, add new devices. Tested on 14e4:4312, 14e4:4315, 14e4:4328, 14e4:432b, 14e4:4353. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-06-20b43: add config for (en|dis)abling G-PHY supportRafał Miłecki
This allows new devices users to save some space. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-06-20b43: remove leftover code from old devices supportRafał Miłecki
Old devices (A-PHY or B-PHY) are supposed to be supported by b43legacy. We keep phy_a.c as it's needed for G-PHY which shares some design. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-06-19b43: PHY: drop is_40mhz (get width info from chandef)Rafał Miłecki
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-06-19b43: store current channel using struct cfg80211_chan_defRafał Miłecki
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-06-19b43: b43_op_config: set channel info before switching bandRafał Miłecki
Band switching code needs to know what channel we switch to. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-06-19b43: b43_op_config: use IEEE80211_CONF_CHANGE_CHANNELRafał Miłecki
This is tiny optimization and grouping band/channel ops. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-06-19b43: b43_op_config: drop check for core changeRafał Miłecki
There aren't devices with multiple 802.11 cores supported by b43. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-06-16b43: disable 5 GHz on G-PHYRafał Miłecki
This fixes regression introduced by adding some G-PHY devices to the list of dual band devices. There is simply no support for 5 GHz on G-PHY devices in b43. It results in: WARNING: CPU: 0 PID: 79 at drivers/net/wireless/b43/phy_g.c:75 b43_gphy_channel_switch+0x125/0x130 [b43]() b43-phy1 ERROR: PHY init: Channel switch to default failed Regression was introduced by the following commit: commit 773cfc508f4d64c14547ff8751b5cbd473124364 Author: Rafał Miłecki <zajec5@gmail.com> Date: Mon May 19 23:18:55 2014 +0200 b43: add more devices to the bands database Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-05-29b43: N-PHY: optimize radio switching on/offRafał Miłecki
Broadcom's wl 6.30.223.141 has some optimizations for radios 0x205[67]. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-05-29b43: PHY: allow init optimizations by tracking PHY stateRafał Miłecki
PHY has to be often re-initialized (e.g. during band switching after PHY reset), however some operations have to be performed only once (only power reset affects them). Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-05-22b43: fix list of 5 GHz channels for 802.11n cardsRafał Miłecki
Broadcom hardware uses a bit tricky hw_value-s for 5 GHz channels, values 184-228 are used for 4920-5140 MHz center frequencies. Normally you expect channels 7-16 (e.g. 5060 MHz is channel 12, not 212). We never meant to register hw_value 228 with freq 6140 MHz (5000 + 228 * 5). Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
generated by cgit v1.2.3 (git 2.0.4) at 2024-09-09 13:38:00 +0000