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>

Much of the code is either unsed or never put to any useful purpose.
Remove this code in advance of reworking the driver's regulatory
support.
Reviewed-by: NArend Van Spriel <arend@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: NBrett Rudley <brudley@broadcom.com>
Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This code has been kept around in anticipation of adding support for
40MHz channels, but subsequent patches to better integrate with mac80211
regulatory support will render it completely broken. Therefore we should
go ahead and remove it.

Keep these changes separate from other cleanup patches in order to make
it easier to resurrect 40MHz channel support at some point in the
future.
Reviewed-by: NArend Van Spriel <arend@broadcom.com>
Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In some situations brcmsmac is choosing a channel internally. This makes
it difficult at times to know what channel to use for enforcing
regulatory constraints, so instead always use the channel from the
mac80211 configuration.
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>

This code is unnecessary, and in fact it's never executed because the
interface is never up when brcms_c_channels_commit() is called. Removing
it helps simplify the implementation of proper regulatory support.
Reviewed-by: NArend Van Spriel <arend@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: NBrett Rudley <brudley@broadcom.com>
Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The checkdied functionality provides useful information for analyzing
firmware crashes. By exposing this information to a debugfs file users
can easily provide its content in bug reports. The functionality is
available only when CONFIG_BRCMDBG is selected.
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.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>

The structure brcmf_sdio contains a number of counters that are useful
for debugging. These were not available in user-space. This patch
exposes them in debugfs under the filename 'counters'.
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.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>

This patch adds debugfs support to brcmfmac. It provide helper functions
to setup the debugfs folder structure for the driver, which has following
hierarchy:

<debugfs_mount>/brcmfmac/<dev_name>/

ie.: /sys/kernel/debug/brcmfmac/mmc0:0001:2/

The new source file provides functions to create and remove the two
folders and a function to retrieve the device-specific folder so files
can be created in it.
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.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>

This patch fixes potential NULL pointer dereference in ampdu. This
was found running smatch static code checker. Smatch warning says:

drivers/net/wireless/brcm80211/brcmsmac/ampdu.c:741 brcms_c_sendampdu()
	 warn: variable dereferenced before check 'p'
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The function brcms_set_hint() does not add any functionality
so regulatory_hint() can be called directly. The error value
has been removed from the message when regulatory_hint() fails.
Reported-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>

Fixed checkpatch and sparse warnings related to aiutils.*
Signed-off-by: NChris Yungmann <yungmann.chris@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is potentially called with NULL pointers, for example, look at
brcmf_c_prec_enq().  Since it's a free() function, probably people
expect it to handle NULL pointers.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This code causes a static checker warning because "pi" gets dereferenced
before it is checked.  The dereference is inside the write_phy_reg()
function which is called from wlc_phy_write_txmacreg_nphy().

This code is only called from wlc_phy_init_nphy() and "pi" is a
valid pointer so we can remove the check for NULL.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Using | with a constant is always true.
Likely this should have be &.
Signed-off-by: NJoe Perches <joe@perches.com>
Acked-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The firmware is more than 300KB big and you should not use kmalloc for
such big allocations. This allocation with kmalloc failed on my mips
based device (BCM47186).
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Acked-by: NFranky Lin <frankyl@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Fix missing comma.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: NWu Fengguang <wfg@linux.intel.com>

Hub-initiated LPM is not good for USB communications devices.  Comms
devices should be able to tell when their link can go into a lower power
state, because they know when an incoming transmission is finished.
Ideally, these devices would slam their links into a lower power state,
using the device-initiated LPM, after finishing the last packet of their
data transfer.

If we enable the idle timeouts for the parent hubs to enable
hub-initiated LPM, we will get a lot of useless LPM packets on the bus
as the devices reject LPM transitions when they're in the middle of
receiving data.  Worse, some devices might blindly accept the
hub-initiated LPM and power down their radios while they're in the
middle of receiving a transmission.

The Intel Windows folks are disabling hub-initiated LPM for all USB
communications devices under a xHCI USB 3.0 host.  In order to keep
the Linux behavior as close as possible to Windows, we need to do the
same in Linux.

Set the disable_hub_initiated_lpm flag for for all USB communications
drivers.  I know there aren't currently any USB 3.0 devices that
implement these class specifications, but we should be ready if they do.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Cc: Hansjoerg Lipp <hjlipp@web.de>
Cc: Tilman Schmidt <tilman@imap.cc>
Cc: Karsten Keil <isdn@linux-pingi.de>
Cc: Peter Korsgaard <jacmet@sunsite.dk>
Cc: Jan Dumon <j.dumon@option.com>
Cc: Petko Manolov <petkan@users.sourceforge.net>
Cc: Steve Glendinning <steve.glendinning@smsc.com>
Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: Kalle Valo <kvalo@qca.qualcomm.com>
Cc: "Luis R. Rodriguez" <mcgrof@qca.qualcomm.com>
Cc: Jouni Malinen <jouni@qca.qualcomm.com>
Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Cc: Christian Lamparter <chunkeey@googlemail.com>
Cc: Brett Rudley <brudley@broadcom.com>
Cc: Roland Vossen <rvossen@broadcom.com>
Cc: Arend van Spriel <arend@broadcom.com>
Cc: "Franky (Zhenhui) Lin" <frankyl@broadcom.com>
Cc: Kan Yan <kanyan@broadcom.com>
Cc: Dan Williams <dcbw@redhat.com>
Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Cc: Ivo van Doorn <IvDoorn@gmail.com>
Cc: Gertjan van Wingerde <gwingerde@gmail.com>
Cc: Helmut Schaa <helmut.schaa@googlemail.com>
Cc: Herton Ronaldo Krzesinski <herton@canonical.com>
Cc: Hin-Tak Leung <htl10@users.sourceforge.net>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Chaoming Li <chaoming_li@realsil.com.cn>
Cc: Daniel Drake <dsd@gentoo.org>
Cc: Ulrich Kunitz <kune@deine-taler.de>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

This is based on code from the Broadcom SDK.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Tested-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If brcmsmac is used on non PCI(s) devices it should not try to access
bus->host_pci.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Tested-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The irq number is copied from the PCIe host device to the bcma cores so
just request it using the bcma core device.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Tested-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There is no code doing anything useful in nicpci.c anymore, so remove
it.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Tested-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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

This is now done by calling bcma_core_pci_extend_L1time()
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Tested-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This function is now unreferenced
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Tested-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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

This is now done by calling bcma_core_set_clockmode()
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Tested-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is now done by calling bcma_chipco_gpio_control().
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Tested-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ai_chipcontrl_epa4331 is not referenced by any method in brcmsmac and
the functionality is already in bcma_chipco_bcm4331_ext_pa_lines_ctl in
drivers/bcma/driver_chipcommon_pmu.c
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Tested-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>