"mac80211: make ARP filtering depend on CONFIG_INET" introduced this
potential locking leak.
Reported-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In the revert of "iwlwifi: move _agn statistics related structure", I
need to use CONFIG_IWLWIFI_DEBUGFS instead of CONFIG_IWLWIFI_DEBUG in
the private structure definition. Without this patch, it is possible
to get this:
drivers/net/wireless/iwlwifi/iwl-rx.c: In function 'iwl_accumulative_statistics':
drivers/net/wireless/iwlwifi/iwl-rx.c:304: error: 'struct iwl_priv' has no member named 'accum_statistics'
drivers/net/wireless/iwlwifi/iwl-rx.c:305: error: 'struct iwl_priv' has no member named 'delta_statistics'
drivers/net/wireless/iwlwifi/iwl-rx.c:306: error: 'struct iwl_priv' has no member named 'max_delta'
drivers/net/wireless/iwlwifi/iwl-rx.c:321: error: 'struct iwl_priv' has no member named 'accum_statistics'
drivers/net/wireless/iwlwifi/iwl-rx.c:323: error: 'struct iwl_priv' has no member named 'accum_statistics'
drivers/net/wireless/iwlwifi/iwl-rx.c:325: error: 'struct iwl_priv' has no member named 'accum_statistics'
drivers/net/wireless/iwlwifi/iwl-rx.c:327: error: 'struct iwl_priv' has no member named 'accum_statistics'
drivers/net/wireless/iwlwifi/iwl-rx.c:329: error: 'struct iwl_priv' has no member named 'accum_statistics'
drivers/net/wireless/iwlwifi/iwl-rx.c:331: error: 'struct iwl_priv' has no member named 'accum_statistics'
drivers/net/wireless/iwlwifi/iwl-rx.c: In function 'iwl_reply_statistics':
drivers/net/wireless/iwlwifi/iwl-rx.c:484: error: 'struct iwl_priv' has no member named 'accum_statistics'
drivers/net/wireless/iwlwifi/iwl-rx.c:486: error: 'struct iwl_priv' has no member named 'delta_statistics'
drivers/net/wireless/iwlwifi/iwl-rx.c:488: error: 'struct iwl_priv' has no member named 'max_delta'
Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fairly complex code in iwlagn_tx_status_reply_tx handle the status reports for
aggregated packet batches sent by the NIC. This code aims to handle the case
where the NIC retransmits failed packets from a previous batch; the status
information for these packets can sometimes be inserted in the middle of a
batch and are actually not in order by sequence number! (I verified this can
happen with printk's in the function.)
The code in question adaptively identifies the "first" frame of the batch,
taking into account that it may not be the one corresponding to the first agg
status report, and also handles the case when the set of sent packets wraps the
256-character entry buffer. It generates the agg->bitmap field of sent packets
which is later compared to the BlockAck response from the receiver to see which
frames of those sent in this batch were ACKed. A small logic error (wrapping by
0xff==255 instead of 0x100==256) was causing the agg->bitmap to be set
incorrectly.
Fix this wrapping code, and add extensive comments to clarify what is going on.
Signed-off-by: Daniel Halperin <dhalperi@cs.washington.edu>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Compressed BlockAck frames store the ACKs/NACKs in a 64-bit bitmap that starts
at the sequence number of the first frame sent in the aggregated batch. Note
that this is a selective ACKnowledgement following selective retransmission;
e.g., if frames 1,4-5 in a batch are ACKed then the next transmission will
include frames 2-3,6-10 (7 frames). In this latter case, the Compressed
BlockAck will not have all meaningful information in the low order bits -- the
semantically meaningful bits of the BA will be 0x1f3 (where the low-order frame
is seq 2).
The driver code originally just looked at the lower (in this case, 7) bits of
the BlockAck. In this case, the lower 7 bits of 0x1f3 => only 5 packets,
maximum, could ever be ACKed. In reality it should be looking at all of the
bits, filtered by those corresponding to packets that were actually sent. This
flaw meant that the number of correctly ACked packets could be significantly
underreported and might result in asynchronous state between TX and RX sides as
well as driver and uCode.
Fix this and also add a shortcut that doesn't require the code to loop through
all 64 bits of the bitmap but rather stops when no higher packets are ACKed.
In my experiments this fix greatly reduces throughput swing, making throughput
stable and high. It is also likely related to some of the stalls observed in
aggregation mode and maybe some of the buffer underruns observed, e.g.,
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1968http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2098http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2018
Signed-off-by: Daniel Halperin <dhalperi@cs.washington.edu>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
The internal scanning created a problem where
when userspace tries to scan, the scan gets
rejected. Instead of doing that, queue up the
user-initiated scan when doing an internal
scan.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
In "iwlwifi: make scan antenna forcing more generic"
I introduced generic scan RX antenna forcing, which
here I rename to make it more evident. Also add scan
TX antenna forcing, since I will need that as well.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Channel switch host command do not need to allocate huge command buffer
since its size is already included in the iwl_device_cmd structure.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Currently, the driver allocates up to 19 skb pointers
for each TFD, of which we have 256 per queue. This
means that for each TX queue, we allocate 19k/38k
(an order 4 or 5 allocation on 32/64 bit respectively)
just for each queue's "txb" array, which contains only
the SKB pointers.
However, due to the way we use these pointers only the
first one can ever be assigned. When the driver was
initially written, the idea was that it could be
passed multiple SKBs for each TFD and attach all
those to implement gather DMA. However, due to
constraints in the userspace API and lack of TCP/IP
level checksumming in the device, this is in fact not
possible. And even if it were, the SKBs would be
chained, and we wouldn't need to keep pointers to
each anyway.
Change this to only keep track of one SKB per TFD,
and thereby reduce memory consumption to just one
pointer per TFD, which is an order 0 allocation per
transmit queue.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
When we allocate queues, we currently don't
use kzalloc() right now. When we then free
those queues again without having used all
entries, we may end up trying to free random
pointers found in the txb array since it was
never initialised. This fixes it simply by
using kzalloc().
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
The iwl_hw_txq_free_tfd() function can be
called from contexts with IRQs disabled,
so it must not call dev_kfree_skb() but
rather dev_kfree_skb_any() instead.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
When we free a txq that had no txb array allocated,
we still try to access it. Fix that, and also free
all SKBs that may be in the txb array (although it
can just be a single one).
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
This variable is now no longer used, so it
can be removed completely.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
use TIME_UNIT define for beacon internal calculation
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Support channel switch in driver as a separated mac80211 callback
function instead of part of mac_config callback; by moving to this
approach, uCode can have more control of channel switch timing.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Move the ucode beacon formation related helper function from 3945 to
iwlcore, so both _3945 and _agn devices can utilize those functions.
When driver pass the beacon related timing information to uCode in both
spectrum measurement and channel switch commands, the beacon timing
parameter require in uCode beacon format; those helper functions will do
the conversation from uSec to the correct uCode format
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
restrict_refcnt is no longer used, remove it from iwl_priv
structure
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Chain noise calibration data are cleared after the calibration is done
in iwlagn_gain_computation() and iwl4965_gain_computation(). This cause
the debugfs entries for those data useless. To provide valid debugging
info, clear those data right before starting the calibration instead.
Signed-off-by: Shanyu Zhao <shanyu.zhao@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
This can now be much better achieved using
tracing and post-processing of the trace,
rather than doing the processing in place
in the driver, so remove a lot of code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
For probe request frames sent during scan, we
should use the virtual interface's mac address
that the scan was initiated on to avoid issues
when the wrong address is used.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
When we do not have an interface, priv->mac_addr
is all zeroes, so the memcpy() is not useful as
the RXON buffer has been cleared previously.
Therefore, use the interface's address that we
are setting up the RXON for, if available.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
priv->mac_addr is the address of the operating
interface, not the permanent MAC address. They
are usually the same, but the user can override
the operating address, so we shouldn't set the
variable to the permanent one, it is assigned
when an interface is added.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
There's no microcode that actually uses this
variable, and it is reserved for functionality
that the driver doesn't support anyway, so we
shouldn't be setting it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
iwl_connection_init_rx_config() will already
have set up the entire RXON command, so these
assignments are duplicate.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Now they are unnecessary. We can use the generic DMA API with any bus.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Michael Buesch <mb@bu3sch.de>
Cc: Gary Zambrano <zambrano@broadcom.com>
Cc: Stefano Brivio <stefano.brivio@polimi.it>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: John W. Linville <linville@tuxdriver.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Note that dma_sync_single_for_device and dma_sync_single_for_cpu support a
partial sync.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Gary Zambrano <zambrano@broadcom.com>
Acked-by: Michael Buesch <mb@bu3sch.de>
Acked-by: David S. Miller <davem@davemloft.net>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Stefano Brivio <stefano.brivio@polimi.it>
Cc: John W. Linville <linville@tuxdriver.com>
Acked-by: Michael Buesch <mb@bu3sch.de>
Acked-by: David S. Miller <davem@davemloft.net>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stefano Brivio <stefano.brivio@polimi.it>
Cc: John W. Linville <linville@tuxdriver.com>
Acked-by: Michael Buesch <mb@bu3sch.de>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add dma_dev, a pointer to struct device, to struct ssb_device. We pass it
to the generic DMA API with SSB_BUSTYPE_PCI and SSB_BUSTYPE_SSB.
ssb_devices_register() sets up it properly.
This is preparation for replacing the ssb bus specific DMA API (ssb_dma_*)
with the generic DMA API.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Acked-by: Michael Buesch <mb@bu3sch.de>
Cc: Gary Zambrano <zambrano@broadcom.com>
Cc: Stefano Brivio <stefano.brivio@polimi.it>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: John W. Linville <linville@tuxdriver.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This can be cleanly applied to wireless-2.6 and iwlwifi git trees.
=
From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Subject: [PATCH] iwlwifi: use the DMA state API instead of the pci equivalents
This replace the PCI DMA state API (include/linux/pci-dma.h) with the
DMA equivalents since the PCI DMA state API will be obsolete.
No functional change.
For further information about the background:
http://marc.info/?l=linux-netdev&m=127037540020276&w=2
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Acked-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The following commit added an entry in 11na and 11ng rate
table but missed to update its rate count field. This
inconsistency between the rate count and the actual number
of rates in the table will leave out the final rate entry
(mcs15 with half gi in ht40) while forming the valid
rate indices. Not having mcs15+shortGI in ht40 will have
a performance impact (on max throughput) of about 10% both
in nght40 and naht40 mode.
Author: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Date: Thu May 13 18:42:38 2010 -0700
ath9k: Enable Short GI in 20 Mhz for ar9287 and later chips
This patch enables short GI rx at all rates and tx at mcs15
for 20 Mhz channel width also.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
For non-AR9271 chips, the credit size is different
and has to be configured appropriately.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
AR7010 is dual-band. Setup the channels and rateset
for 5GHz band.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The rate information on the target has to be updated
for 2-stream devices, along with the correct chainmask.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The supported MCS rate set has to be setup properly
for 2-stream devices.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add the USB device IDs for AR7010 and handle
firmware loading properly.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch fixes programming the byte swap registers
for chipsets other than AR9271. This is needed for
AR7010.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Do not assign the FW name to driver_info but determine
it dynamically on device probe. This facilitates adding new
firmware.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
While the comment removed in this patch claims board_n800.c uses
"cx3110x", it was never merged to mainline like this. Mainlined board
files for Nokia N8x0 devices are expected "p54spi", and thus don't
work because the modalias is "cx3110x". To my knowledge, these
devices are the only real-world use of p54spi, and will not work
without this change. Tested against my Nokia N810.
Signed-off-by: Luke Dashjr <luke-jr+git@utopios.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
STA_NOTIFY_ADD and STA_NOTIFY_REMOVE have no users anymore,
and station addition/removal are indicated to drivers
using sta_add() and sta_remove(), which can sleep.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
sta_add/sta_remove are the callbacks that can sleep.
Use them instead of sta_notify.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In kernel Bugzilla #15825 (2 users), in a wireless mailing list thread
(http://lists.infradead.org/pipermail/b43-dev/2010-May/000124.html), and on a
netbook owned by John Linville
(http://marc.info/?l=linux-wireless&m=127230751408818&w=4), there are reports
of ssb failing to detect an SPROM at the normal location. After studying the
MMIO trace dump for the Broadcom wl driver, it was determined that the affected
boxes had a relocated SPROM.
This patch fixes all systems that have reported this problem.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@kernel.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If buffer is to be accessed by cpu after dma is over, but
between dma mapping and dma unmapping, we should use
dma_sync_single_for_cpu to sync the buffer between cpu with
device. And dma_sync_single_for_device is used to let
device gain the buffer again.
v2: Felix pointed out dma_sync_single_for_device is needed to return
buffer to device if an unsuccessful status bit check is found.
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Acked-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch reduces the binary size by around 25k (measured on MIPS,
with CONFIG_MAC80211_DEBUG_COUNTERS enabled).
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Because there is a limited number of tx buffers available, once the
queue has been filled to a certain point, ath9k needs to stop accepting
new frames from mac80211. In order to prevent a full WMM queue from
stopping another queue with fewer frames, this patch limits the number
of queued frames to a quarter of the total available tx buffers, minus
some reserved frames to be used for other purposes (e.g. beacons).
Because tx buffers are reserved for frames when they're staged in
software queues as well, the actual queue depth cannot be used for
this, so this patch stores a reference to the tx queue in the ath_buf
struct and keeps track of the total number of pending frames.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch fixes beacon distribution in IBSS mode
by configuring the hardware beacon queue properly.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The MIB counters used by ANI have to be disabled
on the host because the FW doesn't do it on the target side.
Also, flush the receive buffers before initializing
RX on the target.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
