The purpose of this is two-fold:
1) by moving it out of tx_data.flags, we can in
another patch move the radiotap parsing so it
no longer is in the hotpath
2) if a device implements fragmentation but can
optionally skip it, the radiotap request for
not doing fragmentation may be honoured
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Since the only way the interface can be a monitor
interface in ieee80211_xmit() is because the frame
came from ieee80211_monitor_start_xmit() we can
move all the code there.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add documentation about NOACK tx flag usage.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When tx is suspended temporarily and the queue is flushed, do not increase
the retry count or attempt to send out BAR frames. Instead simply retry
the affected subframes normally after the reset.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Do not increment the retry counter if packets to a sleeping station
were not sent because of tx failure, instead of only checking the filter
flag.
Clear the PS filter only after an A-MPDU was reported as filtered,
otherwise the hardware might do some unnecessary extra retransmissions.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Export how many times each of the reset triggers has fired through debugfs.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Mesh paths should only exist over established peer links.
Signed-off-by: Javier Cardona <javier@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If "axq_qnum >= ARRAY_SIZE(sc->tx.txq)", then the call to
ath9k_hw_releasetxqueue() would read beyond the end of the ah->txq[]
array and possibly corrupt memory. Fortunately,
ath9k_hw_setuptxqueue() doesn't return high values of "axq_qnum" and
this code can be removed.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
th5k_hw_setup_tx_queue() returns a valid offset into the ah->ah_txq[]
array. The ah->ah_txq[] and the ah->txqs[] array are the same size.
Both have AR5K_NUM_TX_QUEUES elements. So this error handling code
will never trigger.
Also it's wrong. The call to ath5k_hw_release_tx_queue() with a qnum
of AR5K_NUM_TX_QUEUES or more will just trigger a WARN_ON() and
return. Or if it missed the WARN_ON(), it would just corrupt some
memory and return.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When I introduced in-kernel off-channel TX I
introduced a bug -- the work can't be canceled
again because the code clear the skb pointer.
Fix this by keeping track separately of whether
TX status has already been reported.
Cc: stable@kernel.org [2.6.38+]
Reported-by: Jouni Malinen <j@w1.fi>
Tested-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
My previous patch for init calib cfg disable a set of calibration for both
init and runtime which cause performance issue, Fix it
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is needed so that offloaded scan can do the
right thing. Without this patch, the no_cck flag
contains random values from the kernel heap.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add the brcm80211 tree to drivers/net/wireless, and disable the version that's
in drivers/staging. This version includes the sources currently in staging,
plus any changes that have been sent out for review.
Sources in staging will be deleted in a followup patch.
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
CC [M] drivers/net/wireless/ath/ath6kl/cfg80211.o
drivers/net/wireless/ath/ath6kl/cfg80211.c:1838:2: warning: initialization from incompatible pointer type
Caused by commit e9f935e3e8dc0bddd0df6d148165d95925422502...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The current wl12xx fw (7.3.0.0.77) supports both STA and AP mode, and
we no longer use AP-mode-specific quirks.
WL12XX_QUIRK_END_OF_TRANSACTION is still used for certain HWs, while
WL12XX_QUIRK_LPD_MODE is not used anymore.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
The wl12xx FW supports HW channel switch. If we don't use it,
sometimes the firmware gets confused when recalibrating to the new
channel, causing RX problems. This commit adds HW channel switch
support by implementing the channell_switch op.
Signed-off-by: Shahar Levi <shahar_levi@ti.com>
[added one comment, remove the tx_flush and rephrased the commit message]
Signed-off-by: Luciano Coelho <coelho@ti.com>
The wiphy max_sched_scan_ie_len attribute was not set correctly and
remained as 0, so when IEs were being passed in a scheduled scan, we
were returning -EINVAL.
Fix this by setting the attribute properly.
Signed-off-by: Luciano Coelho <coelho@ti.com>
p2p packets should go out only with OFDM rates.
Configure a new rate policy that will (later) be used
during p2p_find (when the p2p_cli / p2p_go interfaces
are in use, we won't have to use this policy, as
the configured rates should already be OFDM-only).
Additionally, update CONF_TX_MAX_RATE_CLASSES to reflect
the current value from the fw api.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
the AR_SREV register does not seems to indicate whether AR9480 is
pci_express capable or not though the other information like macVersion
etc can be obtained properly. this fix is essential as ASPM won't be intialized
and its related driver functionality ath9k_hw_configpcipowersave won't be
called
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
this patch fixes the assumption of maximum number of GPIO pins present
in AR9287/AR9300. this fix is essential as we might encounter some
functionality issues involved in accessing the status of GPIO pins which
are all incorrectly assumed to be not within the range of max_num_gpio
of AR9300/AR9287 chipsets
Cc: stable@kernel.org
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Recent patches added support for resetting the SD8686 hardware when
commands time out, which seems to happen quite frequently soon after
resuming the system from a Wake-on-WLAN-triggered resume.
At http://dev.laptop.org/ticket/10969 we see the same thing happen
with transmits. In this case, the hardware will fail to respond to
a frame passed for transmission, and libertas (correctly) will block
all further commands and transmissions as the hardware can only
deal with one thing at a time. This results in a lockup while the
system waits indefinitely for the dead card to respond.
Hook up a TX lockup timer to detect this and reset the hardware.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
tx params should be configured per interface.
add ieee80211_vif param to the conf_tx callback,
and change all the drivers that use this callback.
The following spatch was used:
@rule1@
struct ieee80211_ops ops;
identifier conf_tx_op;
@@
ops.conf_tx = conf_tx_op;
@rule2@
identifier rule1.conf_tx_op;
identifier hw, queue, params;
@@
conf_tx_op (
- struct ieee80211_hw *hw,
+ struct ieee80211_hw *hw, struct ieee80211_vif *vif,
u16 queue,
const struct ieee80211_tx_queue_params *params) {...}
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Rename the iwlagn module as iwlwifi in preparation for future
changes. Add an alias to iwlagn for backward compatibility.
Signed-off-by: Don Fry <donald.h.fry@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
this extends the bits for rf kill GPIO selection to [7:2] from [4:2] as
we use GPIO pin 11 as rfkill for AR9480 and also remove few unused
macros
Cc: Wilson Tsao <wtsao@qca.qualcomm.com>
Cc: "Hu, Russell" <rhu@qca.qualcomm.com>
Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In failure case locks are not allocated in mwifiex_register().
So mwifiex_free_lock_list() routine call becomes redundant.
Also we don't need to check return type for mwifiex_init_lock_list()
routine. It never fails.
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>
The commit "mwifiex: remove list traversal.."(fcf2176c87..)
wrongly modifies AMSDU aggregation check. Due to this even though
packet size for iperf traffic is already large, we unnecessarily
try to aggregate them which adds some delay. If Tx iperf is started
on UUT for 30 seconds, UUT keeps sending Tx packets for few more
seconds.
That commit is reverted to fix the problem.
Also, MIN_NUM_AMSDU check is moved inside the loop to optimize the
loop.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This was reported and tested by Martin Walter over at AVM GmbH Berlin.
This also applies to 3.0.1 so sendint to stable.
Cc: s.kirste@avm.de
Cc: d.friedel@avm.de
Cc: Martin Walter <m.walter@avm.de>
Cc: Peter Grabienski <pgrabien@qca.qualcomm.com>
Cc: stable@kernel.org
Tested-by: Martin Walter <m.walter@avm.de>
Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Recently mac80211 was changed to use nullfunc instead of probe
request for connection monitoring for tx ack status reporting
hardwares. Sometimes in congested network, STA got disconnected
quickly after the association. It was observered that the rate
control was not adopted to environment due to minimal transmission.
As the nullfunc are used for monitoring purpose, these frames should
not be sacrificed for rate control updation. So it is better to send
the monitoring null func frames at minimum rate that could help to
retain the connection.
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add a gpio setup function which gives a chance to set up
platform specific configuration such as pin multiplexing,
input/output direction at the runtime or booting time.
Signed-off-by: Sangwook Lee <sangwook.lee@linaro.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Allow injected unicast frames to be sent without having to wait
for an ACK.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fixes compilation errors when compiling for ARM:
ath6kl/debug.c:312: error: implicit declaration of function 'vmalloc'
ath6kl/debug.c:312: warning: assignment makes pointer from integer without a cast
ath6kl/debug.c:342: error: implicit declaration of function 'vfree'
ath6kl/debug.c:696: warning: assignment makes pointer from integer without a cast
ath6kl/debug.c:871: warning: assignment makes pointer from integer without a cast
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
My earlier debug log additions added these warnings when compiling 64 bit
kernels:
ath6kl/init.c:962: warning: format '%d' expects type 'int',
but argument 3 has type 'size_t'
ath6kl/init.c:975: warning: format '%d' expects type 'int',
but argument 3 has type 'size_t'
ath6kl/init.c:988: warning: format '%d' expects type 'int',
but argument 3 has type 'size_t'
ath6kl/init.c:1009: warning: format '%d' expects type 'int',
but argument 3 has type 'size_t'
ath6kl/init.c:1192: warning: format '%d' expects type 'int',
but argument 4 has type 'size_t'
ath6kl/init.c:1236: warning: format '%d' expects type 'int',
but argument 4 has type 'size_t'
ath6kl/init.c:1267: warning: format '%d' expects type 'int',
but argument 4 has type 'size_t'
Reported-by: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
802.11 says:
"Sequence numbers for QoS (+)Null frames may be
set to any value."
However, if we use the normal counters then peers
will get confused with aggregation since there'll
be holes in the sequence number sequence.
To avoid that, neither assign a sequence number
to QoS null frames nor put them on aggregation.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
With the addition of uAPSD and driver buffering
the powersave handling has gotten quite complex.
Add a section to the documentation to explain it
for anyone wanting to implement it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
iwlwifi has a separate EOSP notification from
the device, and to make use of that properly
it needs to be passed to mac80211. To be able
to mix with tx_status_irqsafe and rx_irqsafe
it also needs to be an "_irqsafe" version in
the sense that it goes through the tasklet,
the actual flag clearing would be IRQ-safe
but doing it directly would cause reordering
issues.
This is needed in the case of a P2P GO going
into an absence period without transmitting
any frames that should be driver-released as
in this case there's no other way to inform
mac80211 that the service period ended. Note
that for drivers that don't use the _irqsafe
functions another version of this function
will be required.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
iwlwifi needs to know the number of frames that are
going to be sent to a station while it is asleep so
it can properly handle the uCode blocking of that
station.
Before uAPSD, we got by by telling the device that
a single frame was going to be released whenever we
encountered IEEE80211_TX_CTL_POLL_RESPONSE. With
uAPSD, however, that is no longer possible since
there could be more than a single frame.
To support this model, add a new callback to notify
drivers when frames are going to be released.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
My work and some previous work didn't add
all the flags, add them now and while at it
simplify the code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The flaglock in struct sta_info has long been
something that I wanted to get rid of, this
finally does the conversion to atomic bitops.
The conversion itself is straight-forward in
most places, a few things needed to change a
bit since we can no longer use multiple bits
at the same time.
On x86-64, this is a fairly significant code
size reduction:
text data bss dec hex
427861 23648 1008 452517 6e7a5 before
425383 23648 976 450007 6ddd7 after
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If a PS-poll frame is retried (but was received)
there is no way to detect that since it has no
sequence number. As a consequence, the standard
asks us to not react to PS-poll frames until the
response to one made it out (was ACKed or lost).
Implement this by using the WLAN_STA_SP flags to
also indicate a PS-Poll "service period" and the
IEEE80211_TX_STATUS_EOSP flag for the response
packet to indicate the end of the "SP" as usual.
We could use separate flags, but that will most
likely completely confuse drivers, and while the
standard doesn't exclude simultaneously polling
using uAPSD and PS-Poll, doing that seems quite
problematic.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
For PS-poll, there's a possible race between
us expiring a frame and the station polling
for it -- send it a null frame in that case.
For uAPSD, the standard says that we have to
send a frame in each SP, so send null if we
don't have any other frames.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add uAPSD support to mac80211. This is probably not
possible with all devices, so advertising it with
the cfg80211 flag will be left up to drivers that
want it.
Due to my previous patches it is now a fairly
straight-forward extension. Drivers need to have
accurate TX status reporting for the EOSP frame.
For drivers that buffer themselves, the provided
APIs allow releasing the right number of frames,
but then drivers need to set EOSP and more-data
themselves. This is documented in more detail in
the new code itself.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If there are frames for a station buffered in
the driver, mac80211 announces those in the TIM
IE but there's no way to release them. Add new
API to release such frames and use it when the
station polls for a frame.
Since the API will soon also be used for uAPSD
it is easily extensible.
Note that before this change drivers announcing
driver-buffered frames in the TIM bit actually
will respond to a PS-Poll with a potentially
lower priority frame (if there are any frames
buffered in mac80211), after this patch a driver
that hasn't been changed will no longer respond
at all. This only affects ath9k, which will need
to be fixed to implement the new API.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It doesn't seem likely, but maybe possible, that the
more-data bit needs to be recomputed due to changes
in the queued frames. Clear it for filtered frames
to ensure that we never send it incorrectly. It'll
be set again as necessary when we retransmit this
frame.
The more likely case is maybe where the station woke
up after the filtered frame in which case more-data
should be clear when the frame is transmitted to the
station since it is now awake.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Now that we no longer use the return value, we no
longer need to maintain it either, so remove it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
