summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/b43/main.c
AgeCommit message (Collapse)AuthorFilesLines
2015-11-18b43: move under broadcom vendor directoryKalle Valo1-5895/+0
Part of reorganising wireless drivers directory and Kconfig. Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2015-10-28ssb: pick PCMCIA host code support from b43 driverRafał Miłecki1-8/+1
ssb bus can be found on various "host" devices like PCI/PCMCIA/SDIO. Every ssb bus contains cores AKA devices. The main idea is to have ssb driver scan/initialize bus and register ready-to-use cores. This way ssb drivers can operate on a single core mostly ignoring underlaying details. For some reason PCMCIA support was split between ssb and b43. We got PCMCIA host device probing in b43, then bus scanning in ssb and then wireless core probing back in b43. The truth is it's very unlikely we will ever see PCMCIA ssb device with no 802.11 core but I still don't see any advantage of the current architecture. With proposed change we get the same functionality with a simpler architecture, less Kconfig symbols, one killed EXPORT and hopefully cleaner b43. Since b43 supports both: ssb & bcma I prefer to keep ssb specific code in ssb driver. This mostly moves code from b43's pcmcia.c to bridge_pcmcia_80211.c. We already use similar solution with b43_pci_bridge.c. I didn't use "b43" in name of this new file as in theory any driver can operate on wireless core. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2015-09-26b43: probe bcma core (device) rev 0x15Rafał Miłecki1-0/+1
OpenWrt user reported b43 doesn't probe wireless core on SoC BCM5356A1: [ 0.000000] bcma: bus0: Found chip with id 0x5356, rev 0x01 and package 0x04 it is because this chip uses different 802.11 core revison than others: [ 0.000000] bcma: bus0: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x15, class 0x0) Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2015-06-23Merge tag 'wireless-drivers-next-for-davem-2015-06-18' of ↵David S. Miller1-0/+4
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== Major changes: mwifiex: * enhancements for AP mode: support verbose information in station dump command and also information about AP link. * enable power save by default brcmfmac: * fix module reload issue for PCIe * improving msgbuf protocol for PCIe devices * rework .get_station() cfg80211 callback operation * determine interface combinations upon device feature support ath9k: * ath9k_htc: add support of channel switch wil6210: * add modparam for bcast ring size * support hidden SSID * add per-MCS Rx stats ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2015-06-10mac80211: convert HW flags to unsigned long bitmapJohannes Berg1-2/+2
As we're running out of hardware capability flags pretty quickly, convert them to use the regular test_bit() style unsigned long bitmaps. This introduces a number of helper functions/macros to set and to test the bits, along with new debugfs code. The occurrences of an explicit __clear_bit() are intentional, the drivers were never supposed to change their supported bits on the fly. We should investigate changing this to be a per-frame flag. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-06-08b43: fix support for 14e4:4321 PCI dev with BCM4321 chipsetRafał Miłecki1-0/+4
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 Berg1-6/+2
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. Miller1-1/+1
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-21Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller1-0/+1
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łecki1-1/+1
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. Miller1-3/+3
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-04wireless: Use eth_<foo>_addr instead of memsetJoe Perches1-4/+4
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łecki1-0/+1
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łecki1-1/+1
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łecki1-2/+2
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-12treewide: Remove unnecessary SSB_DEVTABLE_END macroJoe Perches1-1/+1
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-12treewide: Remove unnecessary BCMA_CORETABLE_END macroJoe Perches1-1/+1
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łecki1-0/+10
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łecki1-0/+17
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üsch1-11/+32
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 Dubroca1-0/+1
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 Berg1-2/+5
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 Mehrtens1-0/+9
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-15b43: add missing rateHauke Mehrtens1-0/+1
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 Mehrtens1-0/+4
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 Mehrtens1-0/+10
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łecki1-0/+30
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łecki1-1/+16
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-26b43: flush some writes on Broadcom MIPS SoCsRafał Miłecki1-9/+8
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łecki1-1/+2
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łecki1-1/+0
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łecki1-1/+22
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łecki1-21/+25
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łecki1-2/+4
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łecki1-0/+39
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łecki1-8/+10
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łecki1-2/+22
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łecki1-1/+1
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łecki1-4/+4
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-11Merge branch 'master' of ↵John W. Linville1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless
2014-07-08b43: fix reading info about radio for new devices (cores 40 & 42)Rafał Miłecki1-1/+10
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łecki1-0/+12
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łecki1-0/+7
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łecki1-99/+125
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łecki1-0/+2
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łecki1-9/+0
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łecki1-5/+0
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łecki1-0/+1
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łecki1-1/+2
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łecki1-15/+16
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>
generated by cgit v1.2.3 (git 2.39.0) at 2025-01-07 04:51:22 +0300