summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/brcm80211
AgeCommit message (Collapse)AuthorFilesLines
2012-09-12brcmfmac: Fix big endian host configuration data.Hante Meuleman1-10/+16
Fixes big endian host configuration parameters. Cc: stable <stable@vger.kernel.org> Reviewed-by: Arend Van Spriel <arend@broadcom.com> Signed-off-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-09-12brcmfmac: fix big endian bug in i-scan.Hante Meuleman1-2/+4
ssid len is 32 bit and needs endian conversion for big endian systems. Cc: stable <stable@vger.kernel.org> Signed-off-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-09-10brcm80211: fix missing allocation failure checkColin Ian King1-0/+2
Check for oobirq_entry allocation failure to avoid NULL pointer dereferencing. Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-09-10brcmsmac: fix mismatch in number of custom regulatory rulesArend van Spriel1-1/+1
The driver provides the cfg80211 regulatory framework with a set of custom rules. However, there was a mismatch in number of rules and the actual rules provided. This resulted in setting an invalid power level: ieee80211 phy0: brcms_ops_config: change channel 13 ieee80211 phy0: brcms_ops_config: Error setting power_level (8758364) Closer look in cfg80211 regulatory blurb showed following bogus rule: cfg80211: 0 KHz - -60446948 KHz @ 875836468 KHz), (875836468 mBi, 875836468 mBm) Cc: Seth Forshee <seth.forshee@canonical.com> Reviewed-by: Piotr Haber <phaber@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Reviewed-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-09-05brcmfmac: fix get rssi by clearing getvar struct.Hante Meuleman1-7/+8
The function brcmf_cfg80211_get_station requests the RSSI from the device. The complete structure used needs to be cleared before sending the request to firmware. Otherwise the request fails filling the logs with "Could not get rssi (-2)" messages. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-09-05brcmfmac: fix race condition for rx and tx data.Hante Meuleman1-10/+11
On both rx and tx there is was a race condition on the queueing of usb requests. When for example frame gets submitted it is possible that complete function gets called even before usb_submit_urb() returns. As a result it is possible that usb requests get losts, which was noticed on OMAP4 pandaboard platform. This patch fixes the race condition. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-09-05brcmfmac: dont use ZERO flag for usb INHante Meuleman1-1/+0
URB_ZERO_PACKET should only be set or bulk OUT and this condition is checked with a WARN_ON in usb_submit_urb(). This patch fixes brcmfmac to get rid of this warning filling the logs. Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-09-05brcmfmac: fix use of dev_kfree_skb() in irq contextArend van Spriel1-4/+4
The USB part of the brcmfmac did a dev_kfree_skb() that resulted in a warning in net/core/skbuff.c: Jul 11 04:53:33 lb-bun-10 kernel: [53282.667745] WARNING: at net/core/skbuff.c:490 skb_release_head_state+0xcc/0xe0() The brcmutil modules provides brcmu_pkt_buf_free_skb() which takes the context into account. This patch makes use of this function instead of dev_kfree_skb(). Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-08-22brcm80211: smac: set interface down on resetVladimir Zapolskiy1-0/+3
This change marks interface as down on reset, otherwise the driver can't reinitialize itself properly. Without the change a transient problem turns out to be critical and leads to inavailability to reset the driver without brcmsmac module unload/load cycle: ieee80211 phy0: wl0: PSM microcode watchdog fired at 5993 (seconds). Resetting. brcms_c_dpc : PSM Watchdog, chipid 0xa8d9, chiprev 0x1 ieee80211 phy0: wl0: fatal error, reinitializing ieee80211 phy0: Hardware restart was requested ieee80211 phy0: brcms_ops_start: brcms_up() returned -19 Signed-off-by: Vladimir Zapolskiy <vz@mleia.com> Cc: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-08-02brcmsmac: use channel flags to restrict OFDMSeth Forshee2-5/+3
brcmsmac cannot call freq_reg_info() during channel changes as it does not hold cfg80211_lock, and as a result it generates a lockdep warning. freq_reg_info() is being used to determine whether OFDM is allowed on the current channel, so we can avoid the errant call by using the new IEEE80211_CHAN_NO_OFDM for this purpose instead. Reported-by: Josh Boyer <jwboyer@redhat.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-08-01Merge branch 'for-linus' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs Pull second vfs pile from Al Viro: "The stuff in there: fsfreeze deadlock fixes by Jan (essentially, the deadlock reproduced by xfstests 068), symlink and hardlink restriction patches, plus assorted cleanups and fixes. Note that another fsfreeze deadlock (emergency thaw one) is *not* dealt with - the series by Fernando conflicts a lot with Jan's, breaks userland ABI (FIFREEZE semantics gets changed) and trades the deadlock for massive vfsmount leak; this is going to be handled next cycle. There probably will be another pull request, but that stuff won't be in it." Fix up trivial conflicts due to unrelated changes next to each other in drivers/{staging/gdm72xx/usb_boot.c, usb/gadget/storage_common.c} * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (54 commits) delousing target_core_file a bit Documentation: Correct s_umount state for freeze_fs/unfreeze_fs fs: Remove old freezing mechanism ext2: Implement freezing btrfs: Convert to new freezing mechanism nilfs2: Convert to new freezing mechanism ntfs: Convert to new freezing mechanism fuse: Convert to new freezing mechanism gfs2: Convert to new freezing mechanism ocfs2: Convert to new freezing mechanism xfs: Convert to new freezing code ext4: Convert to new freezing mechanism fs: Protect write paths by sb_start_write - sb_end_write fs: Skip atime update on frozen filesystem fs: Add freezing handling to mnt_want_write() / mnt_drop_write() fs: Improve filesystem freezing handling switch the protection of percpu_counter list to spinlock nfsd: Push mnt_want_write() outside of i_mutex btrfs: Push mnt_want_write() outside of i_mutex fat: Push mnt_want_write() outside of i_mutex ...
2012-07-29brcm80211: pointless current->files passed to filp_close()Al Viro1-1/+1
... only needed if it's been in descriptor table Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2012-07-20Merge branch 'master' of ↵John W. Linville4-12/+10
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem
2012-07-12wireless: brcm80211: use %pM to print BSSIDAndy Shevchenko1-3/+1
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-07-12brcmsmac: restructure info->control.sta handling as it is goning to be ↵Thomas Huehn3-8/+7
removed soon. brcmsmac uses info->control.sta while doing ampdu aggregation. This patch changes the usage of the structure info->control.sta, as it is going to be removed soon from struct ieee80211_tx_info. This patch is a pre-requisit in order to add transmission power control (TPC) to the mac80211 subsystem. Suggested-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Thomas Huehn <thomas@net.t-labs.tu-berlin.de> Acked-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-07-12Merge branch 'for-john' of ↵John W. Linville1-1/+2
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Conflicts: drivers/net/wireless/iwmc3200wifi/cfg80211.c drivers/net/wireless/mwifiex/cfg80211.c
2012-07-12Merge branch 'master' of ↵John W. Linville12-451/+216
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem
2012-07-12nl80211: move scan API to wdevJohannes Berg1-1/+2
The new P2P Device will have to be able to scan for P2P search, so move scanning to use struct wireless_dev instead of struct net_device. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-07-10brcmsmac: handle non PCI devices in the phy codeHauke Mehrtens1-2/+8
Some code in write_{radio,radio}_reg() should just be run if this is a pci based device. Add the condition again which was removed in commit: commit 821e4e93172e4f7d5ac1eade04665c3dc5049c4a Author: Roland Vossen <rvossen@broadcom.com> Date: Mon Aug 8 15:58:58 2011 +0200 staging: brcm80211: removed unused bus code from softmac Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Acked-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-07-10brcmsmac: fix read in write_phy_regHauke Mehrtens1-1/+1
This reverts a unintended change mad in commit. commit 4b006b11ca18995677c5f1cd03cc9c42fbe80693 Author: Arend van Spriel <arend@broadcom.com> Date: Thu Dec 8 15:06:54 2011 -0800 brcm80211: smac: use bcma functions for register access in phy code Acked-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-07-10brcmsmac: extend brcms_c_chipmatch() to also handle non PCIe devicesHauke Mehrtens3-9/+34
Now brcms_c_chipmatch() is also able to handle non PCI devices and also does some checking for SoC if they are supported by brcmsmac. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Acked-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-07-10brcmsmac: fix DMA on SoCsHauke Mehrtens1-3/+8
These extra offsets are only needed by PCIe devices and not when running on an SoC. This partly reverts commit: commit 821e4e93172e4f7d5ac1eade04665c3dc5049c4a Author: Roland Vossen <rvossen@broadcom.com> Date: Mon Aug 8 15:58:58 2011 +0200 staging: brcm80211: removed unused bus code from softmac Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Acked-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-07-10brcmsmac: extend xmtfifo_sz arrayHauke Mehrtens1-1/+19
The xmtfifo_sz array contains the queue sizes for the different core revs. This array missed the sizes for the core rev 17 and 28. This patch extends the array to also include these sizes and adds a warning if no queue size is stored in the array for the given core rev. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Acked-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-07-10brcmsmac: add some workarounds for other chips againHauke Mehrtens1-42/+89
This adds some workarounds for the BCM4716, BCM47162, BCM5357 to the phy code again. This patch reverts parts of the following patch. commit c2c724977f95135f397fe0cb45f3c041d26b91e1 Author: Arend van Spriel <arend@broadcom.com> Date: Wed Jun 29 16:46:35 2011 -0700 staging: brcm80211: remove unsupported chipset code from brcmsmac phy The BCM4716 is working for me with an other firmware and I am working on adding support for the other chips. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Acked-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-07-10brcmsmac: add a conditions for core rev 17 againHauke Mehrtens1-2/+4
This reverts some changes made in this commit: commit 7234592364e2efe8b4ac1040c99b1d7ef01cf502 Author: Roland Vossen <rvossen@broadcom.com> Date: Mon Feb 14 12:16:45 2011 +0100 staging: brcm80211: removal of inactive d11 code The bcm4716 has a rev 17 wireless core and this condition is needed. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Acked-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-07-10brcmsmac: remove some unnessessacry casts and void pointerHauke Mehrtens1-6/+5
Acked-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-07-10brcmsmac: use chip and package id constants from bcmaHauke Mehrtens5-37/+27
This patch depends on addin the chip IDs to bcma done in this commit in my pending patch series for bcma. Author: Hauke Mehrtens <hauke@hauke-m.de> Date: Sun Jun 3 18:17:57 2012 +0200 bcma: add constants for chip ids Acked-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-07-10brcmsmac: use core id constants from bcmaHauke Mehrtens2-64/+2
This patch depends on adding the IDs to bcma done in this commit in my pending patch series for bcma. Author: Hauke Mehrtens <hauke@hauke-m.de> Date: Sun Jun 3 18:17:57 2012 +0200 bcma: add constants for chip ids Acked-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-07-10brcmsmac: remove some redundant chip common workaroundsHauke Mehrtens1-42/+0
The removed workarounds are already performed in bcma_pmu_workarounds() and bcma_core_chipcommon_init() This patch depends on the completion of the workarounds in bcma done in this commit in my pending patch series for bcma. Author: Hauke Mehrtens <hauke@hauke-m.de> Date: Mon Jun 4 00:20:26 2012 +0200 bcma: complete workaround for BCMA43224 and BCM4313 Acked-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-07-10brcmsmac: remove si_pmu_spuravoid_pllupdate()Hauke Mehrtens3-86/+2
si_pmu_spuravoid_pllupdate() is now replaced by bcma_pmu_spuravoid_pllupdate() which does the same thing, but supports more chips. This function is in my pending patch series for bcma. Author: Hauke Mehrtens <hauke@hauke-m.de> Date: Mon Jun 4 01:31:32 2012 +0200 bcma: add bcma_pmu_spuravoid_pllupdate() Acked-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-07-10brcmsmac: remove si_pmu_init() and si_pmu_res_init()Hauke Mehrtens3-80/+0
This is already done by bcma_pmu_init() and bcma_pmu_resources_init() in bcma. Acked-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-07-10brcmsmac: remove ai_findcore()Hauke Mehrtens3-31/+14
bcma also stores a pointer to the chipcommon core in its struct, brcmsmac should use it and not search for the core by its own. Acked-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-07-10brcmsmac: use container_of instead of castHauke Mehrtens1-8/+8
Now "struct si_pub pub" does not have to be the first member in struct si_info any more, if it is the resulting code after compilation should be the same. Acked-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-07-10brcmsmac: remove ai_get_buscore{type,rev}()Hauke Mehrtens2-19/+0
These two functions are not used any more. Acked-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-07-10brcmsmac: remove PCI_FORCEHT() macroHauke Mehrtens1-19/+0
The BCM4716 is a SoC and does not have a PCI client interface, so this condition is never true. Acked-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-07-10brcmsmac: remove PCIE() macroHauke Mehrtens1-5/+4
Instead of checking if there is a PCIe core on the bus, better check if hosttype is PCIe. In the original submission to staging PCIE() checked, if the bustype is PCI and the buscore is a PCIe core. Now we assume that all cores bcma supports are PCIe based, so we just have to check if the bustype is PCI. The old code bcmsmac currently uses searches for a PCIe core on the bus and if there is one assumes that this is the buscore, which is wrong. Some SoCs have a PCIe core operating in host mode and this is not the bus core. The old code also caused a null pointer in ai_get_buscoretype() and ai_get_buscorerev() if buscore was not set because there was no PCIe core on the bus. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Acked-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-07-10brcmsmac: fix brcms_c_regd_init() which crashed after 11ad patchArend van Spriel1-10/+7
This patch fixes an OOPS in brcmsmac driver, which was introduced by the 11ad patch 'cfg80211: add 802.11ad (60gHz band) support'. The value IEEE80211_NUM_BANDS increased, which was used in the brcms_c_regd_init() function. Cc: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> Cc: Johannes Berg <johannes.berg@intel.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-29Merge branch 'master' of ↵John W. Linville11-1112/+715
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem Conflicts: drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c
2012-06-27brcmfmac: fix sparse warning introduced with checkdied patchArend van Spriel1-1/+1
The commit "brcmfmac: introduce checkdied debugfs functionality" also introduced a sparse warning: ..../brcmfmac/dhd_sdio.c:3147:45: sparse: cast to restricted __le32 This patch fixes this sparse warning. Reported-by: Fengguang Wu <wfg@linux.intel.com> Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-27brcmfmac: add BCM4334 supportFranky Lin4-0/+22
BCM4334 is a dualband a/b/g/n WiFi chip support 20MHz/40MHz channels. This patch adds support for its SDIO interface. Reviewed-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Franky Lin <frankyl@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-27brcmfmac: reduce allocations needed during nvram data downloadArend van Spriel1-31/+17
The nvram data is preprocessed before being sent to the device and just before sending an additional allocation was done that assured word alignment of the data. This has moved to the preprocessing step to reduce allocations and subsequent copying of the nvram data. Reviewed-by: Franky Lin <frankyl@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-27brcmfmac: use firmware data buffer directly for nvramFranky Lin1-67/+30
The nvram file could be parsed directly in the data buffer in the firmware structure passed by request_firmware function. This patch gets rid of the redundant memcpy. Reviewed-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Franky Lin <frankyl@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-27brcmfmac: move glom alignment setting to SDIO bus layerFranky Lin2-13/+15
txglomming alignment is a SDIO bus specific feature. It is more appropriate to place it in SDIO bus layer instead of common layer. Reviewed-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Franky Lin <frankyl@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-27brcmfmac: restrict dongle txglom disable to old SDIO coreFranky Lin2-6/+15
txglomming is a firmware feature for sdio bus interface. For SDIO device cores newer than revision 11, the default setting of firmware should be used instead of disabling it from the host side. Reviewed-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Franky Lin <frankyl@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-27brcmfmac: add support for bus specific data commandFranky Lin3-0/+26
brcmfmac need to support data command setting for dongle's bus core. A list must be placed at brcmf_bus structure before calling brcmf_bus_start in order to be sent by brcmf_c_preinit_dcmds. Reviewed-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Franky Lin <frankyl@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-22brcmsmac: fix NULL pointer crash in brcms_c_regd_init()Arend van Spriel1-0/+5
In the function brcms_c_regd_init() the channels are validated against the device capabilities. This is done for both 2.4G and 5G band, but there are devices that are 2.4G only, ie. BCM4313. For that device this leads to a NULL dereference. This patch adds a check in brcms_c_regd_init() to fix this. Issue introduced in wireless-next tree by following commit: cf03c5d brcm80211: smac: inform mac80211 of the X2 regulatory domain Cc: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-22brcmfmac: make inclusion of vmalloc.h explicit fixing linux-next buildArend van Spriel1-0/+1
This patch fixes problem detected in linux-next build for powerpc allyesconfig. The error message below is no longer observed: CC drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.o drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c: In function 'brcmf_sdio_dump_console': drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c:3085: error: implicit declaration of function 'vzalloc' drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c:3085: warning: assignment makes pointer from integer without a cast drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c:3113: error: implicit declaration of function 'vfree' make[2]: *** [drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.o] Error 1 Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-20brcm80211: smac: use current regulatory domain when checking whether OFDM is ↵Seth Forshee3-126/+15
allowed The brcmsmac internal regulatory data is being used to determine whether OFDM should be allowed, and this is only done once during initialization. To be effective this needs to be checked against mac80211's regulatory rules for the current channel. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-20brcm80211: smac: don't validate channels against internal regulatory dataSeth Forshee1-338/+6
The core regulatory support will disable channels not allowed by regulatory rules, so brcmsmac doesn't need to check whether or not the requested channel is permitted by regulatory. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-06-20brcm80211: smac: use mac80211 channel data for tx power limitsSeth Forshee1-59/+14
Currently the limits from the internal X2 domain are used, regardless of what regulatory rules are in effect. Instead use the power limits set by the higher-level regulatory support. The rules for the MIMO power limits are still always derived from the world domain, pending guidance from Broadcom as to how these need to be handled. This will be fixed later, but using the limits from the world domain works for now. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>