brcmf_usb_tx_ctlpkt sends message using brcmf_usb_send_ctl then
clears boolean and waits for boolean to be set (by another
thread). This can result in situation where flag gets cleared
while result was already received. First clearing the flag and
then sending the data will prevent this.

Reviewed-by: Arend Van Spriel (arend@broadcom.com)
Reviewed-by: NFranky (Zhenhui) Lin <frankyl@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NHante Meuleman <meuleman@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The brcmsmac driver requests firmware but doesn't document the
dependency. This means that software that analyzes the modules to
determine if firmware is needed won't detect it.

Specifically, (at least) openSUSE won't install the kernel-firmware
package if no hardware requires it.

This patch adds the MODULE_FIRMWARE directives.
Signed-off-by: NJeff Mahoney <jeffm@suse.com>
Acked-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Instead of hard-coding almost the same functionality,
just use ieee80211_channel_to_frequency() directly.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Remove the control.sta pointer from ieee80211_tx_info to free up
sufficient space in the TX skb control buffer for the upcoming
Transmit Power Control (TPC).
Instead, the pointer is now on the stack in a new control struct
that is passed as a function parameter to the drivers' tx method.
Signed-off-by: NThomas Huehn <thomas@net.t-labs.tu-berlin.de>
Signed-off-by: NAlina Friedrichsen <x-alina@gmx.net>
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
[reworded commit message]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NThomas Huehn <thomas@net.t-labs.tu-berlin.de>
Acked-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NJohannes Berg <johannes.berg@intel.com>

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 821e4e93
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: NHauke Mehrtens <hauke@hauke-m.de>
Acked-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This reverts a unintended change mad in commit.
commit 4b006b11
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: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NHauke Mehrtens <hauke@hauke-m.de>
Acked-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

These extra offsets are only needed by PCIe devices and not when
running on an SoC.

This partly reverts commit:
commit 821e4e93
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: NHauke Mehrtens <hauke@hauke-m.de>
Acked-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NHauke Mehrtens <hauke@hauke-m.de>
Acked-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This adds some workarounds for the BCM4716, BCM47162, BCM5357 to the
phy code again. This patch reverts parts of the following patch.

commit c2c72497
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: NHauke Mehrtens <hauke@hauke-m.de>
Acked-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This reverts some changes made in this commit:
commit 72345923
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: NHauke Mehrtens <hauke@hauke-m.de>
Acked-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Acked-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is already done by bcma_pmu_init() and bcma_pmu_resources_init() in bcma.
Acked-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

These two functions are not used any more.
Acked-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The BCM4716 is a SoC and does not have a PCI client interface, so this
condition is never true.
Acked-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NHauke Mehrtens <hauke@hauke-m.de>
Acked-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NFengguang Wu <wfg@linux.intel.com>
Reviewed-by: NFranky (Zhenhui) Lin <frankyl@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

BCM4334 is a dualband a/b/g/n WiFi chip support 20MHz/40MHz
channels. This patch adds support for its SDIO interface.
Reviewed-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NFranky Lin <frankyl@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NFranky Lin <frankyl@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NFranky Lin <frankyl@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NFranky Lin <frankyl@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NFranky Lin <frankyl@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NFranky Lin <frankyl@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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:
cf03c5da brcm80211: smac: inform mac80211 of the X2 regulatory domain

Cc: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NArend Van Spriel <arend@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NArend Van Spriel <arend@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NArend Van Spriel <arend@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently the radio disable state is only updated during initialization,
and it's only checked against the internal world domain. This is
unnecessary, as there are always valid channels against this domain.
Instead, check whether any channels are enabled in the regulatory
notifier and update the radio state accordingly.
Reviewed-by: NArend Van Spriel <arend@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

brcmsmac implements enforcement of regulatory constraints internally,
using a Broadcom-specific world roaming domain named X2. Besides being
duplication of functionality this can also conflict with mac80211's
regulatory implementation, as mac80211 is unaware of the X2 domain and
thus might apply a more restrictive domain.

This patch is the first step in making brcmsmac cooperate with
mac80211's regulatory support. X2 is registered as a custom domain with
mac80211, so that at least both implementations will be enforcing the
same set of constraints. The internal enforcement of rules is kept for
now; this will be converted over to relying on mac80211 regulatory
enforcement in later patches.
Reviewed-by: NArend Van Spriel <arend@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>