Almost all the DMA issues which have plagued ath9k (in station mode)
for years are related to PS. Disabling PS usually "fixes" the user's
connection stablility. Reports of DMA problems are still trickling in
and are sitting in the kernel bugzilla. Until the PS code in ath9k is
given a thorough review, disbale it by default. The slight increase
in chip power consumption is a small price to pay for improved link
stability.
Cc: stable@vger.kernel.org
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This false leak indication is avoided with a no-leak annotation to kmemleak.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Due to a typo, the current code copies only sizeof(cmd->channels_2)
bytes, which is smaller than the correct sizeof(cmd->channels_5)
size, resulting in a partial scan (some channels are skipped).
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The minimum firmware version required for singlerole after recent
driver changes is 6/7.3.10.0.133.
Reported-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There was a typo in commit 8675f9 (wlcore/wl12xx/wl18xx: verify
multi-role and single-role fw versions), which was causing the
multirole firmware for wl127x (WiLink6) to be rejected. The actual
minimum version needed for wl127x multirole is 6.5.7.0.42.
Reported-by: Levi Pearson <levipearson@gmail.com>
Reported-by: Michael Scott <hashcode0f@gmail.com>
Cc: stable@kernel.org # 3.9+
Signed-off-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Since driver does not use control.rates[0].count, we have never set that
variable. But currently, after rate control API rewrite, this is required
by mac80211. Otherwise legacy rates control does not work and we transmit
always at 1Mbit/s on pre 11n networks.
[same fix as for iwlegacy, thanks Stanislaw!]
Signed-off-by: Moshe Benji <Moshe.Benji@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
iwlmvm does not support concurrent operation of AP with P2P Client/GO.
Update the interface limits to reflect that iwlmvm supports only
concurrent operation of station with AP and P2P Client/GO.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The MCAST queue should be enabled after DTIM only.
According to fw API, the MCAST must not be attached to any
station, but should appear in the mcast_qid of the AP's
mac context only.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We only need EXPORT_SYMBOL_GPL, none of the other things
from module.h, so only include export.h.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This is only really useful for people who are bringing up new hardware
designs and have access to the proprietary vendor tools that interface
with this mode.
It'll live out of tree until it's rewritten to use a less kludgy interface.
Signed-off-by: Solomon Peachy <pizza@shaftnet.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This can live on as an out-of-tree patch for those that care.
Signed-off-by: Solomon Peachy <pizza@shaftnet.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
cfg80211 passes a NULL channel to mgmt_tx if the frame has
to be sent on the one currently in use by the device.
Make the implementation of mgmt_tx correctly handle this
case
Cc: Nicolas Cavallari <Nicolas.Cavallari@lri.fr>
Acked-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Support for rt2800 device is broken since my
'rt2x00: rt2x00dev: use rt2x00dev->tx->limit'
patch. The changelog of that commit says that the
TX data queue is initialized already when the
rt2x00lib_probe_hw() function is called.
However as Jakub noticed it, this statement is not
correct. The queue->limit field is initialized in
the rt2x00queue_alloc_entries routine and that is
not yet called when rt2x00lib_probe_hw() runs.
Because the value of tx->limit contains zero, the
driver tries to allocate a kernel fifo with zero
size and kfifo_alloc rejects that with -EINVAL.
PCI: Enabling device 0000:01:00.0 (0000 -> 0002)
ieee80211 phy1: rt2x00_set_rt: Info - RT chipset 3071, rev 021c detected
ieee80211 phy1: rt2x00_set_rf: Info - RF chipset 0008 detected
ieee80211 phy1: rt2x00lib_probe_dev: Error - Failed to initialize hw
rt2800pci: probe of 0000:01:00.0 failed with error -22
Move the data_queue field initialization from
the rt2x00queue_alloc_entries routine into the
rt2x00queue_init function. The initialization
code is not strictly related to the allocation,
and the change ensures that the queue_data fields
can be used in the probe routines.
The patch also introduces a helper function in
order to be able to get the correct data_queue_desc
structure for a given queue. This helper is only
needed temporarily and it will be removed later.
Reported-by: Jakub Kicinski <moorray@wp.pl>
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
GCC 4.8 is spitting out uninitialized-variable warnings against
"drivers/net/wireless/rtlwifi/rtl8192de/dm.c".
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:941:31:
error: 'ofdm_index_old[1]' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
rtlpriv->dm.ofdm_index[i] = ofdm_index_old[i];
This patch adds initialization to the variable and properly sets its value.
Signed-off-by: Yunlian Jiang <yunlian@google.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Check for allocation failures and return -ENOMEM. The caller
already expects it.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This has only one caller and rates[] is an array with
IEEE80211_TX_MAX_RATES (4) elements.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The optional debugfs interface to the vendor's engineering tools wasn't
bounds checking at all, which made it trivial to perform a buffer
overflow if this interface was compiled in and then explicitly enabled
at runtime.
This patch checks both the length supplied as part of the data to ensure
it is sane, and also the amount of data compared to the remaining buffer
space. If either is too large, fail immediately.
(This bug was spotted by Dan Carpenter <dan.carpenter@oracle.com>)
Signed-off-by: Solomon Peachy <pizza@shaftnet.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
goto after return is wrong.
The other code in this block needs to set an
error value then goto an error release block.
This one doesn't need to release anything and
was likely a copy/paste remainder.
Signed-off-by: Joe Perches <joe@perches.com>
Acked-By: Solomon Peachy <pizza@shaftnet.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Merge 'net' bug fixes into 'net-next' as we have patches
that will build on top of them.
This merge commit includes a change from Emil Goode
(emilgoode@gmail.com) that fixes a warning that would
have been introduced by this merge. Specifically it
fixes the pingv6_ops method ipv6_chk_addr() to add a
"const" to the "struct net_device *dev" argument and
likewise update the dummy_ipv6_chk_addr() declaration.
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently beacon availability upon association is marked by have_beacon
flag of assoc_data structure that becomes unavailable when association
completes. However beacon availability indication is required also after
association to inform a driver. Currently dtim_period parameter is used
for this purpose. Move have_beacon flag to another structure, persistant
throughout a interface's life cycle. Use suitable sematics for beacon
availability indication.
Signed-off-by: Alexander Bondar <alexander.bondar@intel.com>
[fix another instance of BSS_CHANGED_DTIM_PERIOD in docs]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In multicast, there is no retries nor RTS since there is no
specific recipient that can ACK or send CTS. This means
that we must not use the rate scale table for multicast
frames.
This true for any frame that doesn't have a valid
ieee80211_sta pointer.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In unassociated BSS STA mode FW verifies both power save and power
management flags to decide on switching power off. The driver currently
sets power management flag according to mac80211 decision. As result, in
unassociated mode power management flag is down and power consumption is
high. Change power management enablement. When unassociated in BPS and
LP power save modes enable power management regardless of mac80211
decision. Rely on mac80211 decision if associated. Add power management
state update during associated/disassociated modes transitions.
Signed-off-by: Alexander Bondar <alexander.bondar@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently vif_count verification for power management enablement appear
in different places. Move these verifications to one place in
iwl_mvm_update_power_mode().
Signed-off-by: Alexander Bondar <alexander.bondar@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The AP mode needs to use the MCAST fifo for the MCAST
frames sent after the DTIM. This fifo needs to be
configured with the same parameters as the VOICE FIFO.
A separate SCD queue is mapped to this fifo - the cab_queue
(cab stands for Content After Beacon). This queue isn't
connected to any station, but rather to the MAC context.
This queue should (and is already) be set as the MCAST
queue - this is part of the of MAC context command.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Since SCAN related handlers are much less likely than
beacon related handlers, reorder between them.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
According to the FW implementation, the quota command should
have a valid entry for each active binding (where 'active' in
this context means that the binding is known to the FW). In case
the binding should not get any quota, the 'quota' should be set
to zero.
Not setting an 0 quota for an active binding when all the MACs
in the binding are idle, i.e., not associated in case of managed
interface, will result in preventing the FW scheduler from entering
IDLE state and the FW from transitioning to low PS.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When CMD_SEND_IN_RFKILL is set, it is perfectly legitimate
to send a host command while RFKILL is asserted. In this
case, the host command sending functions should return 0
even if RFKILL is asserted.
Signed-off-by: Eran Harary <eran.harary@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
First step of chain noise calibration process had disable flag
check inverted. Chain noise calibration never started because
of this.
Tested on intel 5300 with two antennas attached. The driver
correctly disabled one chain.
Cc: stable@vger.kernel.org
Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If the opmode modules aren't modular, there's no point in
printing an error message that request_module() failed.
This will happen because the probe runs during iwlwifi's
init and the opmode is only added during its init.
Reported-by: Jörg Otte <jrg.otte@gmail.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
