aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net/wireless/b43
Commit message (Collapse)AuthorAge
* b43: fix support for 14e4:4321 PCI dev with BCM4321 chipsetRafał Miłecki2015-06-29
| | | | | | | | | | | | | | | | | commit 90f91b129810c3f169e443252be30ed7c0130326 upstream. 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* wireless: Use bool function returns of true/false instead of 1/0Joe Perches2015-04-07
| | | | | | | Use bool constants as the return values instead of 1 and 0. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* Merge tag 'wireless-drivers-next-for-davem-2015-04-01' of ↵David S. Miller2015-04-01
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * bcma: move PCI IRQ control function to host specific codeRafał Miłecki2015-03-13
| | | | | | | | | | | | | | | | 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>
* | Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller2015-03-20
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * b43: fix support for 5 GHz only BCM43228 modelRafał Miłecki2015-03-03
| | | | | | | | | | | | | | | | 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>
* | Merge tag 'wireless-drivers-next-for-davem-2015-03-06' of ↵David S. Miller2015-03-06
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | bcma: change IRQ control function to accept bus as an argumentRafał Miłecki2015-03-02
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | bcma: add helpers bringing PCIe hosted bus up / downRafał Miłecki2015-03-02
| |/ | | | | | | | | | | | | | | | | 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>
* / wireless: Use eth_<foo>_addr instead of memsetJoe Perches2015-03-03
|/ | | | | | | | | | | | 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>
* treewide: Remove unnecessary SSB_DEVTABLE_END macroJoe Perches2015-02-11
| | | | | | | | | 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 macroJoe Perches2015-02-11
| | | | | | | | | 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 supportRafał Miłecki2015-01-29
| | | | | | | | | 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 hardwareRafał Miłecki2015-01-29
| | | | | | | | 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 halfMichael Büsch2015-01-29
| | | | | | | | | | | | | | | | | | | | | 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 suspendSabrina Dubroca2015-01-23
| | | | | | | | | | | | | | | | | | | | | | | | 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 ↵John W. Linville2014-11-20
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next 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_ADDRJohannes Berg2014-11-19
| | | | | | | | | | | | | | | | 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()Hauke Mehrtens2014-11-10
|/ | | | | | | | | | | | | | | | | | | | | | 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>
* b43: add support for setting the beacon listen intervalHauke Mehrtens2014-09-15
| | | | | Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: update some transmit header constantsHauke Mehrtens2014-09-15
| | | | | | | | | | Some constants were missing and are added now. The rate mode was renamed, at least the ucode in brcsmac uses 2 for HT rates (iee80211n) and the more recent ucodes are using 3 for VHT (ieee80211ac). Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: add missing rateHauke Mehrtens2014-09-15
| | | | | | | 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>
* b43: tell ucode the phy type and versionHauke Mehrtens2014-09-15
| | | | | Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: tell the ucode the mac capabilitiesHauke Mehrtens2014-09-15
| | | | | | | 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>
* b43: Implement PHY PLL resetRafał Miłecki2014-09-15
| | | | | | | 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>
* b43: HT-PHY: Update values for frequency calibrationRafał Miłecki2014-09-15
| | | | | | | | Previous values were extracted from MMIO dump of some old 5.x driver, new ones should improve calibration. This also adds values for 5 GHz. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: HT-PHY: Implement band switchingRafał Miłecki2014-09-15
| | | | | | | It works pretty much the same way as in N-PHY. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: HT-PHY: Set MAC frequency to correct valuesRafał Miłecki2014-09-11
| | | | | | | 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>
* b43: HT-PHY: Complete radio init (add missing entries)Rafał Miłecki2014-09-11
| | | | | Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: HT-PHY: Define some regs for 0x2059 radioRafał Miłecki2014-09-11
| | | | | Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: HT-PHY: Move radio calibration to separated functionsRafał Miłecki2014-09-11
| | | | | | | | Also use b43_radio_wait_value to simplify the code and usleep_range when needed. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: HT-PHY: Move radio preparation into init functionRafał Miłecki2014-09-11
| | | | | | | | | Radio should be prepared only before initialization. We need this to be able to call b43_radio_2059_init conditionally (in the future). This also documents RF control register a bit. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: N-PHY: support setting custom TX powerRafał Miłecki2014-08-25
| | | | | Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: implement PPR (Power Per Rate) management/APIRafał Miłecki2014-08-25
| | | | | | | | | | | | | Broadcom hardware supports auto-adjustment of TX power depending on the currently used rate. So far all calculations were handled without any helpers (API) using big arrays and magic offsets. It seems Broadcom recently decided to clean this up by developing PPR. Their wlc_ppr.h can be found in open parts of the SDK. As we plan to implement support for rate-based TX power it makes sense to also implement our version of PPR as well. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: N-PHY: add RF power tables for radio 0x2057 revs 9 & 14Rafał Miłecki2014-08-25
| | | | | | | Don't write them as we don't have gains configured correctly yet. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: N-PHY: update rev3+ gain control workaroundsRafał Miłecki2014-08-25
| | | | | | | This fixes workarounds on rev 6+ and cleans code slightly. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: flush some writes on Broadcom MIPS SoCsRafał Miłecki2014-08-25
| | | | | | | | | | 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>
* b43: don't duplicate common PHY read/write opsRafał Miłecki2014-08-25
| | | | | | | | | Most of the PHYs use the same way of accessing registers, so move that code to the shared place. An exception is G-PHY which sometimes access A-PHY regs and requires special handling. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: update flushing many writes performed in a rowRafał Miłecki2014-08-25
| | | | | | | | Flush radio writes as well and add some tiny optimizations (e.g. masksetting PHY reg involves reading it, so reset the counter). Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: N-PHY: fix "Data bus error" while working in 5 GHzRafał Miłecki2014-07-31
| | | | | | | | | | | | When switching from one 5 GHz channel to another 5 GHz channel we need to make sure BPHY is still in a reset. However to access BPHY register we have to switch to 2 GHz mode for a moment. Otherwise this may result in "Data bus error" (noticed by Hauke with BCM43224 connected to the SoC). Reported-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: update PHY descriptions in KconfigRafał Miłecki2014-07-31
| | | | | | | | Add lists of chipsets, so people can enable support for their device easier (at least after checking lspci). Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: add support for BCM43131 chipset with N-PHY rev 17Rafał Miłecki2014-07-29
| | | | | | | | 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>
* b43: enable 5 GHz support for N-PHY devicesRafał Miłecki2014-07-23
| | | | | | | | | 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>
* b43: register limited amount of 5G channels for BCM43228Rafał Miłecki2014-07-23
| | | | | | | | 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>
* b43: N-PHY: don't calculate values for TSSI if we can't transmitRafał Miłecki2014-07-23
| | | | | | | | This process requires sending some sample tone, so make sure we're allowed to transmit first. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: report correct rate to mac80211 for 5 GHz packetsRafał Miłecki2014-07-23
| | | | | | | So far we were assuming only A-PHY supports 5 GHz. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: N-PHY: fix rev7+ typos at random placesRafał Miłecki2014-07-23
| | | | | Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: extract one more radio parameter: versionRafał Miłecki2014-07-22
| | | | | | | | 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>
* b43: enable radio 0x2057 rev 14 support (AKA BCM43217)Rafał Miłecki2014-07-22
| | | | | Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: N-PHY: final fixes to rev7+ workaroundsRafał Miłecki2014-07-22
| | | | | Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
generated by cgit v1.2.2 (git 2.25.0) at 2024-12-27 08:05:07 -0500