It is preferred to use the setter that to set queue_mapping directly.
This also helps backporting in compat-wireless.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Luciano Coelho <coelho@ti.com>
When packets arrive with a RX descriptor indicating corruption, discard
them.
In general white-list the RX descriptor status to prevent rouge data
from being sent up.
Signed-off-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Frames are considered pending when they reside in the driver TX queue or
already queued in the FW.
This notion of "pending" is appropriate for power save considerations in
STA mode, but not necessarily in other modes (for instance P2P-GO).
[Fixed a sparse warning about missing "static" in a function
declaration -- Luca]
Signed-off-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
The FW can dynamically manage its internal TX & RX memory pools, moving
blocks from one pool to another when necessary. This can significantly
improve performance. Currently this feature is enabled only for 128x.
Enable dynamic memory for 127x as well. Other parameters in the memory
configuration structure may need to be fine tuned, as the optimal values
for these may change once dynamic memory is enabled.
Signed-off-by: Ido Yariv <ido@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
The driver stops sending TX packets when either there aren't enough
memory blocks, or it runs out of TX descriptors. The driver continues to
send packets to the FW only when more memory blocks are available.
The FW might free TX descriptors without freeing the corresponding
memory blocks, especially when dynamic memory is enabled. In cases where
memory blocks are not freed at all, the driver will keep waiting for
more memory blocks indefinitely.
Fix this by clearing the WL1271_FLAG_FW_TX_BUSY flag when there are
available TX descriptors.
Signed-off-by: Ido Yariv <ido@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
The 128x/AP firmware does not yet support dynamic memory. Temporarily,
the memory configuration for the 127x was used both for 127x/AP as well
as 128x/AP. Since the two chips don't have the same number of memory
blocks, TP was significantly degraded.
This hasn't been fine tuned yet, but using the base 128x numbers
(without dynamic memory) seems to yield much better results (around 30%
more). Additional fine tuning will be required in the future.
Signed-off-by: Ido Yariv <ido@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
When configuring ACX_WAKE_UP_CONDITIONS (before entering psm), we
tell the firmware to wake up once in N DTIMs/beacons.
Allow control of this value via debugfs (for debugging purposes).
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Reducing the retries of sending PS exit packets to the peer AP.
That fix is to avoid sending unrealizable number of PS exit packets
in case of ap lost.
Signed-off-by: Shahar Levi <shahar_levi@ti.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Add support to FM WLAN coexistence (STA only). Some WiFi harmonics
may interfere with FM operation, to avoid this problem special
coexistence techniques are activated around some FM frequencies.
Signed-off-by: Shahar Levi <shahar_levi@ti.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
When working in ibss mode, we don't configure rate policy per station
(as we use the same link for multiple stations), so currently the
1mb/s rate is being used.
Instead, configure the firmware to use the whole 11b rates by default.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
ieee80211_reconfig() sets most of the "changed" flags regardless
of the actual change (e.g. BSS_CHANGED_ASSOC will be set even if
the interface is still not associated). in this case the driver
will issue some unneeded commands.
Since the driver relies solely on the BSS_CHANGED_ASSOC flag,
without checking if there was an actual change, it will end up
issuing unjoin() and dummy_join() commands, although it was
never associated and should just remain idle.
Avoid it by checking the actual state change, in addition to the
"changed" flag.
(there seem to be more redundant configuration commands being
issued, but they shouldn't harm)
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
When debugging, reduce the padding size from each rx packet, to
get the actual packet size (so comparing it against a cap file
will be easier)
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Fix mismatch between the REF CLK and TCXO CLK information that is
set in the platform data and the NVS, so we override what comes
from the NVS and replace it with what comes from the platform data.
[Small fix in a comment -- Luca]
Signed-off-by: Shahar Levi <shahar_levi@ti.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
The elp_work is being enqueued on wl1271_ps_elp_sleep, but doesn't get
cancelled on wl1271_ps_elp_wakeup. This might cause immediate entrance
to elp when the wl->mutex is being released, rather than using the delayed
enqueueing optimization.
Cancel elp_work on wakeup request, and add a new WL1271_FLAG_ELP_REQUESTED
flag to further synchronize the elp actions.
[Fixed a couple of typos in some comments -- Luca]
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
commit d05c806 ("wl12xx: rearrange some ELP wake_up/sleep calls")
introduced a bug in which wl1271_ps_elp_wakeup() was called instead
of wl1271_ps_elp_sleep() after completing the tx work.
Reported-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
End-of-transaction flag should be set when working with
wl127x chip on AP mode.
Thanks Ido Yariv <ido@wizery.com> for the guidance with that.
Signed-off-by: Shahar Levi <shahar_levi@ti.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
The tx_headroom required for mwl8k driver is 32 bytes and it
can use the space for 802.11 header received from mac80211.
mwl8k considers the smallest 802.11 frame (CTS2self of 10
bytes) that can be received from mac80211 to compute the
extra_tx_headroom as 22 (32 - 10) bytes.
When the wireless interface is part of bridge, this
extra_tx_headroom requirement results in a memcpy in
mac80211 (in function pskb_expand_head) for all the data
frames needing L2 forwarding/bridging, when NET_SKB_PAD is
defined as 32. This patch reduces the extra_tx_headroom by
8 bytes so that memcpy of data frames in mac80211 is
avoided in this case.
The resize will be required in driver for frames with 802.11
header size of less than 18 bytes.
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: Pradeep Nemavat <pnemavat@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Remove all the convoluted hacks in the driver and simplify things
by making use of mac80211's LED triggers.
Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We now use priv->mutex to serialize sync command, remove old
priv->sync_cmd_mutex and add assertion that priv->mutex must be locked.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Check status bits with mutex taken, because when we wait for mutex
unlock, status can change. Patch should also make remaining sync
commands be send with priv->mutex taken. That will prevent execute
these commands when we are currently reset firmware, what could
possibly cause troubles.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We mark command as huge by using meta->flags from other (non huge) command,
but flags can be possibly overridden, when non huge command is enqueued,
what can lead to:
WARNING: at lib/dma-debug.c:696 dma_debug_device_change+0x1a3/0x1f0()
DMA-API: device driver has pending DMA allocations while released from device [count=1]
To fix introduce additional CMD_MAPPED to mark command as mapped and
serialize iwl_enqueue_hcmd() with iwl_tx_cmd_complete() using
hcmd_lock. Serialization will also fix possible race conditions,
because q->read_ptr, q->write_ptr are modified/used in parallel.
Do not change callback, I did (and fixed) that mistake in iwlagn.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
struct iwl_queue is not part of firmware interface, so __packed is not
needed. Remove it since is may affect performance.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We never set STATUS_SCANNING in softwre scanning mode, disable_hw_scan
check is unneeded. Correct debug message while at it.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Don't need to use conditional as ch->band is already assigned to
IEEE80211_BAND_5GHZ or IEEE80211_BAND_2GHZ
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add two below iwlwifi commits to iwlegacy:
commit 554d1d027b
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Thu Dec 23 12:38:21 2010 +0100
iwlagn: enable only rfkill interrupt when device is down
commit 3dd823e6b8
Author: Don Fry <donald.h.fry@intel.com>
Date: Sun Feb 6 09:29:45 2011 -0800
iwlagn: Re-enable RF_KILL interrupt when down
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Since
commit f844a709a7
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Fri Jan 28 16:47:44 2011 +0100
iwlwifi: do not set tx power when channel is changing
we set device tx power during initialization to priv->tx_power_next,
which itself is initialized to minimum power. That changed
default behaviour of driver. Previously we initialized device to
transmit at maximum available power by default. Patch change again
to previous behaviour and cleanup tx power initialization.
Fortunately this is not critical fix, as mac80211 layer setup
tx power lately to 14dB, hence device does not operate at minimal
transmit power all the time.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
CC [M] drivers/net/wireless/p54/eeprom.o
drivers/net/wireless/p54/eeprom.c: In function ‘p54_parse_rssical’:
drivers/net/wireless/p54/eeprom.c:494:8: warning: ‘freq’ may be used uninitialized in this function
Signed-off-by: John W. Linville <linville@tuxdriver.com>
CC [M] drivers/net/wireless/mwifiex/join.o
drivers/net/wireless/mwifiex/join.c: In function ‘mwifiex_cmd_802_11_associate’:
drivers/net/wireless/mwifiex/join.c:119:8: warning: ‘tsf_val’ may be used uninitialized in this function
drivers/net/wireless/mwifiex/join.c:103:12: note: ‘tsf_val’ was declared here
Looks like a copy-n-paste error, identical lines are a few lines below
the ones removed, with an actual memcpy to tsf_val in between...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
CC [M] drivers/net/wireless/b43/phy_n.o
drivers/net/wireless/b43/phy_n.c: In function ‘b43_nphy_set_channel’:
drivers/net/wireless/b43/phy_n.c:3848:47: warning: ‘tabent_r2’ may be used uninitialized in this function
drivers/net/wireless/b43/phy_n.c:3849:47: warning: ‘tabent_r3’ may be used uninitialized in this function
drivers/net/wireless/b43/phy_n.c: In function ‘b43_nphy_poll_rssi.clone.14’:
drivers/net/wireless/b43/phy_n.c:2270:6: warning: ‘save_regs_phy$7’ may be used uninitialized in this function
drivers/net/wireless/b43/phy_n.c:2270:6: warning: ‘save_regs_phy$8’ may be used uninitialized in this function
FWIW, the usage of these variables is goverened by checks that match
their initializations. So, I think these are actually false warnings.
Still, I would rather avoid the warning SPAM...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
CC [M] drivers/net/wireless/ath/ath5k/reset.o
drivers/net/wireless/ath/ath5k/reset.c: In function ‘ath5k_hw_init_core_clock’:
drivers/net/wireless/ath/ath5k/reset.c💯51: warning: ‘txf2txs’ may be used uninitialized in this function
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In some circumstances hci_get_auth_req will return a value different
from the current conn->auth_type. In these cases update conn->auth_type
so that when a user confirm request comes it doesn't falsely trigger
auto-accept.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Even for keys that shouldn't be stored some use cases require the
knowledge of a new key having been created so that the conclusion of a
successful pairing can be made. Therefore, always send the mgmt_new_key
event but add a store_hint parameter to it to indicate to user space
whether the key should be stored or not.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
User space shouldn't have any need for the old key type so remove it
from the corresponding Management interface event.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
If a controller generates a changed combination key as its first key the
connection key type will not be correctly set. In these situations make
sure the update the connection key type when such a buggy controller is
detected.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Even if there's no previous key stored the connection might still be
secured with a non-persistent key and in that case the key type in the
hci_conn struct should be checked.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Link keys should only be stored if very specific criteria of the
authentication process are fulfilled. This patch essentially copies the
criteria that user space has so far been using to the kernel side so
that the management interface works properly.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
The mgmt_ev_pin_code_request event should not be sent to user space if
the request gets rejected by the kernel due to the pairable flag not
being set.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
"Pairing not allowed" is 0x18 and not 0x16.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
When accepting a pairing request which fulfills the SSP auto-accept
criteria we need to push the request all the way to the user for
confirmation. This patch adds a new hint to the user_confirm_request
management event so user space can know when to show a numeric
comparison dialog and when to show a simple yes/no confirmation dialog.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
The HCI_CONN_AUTH_PEND flag should be set whenever requesting
authentication so that multiple pending requests can't occur.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Some test systems require an arbitrary delay to the auto-accept test
cases for Secure Simple Pairing in order for the tests to pass.
Previously when this was handled in user space it was worked around by
code modifications and recompilation, but now that it's on the kernel
side it's more convenient if there's a debugfs interface for it.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
This patch adds automated negative and positive (auto-accept) responses
for Secure Simple Pairing user confirmation requests. The responses are
only sent if the HCI_MGMT flag is set in order not to confuse older user
space versions (without management interface support).
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Since timestamp in beacon buffer keeps changing all the time,
the memcmp check in mwifiex_save_curr_bcn() is redundant.
Remove that memcmp check and also avoid freeing and allocation
of buffer if required beacon buffer size is same as previous one.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
1) Initialise HT capabilities in cfg80211 properly.
2) Cfg80211 stack may modify "sband->ht_cap" to disable
40Mhz operation in 2.4GHz band (after recent patch
"cfg80211: module_param to disable HT40 in 2.4GHz band")
Therefore read "sband->ht_cap" instead of an adapter variable
"hw_dot_11n_dev_cap" to get HT capabilities.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
