There's only one place using this function, so
move it where it's needed.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We should be doing a shift (1 << FLAG_RADIO_DOWN) here before testing
the flag.  As luck would have it, this test works almost correctly.
The current code tests for FLAG_RADIO_OFF instead of FLAG_RADIO_DOWN.

#define FLAG_RADIO_OFF  0       /* User disabling of MAC */
#define FLAG_RADIO_DOWN 1       /* ifup/ifdown disabling of MAC */
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If we only monitor while associated, the following
can happen:
 - we're associated, and the queue stuck check
   runs, setting the queue "touch" time to X
 - we disassociate, stopping the monitoring,
   which leaves the time set to X
 - almost 2s later, we associate, and enqueue
   a frame
 - before the frame is transmitted, we monitor
   for stuck queues, and find the time set to
   X, although it is now later than X + 2000ms,
   so we decide that the queue is stuck and
   erroneously restart the device

It happens more with P2P because there we can
go between associated/unassociated frequently.

Cc: stable@vger.kernel.org
Reported-by: NBen Cahill <ben.m.cahill@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Driver rtl8192ce when used with the RTL8188CE device would start at about
20 Mbps on a 54 Mbps connection, but quickly drop to 1 Mbps. One of the
symptoms is that the AP would need to retransmit each packet 4 of 5 times
before the driver would acknowledge it. Recovery is possible only by
unloading and reloading the driver. This problem was reported at
https://bugzilla.redhat.com/show_bug.cgi?id=770207.

The problem is due to a missing update of the gain setting.
Signed-off-by: NJingjun Wu <jingjun_wu@realsil.com.cn>
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch allows the possibility of having the mesh point and AP to be operated
simultaneously in one single radio. Previously, mesh point fails to generate the
mesh beacon if virtual AP is created for the same radio.
Signed-off-by: NChun-Yeow Yeoh <yeohchunyeow@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add the signal strength (in dBm only for now) to
frames that are received via nl80211's various
frame APIs.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Acked-by: NKalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Tidying up some debug statements in brcms_c_ampdu_dotxstatus_complete()
that got broken strings to satisfy checkpatch, but the rules changed.
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: NAlwin Beukers <alwin@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

As indicated in [1] on netdev mailing list drivers should not block
on the init_module() syscall. This patch defers the actual driver
registration to a workqueue so the init_module() syscall can complete
without delay.

[1] http://article.gmane.org/gmane.linux.network/217729/Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: NAlwin Beukers <alwin@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

As indicated in [1] on netdev mailing list drivers should not block
on the init_module() syscall. This patch defers the actual driver
registration to a workqueue so the init_module() syscall can complete
without delay.

[1] http://article.gmane.org/gmane.linux.network/217729/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 module init function of brcmfmac calls init functions for SDIO and
USB doing driver registration. This patch removes terminating the module
init when a driver registration for one host interface fails.
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 usb code defines a structure for counting statistics. However,
it should use the statistics entry provided in brcmf_bus as that is
exposed to the net_device. The usb private statistics counter only
remains with counters for control packets between driver and usb
device.
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>

Several fields in this structure are only written once or not used
at all. Remaining two fields have been moved and brcmf_usb_attrib
definition has been removed.
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: NFranky (Zhenhui) Lin <frankyl@broadcom.com>
Reviewed-by: NKan Yan <kanyan@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In brcmf_usb_up() the variable devinfo was checked for being
a NULL pointer, but this can not happen. Also the check was done
after dereferencing the pointer. This patch removes the check.
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: NFranky (Zhenhui) Lin <frankyl@broadcom.com>
Reviewed-by: NKan Yan <kanyan@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When driver rtl8192cu is used with the debug level set to 3 or greater,
the result is "sleeping function called from invalid context" due to
an rcu_read_lock() call in the DM refresh routine in driver rtl8192c.
This lock is not necessary as the USB driver does not use the struct
being protected, thus the lock is set only when a PCI interface is
active.

This bug is reported in https://bugzilla.kernel.org/show_bug.cgi?id=42775.
Reported-by: NRonald Wahl <ronald.wahl@raritan.com>
Tested-by: NRonald Wahl <ronald.wahl@raritan.com>
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>
Cc: Ronald Wahl <ronald.wahl@raritan.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In usb.c, routine _rtl_usb_init_sw() always returns 0, and rtl_usb_probe()
never checks the returned value. Thus we can change _rtl_usb_init_sw() to
a void routine. In addition, remove the underscore at the beginning of the
name of the routine.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In the unlikely event of a misread of the USB end point count, the driver
generates a divide fault. To prevent this, add a check of the value
returned by _rtl_usb_init(). In addition, add some logging to indicate
why the condition occurred.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In mwifiex_drv_change_adhoc_chan() we pass channel to
mwifiex_bss_ioctl_ibss_channel() which sets the high 16 bits.  This
works on little endian systems but not on big endian ones.  I've changed
mwifiex_drv_change_adhoc_chan() to use a 16 bit variable.  This matches
the other functions in the file.

I considered changing mwifiex_change_adhoc_chan() as well but it turns
out that the function isn't implemented so I just removed the
definition.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This makes it possible to reload driver if insmod has failed due to
missing firmware.
Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

cfg80211 uses u8 for key indexes and so should rndis_wlan.
Signed-off-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Use new RNDIS_WLAN_NUM_KEYS for checks in add_wep_key() and add_wpa_key().
Signed-off-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

'beacon_period' in 'struct ndis_80211_conf' is __le32 instead of __le16 so
le32_to_cpu must be used instead of le16_to_cpu.

Also correct 'beacon_interval' variables used for passing this value forward
from u16 to u32 and rename those variables 'beacon_period' This is to avoid
confusion because 'beacon_interval' is defined as __le16 at other structure,
'struct ndis_80211_fixed_ies'.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If we pick a high value for "offset" then it could lead to an integer
overflow and we would get past the check for:
	if (offset + len > buflen) { ...
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

These variables can never be less than zero because we cap them in
get_device_pmkids().  Let's make them unsigned here because it's simpler
to not have to worry about negative numbers when we read the code.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We never use the "len" variable.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If "offset" is negative then we can get past this check:
	if (offset > CONTROL_BUFFER_SIZE)
Or if we pick a very high "req_ie_len" then we can get around the check:
	if (offset + req_ie_len > CONTROL_BUFFER_SIZE)

I made "resp_ie_len" and "req_ie_len" unsigned.  I don't know if it was
intentional that they were signed in the original.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When using the bcm5354 (Soc with integrated LP-PHY Wifi) with a recent
firmware >= 478.104 it runs out of memory after a very short time in
OpenWrt after doing an active scan or any thing else where packages are
send. This was cased by a gpio misconfiguration, the firmware triggered
the GPIO pins used for buttons on some devices and that caused an other
driver (OpenWrt diag) listening for these buttons irqs to send many
messages to the user space.
This patch fixes the bug for my devices (Asus WL-520GU) and makes it
work with firmware 666.2. Now the firmware just uses LED GPIO pin
number 1 and not the button pins any more.

This is the GPIO Pin layout used on my device, see [0].
GPIO pin layout:
pin#    name    type
0       power   led
1       wlan    led
2       reset   button
3       ses     buttom

This is the nvram configuration output of "nvram show |grep gpio"

related nvram configuration:
wl0gpio2=11
wl0gpio3=11
wl0gpio0=11
wl0gpio1=0x02
reset_gpio=2

[0]: https://dev.openwrt.org/browser/trunk/package/broadcom-diag/src/diag.cSigned-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

this does the same thing as the previous code
Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

its better to zero initialize the 'valid_phy_rate_idx' array completely
Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently if valid SSID list is provided in scan request, driver
performs specific SSID scan otherwise wildcard scan is chosen.

When wpa_supplicant provides valid SSID list followed by
zero-length SSID for wildcard scan, only specific SSID scan is
performed by driver. Actually driver is expected to do both type
of scanning in this case. The patch fixes this issue.

Also, use SSID list pointer provided by stack directly, instead
of copying SSID's to local structure.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Use struct cfg80211_ssid available in include/net/cfg80211.h
instead of having similar definition in driver.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

1. Driver and firmware do not support 22Mbps and 72Mbps bitrates.
Remove them from the rate table advertised to cfg80211.

2. First 4 rates from mwifiex_rates table are not valid for
5GHz/A band. Set correct bitrate array's index and no of rates for
ieee80211_supported_band for 5GHz band.
Signed-off-by: NAvinash Patil <patila@marvell.com>
Signed-off-by: NNishant Sarmukadam <nishants@marvell.com>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: NKiran Divekar <dkiran@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On SoCs the sprom is stored in the nvram in a special partition on the
flash chip. The nvram contains the sprom for the main bus, but
sometimes also for a pci devices using bcma. This patch makes it
possible for the arch code to register a function to fetch the needed
sprom from the nvram and provide it to the bcma code.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This function is needed by the bcm47xx arch code to get the number of
the ieee80211 core.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There is no 2.4 GHz or 5GHz antenna gain stored in sprom. The sprom
just stores the gain values for antenna 1 and 2 or 1 to 4 for more
recent sprom versions. On old devices antenna 2 was used for 5 GHz wifi.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Not doing so could cause the tx status queue to overflow during longer
periods of time without non-beacon tx. These events are also required
for proper drv_tx_last_beacon handling.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Since AR9003 uses a global tx status queue, processing tx status outside of
the regular tx tasklet is dangerous and messes up hardware/software
synchronization of tx status events.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The approach of this change is flawed, as it triggers tx status processing
from more callsites, yet the chips only have one global tx status queue.
Subsequent patches will properly fix the issue that this one tried to address.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>