When WLAN enter full sleep mode, WLAN HW should send out a LNA_TAKE
message for BT to take control of the shared LNA. Otherwise BT traffic
is completely stopped whenever the wlan interface is moved full sleep
mode.
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
During driver stop, btcoex is disabled and also btcoex_hw.enabled
is set to false. Afterwards mci_is_enabled returns false so that
BT is not gaining SPDT control on WLAN sleep. Fix that.
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
WLAN driver initialization is muting BT which is terminating
the ongoing BT traffic. The reason to mute BT is to avoid any
incoming MCI messages from BT when MCI reset is in progress that
could corrupt WLAN MCI RX state machine. But we should not
dedicate radio completely to WLAN in driver init itself. So this
patch removes the wlan weightage changes from mute BT to retain
BT connection.
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Two MCI interrupts are generated while adding A2DP and headset profiles
with different types and same connection handle. While disconnecting,
only one MCI interrupt is generated with last added profile type value
for both profiles.
While adding second profile type decrement first one.
Signed-off-by: Bala Shanmugam <bkamatch@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Firmware supports changing filters using ACX_RX_CFG command,
so use it in .configure_filter callback. Firmware also supports
probe request filtering, so add it too along the way.
This will also re-enable BSSID filter which is now removed by
join command while associating.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This driver has a hack in cmd.c which effectively disables all filtering.
This seems to be triggering a firmware bug where it stops reporting any
rx packets after random time on some routers, which is eliminated (or at
least appears much more rarely) when filtering is on.
I have found that only BSSID filter needs to be disabled for association
to work, so disable only that instead of all filtering.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: John 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: 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>
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>
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>
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: 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>
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: 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>
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: Arend Van Spriel <arend@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: Brett Rudley <brudley@broadcom.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: John 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: Arend Van Spriel <arend@broadcom.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: John 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: 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>
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: Arend Van Spriel <arend@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: Brett Rudley <brudley@broadcom.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch adds support for WEP open/shared encryption in AP mode.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
To enhance readability, create a separate function for parsing
WPA/WPA2 related parameters from cfg80211_ap_settings.
There is no functional change in this patch.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Parse HT IE from cfg80211 and set HT capabilities accordingly
to FW. If HT IE is missing, 11n would be disabled in FW.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Kiran Divekar <dkiran@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch adds functionality to set channel info received from
cfg80211_ap_settings in start_ap handler.
Since set_channel cfg80211 handler has been removed and we need
not explicitely call mwifiex_uap_set_channel(); hence this
function definition is also removed.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Kiran Divekar <dkiran@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Adjust ah->config.ofdm_trig_{high,low} when setting noise immunity values
to simplify threshold checks in ath9k_hw_ani_monitor
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Commit af1e8a6f "ath9k: reset noiseimmunity level to default" was supposed
to ensure that the default noise immunity level is above the INI
values, however it prevents setting lower noise immunity values altogether.
Fix this by moving the checks to the right function.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It was found to be buggy on a variety of chipsets from AR913x to AR928x.
The new version (which was introduced along with AR93xx support) is more
reliable in preventing connectivity dropouts and also fixes MIB interrupt
storm issues.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Beacon RSSI is only meaningful in station mode - in ad-hoc mode it
fluctuates, depending on which peer last sent a beacon, and in other
modes it is not set at all.
Fix places in ANI where the beacon RSSI is used to limit their use
to station mode only.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Code using this had already triggered smatch complaints, so remove it before
it gets fixed the wrong way.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Commit "ath9k_hw: improve ANI processing and rx desensitizing parameters"
was unifying some code related to overriding OFDM weak signal detection,
but seems to have gotten some of the original intent wrong, probably
because of a misnamed variable.
The beacon RSSI is only valid in station mode, and the main reason to check
it in ath9k_hw_set_ofdm_nil is to make sure that OFDM weak signal detection
stays enabled if the RSSI is low, even when the OFDM noise immunity entry
is supposed to disable it.
The above commit removed the mode checks and changed the code so that
OFDM weak signal detection would only be changed if the rssi is high, which
is wrong for everything but client mode.
This patch restores the old behavior in a simplified form.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
I don't know why somebody decided to keep a cached copy of beacon rssi in a
variable called 'noiseFloor', but the caching is unnecessary and the variable
name is confusing, so let's just get rid of it entirely.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John 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: Pieter-Paul Giesberts <pieterpg@broadcom.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>
This patch support the new chipset rt3290 wifi implementation in rt2x00.
It initailize the related mac, bbp and rf register in startup phase.
And this patch modify the efuse read/write method for the different efuse data offset of rt3290.
Signed-off-by: Woody Hung <Woody.Hung@mediatek.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Now that the eeprom parsing code overrides the sku
field directly with 11n_disable parameters, there's
no longer a need to keep a copy of this field.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The effect of using a short single-channel scan
to reset the radio is that scanning a channel
that isn't in use needs to re-tune the radio.
This means that the dwell time is irrelevant,
so use a shorter time.
While at it, clean up the code for this a bit.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
My commit 26a7ca9a71 ("iwlwifi: refactor EEPROM reading/parsing")
broke the 11n_disable module parameter's BIT(0) to disable all HT
operation (using the other bits to disable aggregation only was
unaffected). Restore this by overriding the SKU when parsing the
EEPROM if the module parameter is set.
Reported-by: Matthijs Kooijman <matthijs@stdin.nl>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When the device is doing an internal radio reset
scan, ROC can be rejected to the supplicant with
busy status which confuses it.
One option would be to queue the ROC and handle
it later, but since the radio reset scan is very
quick we can just wait for it to finish instead.
Also add a warning since we shouldn't run into
the case of having a scan active when requesting
a ROC in any other case since mac80211 will not
scan while ROC or ROC while scanning.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This feature needs to be disabled for all NICs.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This variable was accessed without taking the lock.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This is really not needed, we already have a lock inside
the accesses to the prph.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This is not needed since notif_wait_lock is never accessed
from IRQ.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This is required by the op_mode API.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
A few op_mode of the op_mode API functions have requirements
on the running context of the caller. Document that.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We introduced a lock here in ff1ffb850b ("iwlwifi: fix dynamic
loading"). But we missed an error path which needs an unlock.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
