David Miller complained about the driver's excessive use
of variables in __packed structs. While I did not fully
agree with his sole "performance" argument on all accounts.
I do see some room for improvement in hot-paths on
architectures without an efficient access to unaligned
elements.
This first patch (dare I say?) optimizes an important tx
hot-path in the driver: carl9170_tx_prepare.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch removes some cruft, which survived
the RFC review phase.
Originally, carl9170_tx_ampdu_queue erroneously
dropped a lot of frames. As a result the ampdu
scheduler bogged down quite frequently and the
affected BA session timed out.
However this bug has been fixed and the WA and
its debugfs counter is no longer useful.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
802.11n-2009 demands in 11.2.1: "
When a STA enters normal (non-APSD) PS mode, any downlink
Block ACK agreement without an associated schedule is
suspended for the duration of this PS mode."
The operative word is "suspended" and not terminated.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211: fix offchannel assumption upon association
Association is dealt with as an atomic offchannel operation,
we do this because we don't know we are associated until we
get the associatin response from the AP. When we do get the
associatin response though we were never clearing the offchannel
state. This has a few implications, we told drivers we were
still offchannel, and the first configured TX power for the
channel does not take into account any power constraints.
For ath9k this meant ANI calibration would not start upon
association, and we'd have to wait until the first bgscan
to be triggered. There may be other issues this resolves
but I'm too lazy to comb the code to check.
Cc: stable@kernel.org Cc: Amod Bodas <amod.bodas@atheros.com> Cc: Vasanth Thiagarajan <vasanth.thiagarajan@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
John W. Linville [Mon, 27 Sep 2010 18:00:51 +0000 (14:00 -0400)]
wl12xx: fix separate-object-folder builds
Make this go away (happens when building with a separate object
directory):
Assembler messages:
Fatal error: can't create drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.o: No such file or directory
drivers/net/wireless/wl12xx/wl12xx_platform_data.c: In function 'wl12xx_get_platform_data':
drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: error: cannot open drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.gcno
drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: confused by earlier errors, bailing out
Signed-off-by: John W. Linville <linville@tuxdriver.com> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
moved the CMNTR flag into the skb RX flags for
some aggregation cleanups, but this was wrong
since the optimisation this flag tried to make
requires that it is kept across the processing
of multiple interfaces -- which isn't true for
flags in the skb. The patch not only broke the
optimisation, it also introduced a bug: under
some (common!) circumstances the flag will be
set on an already freed skb!
However, investigating this in more detail, I
found that most of the flags that we set should
be per packet, _except_ for this one, due to
a-MPDU processing. Additionally, the flags used
for processing (currently just this one) need
to be reset before processing a new packet.
Since we haven't actually seen bugs reported as
a result of the wrong flags handling (which is
not too surprising -- the only real bug case I
can come up with is an a-MSDU contained in an
a-MPDU), I'll make a different fix for rc.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Fri, 24 Sep 2010 09:21:08 +0000 (11:21 +0200)]
mac80211: fix release_reorder_timeout in scan
Even if the reorder timeout timer fires while
scanning, the frames weren't received during
scanning and therefore shouldn't be dropped.
To implement this, changes to the passive scan
RX handler simplify understanding it, because
it currently checks HW_SCANNING independently
of a packet's in-scan receive status (which
doesn't make a big difference, since scan_rx()
will only pick up probe responses and beacons,
which can't be aggregated.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Fri, 24 Sep 2010 09:21:06 +0000 (11:21 +0200)]
mac80211: consolidate packet processing
There are now four instances of vaguely the same
code that does packet preparation, checking for
MMIC errors and reporting them, and then invoking
packet processing. Consolidate all of these.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
The first argument to prepare_for_handlers is always
the sdata that can just be stored in rx data directly
(and even already is, in two of four code paths.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Teemu Paasikivi [Fri, 24 Sep 2010 04:23:55 +0000 (07:23 +0300)]
nl80211: Fix exit from nl80211_set_power_save
If interface does not existk, when nl80211_set_power_save is called, (eg.
module has been unloaded) it has been causing kernel panic. Added new
goto target to avoid crash if get_rdev_dev_by_info_ifindex does not
return dev and rdev pointers.
Signed-off-by: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Ben Greear [Thu, 23 Sep 2010 17:22:24 +0000 (10:22 -0700)]
mac80211: Support receiving data frames on multiple vifs.
When using multiple STA interfaces on the same radio, some
data packets need to be received on all interfaces
(broadcast, for instance).
Make the STA loop look similar to the mgt-data loop.
Also, add logic to check RX_FLAG_MMIC_ERROR for last
interface in mgt-data loop.
Signed-off-by: Ben Greear <greearb@candelatech.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Ben Greear [Thu, 23 Sep 2010 16:44:36 +0000 (09:44 -0700)]
mac80211/ath9k: Support AMPDU with multiple VIFs.
The old ieee80211_find_sta_by_hw method didn't properly
find VIFS when there was more than one per AP. This caused
AMPDU logic in ath9k to get the wrong VIF when trying to
account for transmitted SKBs.
This patch changes ieee80211_find_sta_by_hw to take a
localaddr argument to distinguish between VIFs with the
same AP but different local addresses. The method name
is changed to ieee80211_find_sta_by_ifaddr.
Signed-off-by: Ben Greear <greearb@candelatech.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Ben Greear [Thu, 23 Sep 2010 03:29:01 +0000 (20:29 -0700)]
mac80211: Support multiple VIFS per AP in debugfs.
Create 'stations' sub-directory under each netdev:[vif-name]
directory to hold all stations for that network device.
Signed-off-by: Ben Greear <greearb@candelatech.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Felix Fietkau [Wed, 22 Sep 2010 10:34:52 +0000 (12:34 +0200)]
ath9k_hw: simplify revision checks for AR9280
Since AR9280 v1.0 was never sold (and the initvals removed), v1.0 specific
revision checks can be removed and the 'v2.0 or later' check can be
simplified to a check for AR9280 or later.
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Due to miscalculation of nvs_len, excessive data was sent to the
firmware.
Fix this by first setting nvs_ptr to point to the first NVS table,
and computing the total size of all NVS tables accordingly.
Signed-off-by: Ido Yariv <ido@wizery.com> Tested-By: Tuomas Katila <ext-tuomas.2.katila@nokia.com> Acked-by: Luciano Coelho <luciano.coelho@nokia.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Paprd needs to be done only on active chains(not for all the chains
that hw can support). The paprd training frames which are sent
for inactive chains would be hanging on the hw queue without
getting transmitted and would make the connection so unstable.
This issue happens only with the hw which supports paprd cal(ar9003).
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> Cc: stable@kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch fixes stale mac80211_tx_control_flags for
filtered / retried frames.
Because ieee80211_handle_filtered_frame feeds skbs back
into the tx path, they have to be stripped of some tx
flags so they won't confuse the stack, driver or device.
Cc: <stable@kernel.org> Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Dan Carpenter [Sat, 11 Sep 2010 23:48:33 +0000 (01:48 +0200)]
airo: remove "basic_rate" module option
The "basic_rate" module option is not implemented correctly. If the
rate was set to zero it was supposed to set it to "basic_rate | 0x80".
Unfortunately the check to see if what zero was wrong and it checked
"!ai->config.rates" (which is always false) instead of
"!ai->config.rates[i]".
This option was just used for development and it wasn't documented
anywhere. Instead of fixing it, we can just remove it.
Reported-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Jouni Malinen [Sat, 28 Aug 2010 16:37:51 +0000 (19:37 +0300)]
mac80211: Add DS Parameter Set into Probe Request on 2.4 GHz
IEEE Std 802.11k-2008 added DS Parameter Set information element into
Probe Request frames as an optional information on 2.4 GHz band (and
mandatory, if radio measurements are enabled). This allows APs to
filter out Probe Request frames that may be received from neighboring
overlapping channels and by doing so, reduce the number of unnecessary
frames in the air. Make mac80211 add this IE into Probe Request frames
whenever the channel is known (i.e., whenever hwscan is not used).
Signed-off-by: Jouni Malinen <j@w1.fi> Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Jouni Malinen [Sat, 28 Aug 2010 16:36:10 +0000 (19:36 +0300)]
mac80211: Filter ProbeReq SuppRates based on TX rate mask
If the TX rate set has been masked, the removed rates can also be
removed from the Supported Rates and Extended Supported Rates IEs in
Probe Request frames.
Signed-off-by: Jouni Malinen <j@w1.fi> Signed-off-by: John W. Linville <linville@tuxdriver.com>
moved the CMTR flag into the skb's status, and
in doing so introduced a use-after-free -- when
the skb has been handed to cooked monitors the
status setting will touch now invalid memory.
Additionally, moving it there has effectively
discarded the optimisation -- since the bit is
only ever set on freed SKBs, and those were a
copy, it could never be checked.
For the current release, fixing this properly
is a bit too involved, so let's just remove the
problematic code and leave userspace with one
copy of each frame for each virtual interface.
Cc: stable@kernel.org [2.6.33+] Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Felix Fietkau [Mon, 20 Sep 2010 11:45:38 +0000 (13:45 +0200)]
ath9k: clean up / fix aggregation session flush
The tid aggregation cleanup is a bit fragile, as it discards failed
subframes in some places, and retransmits them in others. This could
block the cleanup of an existing aggregation session, if a retransmission
for a tid is issued, yet the tid is never scheduled again because of
the cleanup state.
Fix this by getting rid of as many subframes as possible, as early
as possible, and immediately transmitting pending subframes as regular
HT frames instead of waiting for the cleanup to complete.
Drop all pending subframes while keeping track of the Block ACK window
during aggregate tx completion to prevent sending out stale subframes,
which could confuse the receiver side.
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Cc: stable@kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
Felix Fietkau [Mon, 20 Sep 2010 17:35:28 +0000 (19:35 +0200)]
ath9k: fix an aggregation start related race condition
A new aggregation session start can be issued by mac80211, even when the
cleanup of the previous session has not completed yet. Since the data structure
for the session is not recreated, this could corrupt the block ack window
and lock up the aggregation session. Fix this by delaying the new session
until the old one has been cleaned up.
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Cc: stable@kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
Felix Fietkau [Mon, 20 Sep 2010 11:45:36 +0000 (13:45 +0200)]
ath9k: clean up block ack window handling
There's no reason to keep pointers to pending tx buffers around, if they're
only used to keep track of which frames are still pending. Use a bitfield
instead.
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
carl9170: reinit phy after HT settings have changed
The driver has a set of different initvals for 20 MHz
vs dynamic HT2040 operation. Because we can't change
some of the registers "in-flight", the driver needs to
perform a warm reset.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Don't mark the device as completely dead just yet.
If all goes to plan and carl9170_reboot succeeds
then we can skip the expensive userspace-driven
reinitialization anyway.
And if it doesn't and carl9170_reboot fails,
then carl9170_usb_cancel_urbs will do the
necessary steps.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Ever since carl9170 gained support to read the noisefloor,
the reported noisefloor level was pretty poor.
Initially I assumed that something was wrong in the PHY
setup and it would be impossible to fix without any
guidances. But this was not the case. In fact the nf
readings were correct and the thing that was broken
was the "simple" sign extension code!
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bruno Randolf [Fri, 17 Sep 2010 02:37:12 +0000 (11:37 +0900)]
ath5k: Simplify cw_min/max and AIFS configuration
Get rid of overly complicated cw_min/max and AIFS configuration:
* Validate values in ath5k_hw_set_tx_queueprops(), so we can use them directly
without further checks or computation in ath5k_hw_reset_tx_queue().
* Simplifiy by using AR5K_TUNE_AIFS|CWMIN|CWMAX variables directly since we
don't support XR or B channels. That way we can also remove
AR5K_TXQ_USEDEFAULT and the confusing logic around it.
* Update data types: AIFS is u8, CW's are u16.
* Remove now unneeded variables in ath5k_hw.
Signed-off-by: Bruno Randolf <br1@einfach.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bruno Randolf [Fri, 17 Sep 2010 02:37:07 +0000 (11:37 +0900)]
ath5k: Keep last descriptor in queue
If we return a TX descriptor to the pool of available descriptors, while a
queues TXDP still points to it we could potentially run into all sorts of
troube.
It has been suggested that there is hardware which can set the descriptors
done bit before it reads ds_link and moves on to the next descriptor. While the
documentation says this is not true for newer chipsets (the descriptor contents
are copied to some internal memory), we don't know about older hardware.
To be safe, we always keep the last descriptor in the queue, and avoid dangling
TXDP pointers. Unfortunately this does not fully resolve the problem - queues
still get stuck!
This is similar to what ath9k does.
Signed-off-by: Bruno Randolf <br1@einfach.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bruno Randolf [Fri, 17 Sep 2010 02:36:56 +0000 (11:36 +0900)]
ath5k: Add watchdog for stuck TX queues
Since we do not know any better solution to the problem that TX queues can get
stuck, this adds a timer-based watchdog, which will check for stuck queues and
reset the hardware if necessary.
Bruno Randolf [Fri, 17 Sep 2010 02:36:35 +0000 (11:36 +0900)]
ath5k: Use four hardware queues
Prepare ath5k for WME by using four hardware queues.
The way we set up our queues matches the mac80211 queue priority 1:1, so we
don't have to do any mapping for queue numbers.
Every queue uses 50 of the total 200 available transmit buffers, so the DMA
memory usage does not increase with this patch, but it might be good to
fine-tune the number of buffers per queue later (depending on the CPU speed and
load, and the speed of the medium access, it might not be big enough).
Signed-off-by: Bruno Randolf <br1@einfach.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bob Copeland [Fri, 17 Sep 2010 03:45:07 +0000 (12:45 +0900)]
ath5k: reorder base.c to remove fwd decls
This change reorganizes the main ath5k file in order to re-group
related functions and remove most of the forward declarations
(from 61 down to 3). This is, unfortunately, a lot of churn, but
there should be no functional changes.
Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Bruno Randolf <br1@einfach.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Remove unneeded ath_crypt_caps flags, as per "ath9k_hw: remove useless hw
capability flags" (364734fafbba0c3133e482db78149b9a823ae7a5), but set the
AESCCM flag for ath9k. common ath code still needs a flag for this because
there is ath5k hardware which can't do AES in hardware.
Signed-off-by: Bruno Randolf <br1@einfach.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add a simple mechanism to pass platform data to the
SDIO instances of wl12xx.
This way there is no confusion over who owns the 'embedded data',
typechecking is preserved, and no possibility for the wrong driver to
pick up the data.
Originally proposed by Russell King.
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Make it possible for the set power method to indicate a
success/failure return value. This is needed to support
more complex power on/off operations such as SDIO
power manipulations.
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Acked-by: Luciano Coelho <luciano.coelho@nokia.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
When a driver doesn't fill the entire buffer, old
heap contents may remain, and if it also doesn't
update the length properly, this old heap content
will be copied back to userspace.
It is very unlikely that this happens in any of
the drivers using private ioctls since it would
show up as junk being reported by iwpriv, but it
seems better to be safe here, so use kzalloc.
Reported-by: Jeff Mahoney <jeffm@suse.com> Cc: stable@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Jay Sternberg [Wed, 8 Sep 2010 16:42:35 +0000 (09:42 -0700)]
iwlwifi: corrections to debug output of ucode statistics
remove duplicate header and clean up format so it is defined once
making changes consolicated ensuring consistancy of output.
no function change to date displayed.
Signed-off-by: Jay Sternberg <jay.e.sternberg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Wey-Yi Guy [Sun, 5 Sep 2010 17:49:42 +0000 (10:49 -0700)]
iwlagn: keep track of failure tx status
Tx command response sent to host by uCode after completed
the transmission attempt. The status parameter indicates
whether the transmission was successful, or else why if failed.
Here we keep the counters to help understand the different failure
cases.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
The patch titled "ath9k: Add new file init.c" shuffled some code
around but in dong so for some reason also removed the revision
check for disablign power save. Add this revision check again
so we can get power save re-enabled again by default on cards
newer than AR5416 and AR5418.
This patch has fixes for stable kernels [2.6.34+].
Cc: stable@kernel.org Cc: Paul Stewart <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
This helper only clears the SC_OP_WAIT_FOR_{BEACON,CAB} flags.
Remove it and clear these flags directly in the approptiate
places instead.
Changes-licensed-under: ISC Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
introduced a regression which forgot to lift the beacon flag
after we received all broadcast and multicast data. This meant
we never went to sleep consuming about ~650mW on idle. This pretty
much broke power save completely.
This patch has fixes for stable kernels [2.6.32+].
Cc: stable@kernel.org Cc: Paul Stewart <pstew@google.com> Cc: Sameer Nanda <snanda@google.com> Cc: Gabor Juhos <juhosg@openwrt.org> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Some buggy APs do not respond to unicast probe requests
or send unicast probe requests very delayed so in the
worst case we should try to send broadcast probe requests,
otherwise we can get disconnected from these APs.
Even if drivers do not have filters to disregard probe
responses from foreign APs mac80211 will only process
probe responses from our associated AP for re-arming
connection monitoring.
We need to do this since the beacon monitor does not
push back the connection monitor by design so even if we
are getting beacons from these type of APs our connection
monitor currently relies heavily on the way the probe
requests are received on the AP. An example of an AP
affected by this is the Nexus One, but this has also been
observed with random APs.
We can probably optimize this later by using null funcs
instead of probe requests.
This patch has fixes for stable kernels [2.6.35+].
Cc: stable@kernel.org Cc: Paul Stewart <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211: disable beacon monitor while going offchannel
The beacon monitor should be disabled when going off channel
to prevent spurious warnings and triggering connection
deterioration work such as sending probe requests. Re-enable
the beacon monitor once we come back to the home channel.
This patch has fixes for stable kernels [2.6.34+].
Cc: stable@kernel.org Cc: Paul Stewart <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211: make the beacon monitor available externally
This will be used by other components next. The beacon
monitor was added as of 2.6.34 so these fixes are applicable
only to kernels >= 2.6.34.
Cc: stable@kernel.org Cc: Paul Stewart <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211: reset connection idle when going offchannel
When we go offchannel mac80211 currently leaves alive the
connection idle monitor. This should be instead postponed
until we come back to our home channel, otherwise by the
time we get back to the home channel we could be triggering
unecesary probe requests. For APs that do not respond to
unicast probe requests (Nexus One is a simple example) this
means we essentially get disconnected after the probes
fails.
This patch has stable fixes for kernels [2.6.35+]
Cc: stable@kernel.org Cc: Paul Stewart <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211: reset probe send counter upon connection timer reset
Upon beacon loss we send probe requests after 30 seconds of idle
time and we wait for each probe response 1/2 second. We send a
total of 3 probe requests before giving up on the AP. In the case
that we reset the connection idle monitor we should reset the probe
requests count to 0. Right now this won't help in any way but
the next patch will.
This patch has fixes for stable kernel [2.6.35+].
Cc: stable@kernel.org Cc: Paul Stewart <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211: add helper for reseting the connection monitor
This will be used in another place later. The connection
monitor was added as of 2.6.35 so these fixes will be
applicable to >= 2.6.35.
Cc: stable@kernel.org Cc: Paul Stewart <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k: fix enabling ANI / tx monitor after bg scan
ath9k's entire logic with SC_OP_SCANNING is incorrect due to the
way mac80211 currently implements the scan complete callback and
we handle it in ath9k. This patch removes the flag completely in
preference for the SC_OP_OFFCHANNEL which is really what we wanted.
The scanning flag was used to ensure we reset ANI to the old values
when we go back to the home channel, but if we are offchannel we
use some defaults. The flag was also used to re-enable the TX monitor.
Without this patch we simply never re-enabled ANI and the TX monitor
after going offchannel. This means that after one background
scan we are prone to noise issues and if we had a TX hang we would
not recover. To get this to work properly we must enable ANI after
we have configured the beacon timers, otherwise hardware acts really
oddly.
This patch has stable fixes which apply down to [2.6.36+], there
*may* be a to fix this on older kernels but requires a bit of
work since this patch relies on the new mac80211 flag
IEEE80211_CONF_OFFCHANNEL which was introduced as of 2.6.36.
Cc: stable@kernel.org Cc: Paul Stewart <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
When we return to the home channel we were never reseting our beacon
timers, this was casued by the fact that the scanning flag was still
on even after we returned to our home channel. There are also other
reasons why we would get a reset and if we are not off channel
we always need to resynch our beacon timers, because a reset will
clear them.
This bug is a regression introduced on 2.6.36. The order of the
changes are as follows:
So 5ee08656 would have worked if a0daa0e7 was not committed but
it was so this means 5ee08656 was broken since it assumed that
when we were in the channel change routine the scan flag would
be lifted. As it turns out the scan flag will be set when we
are already on the home channel.
These issues will need to be considered for our solution on
reshifting the scan complete callback location on mac80211 on
current development kernel work.
This patch has stable fixes which apply down to [2.6.36+]
Cc: stable@kernel.org Cc: Paul Stewart <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k has a race on putting the chip into network sleep and
having registers read from hardware. The race occurs because
although ath9k_ps_restore() locks its own callers it makes use
of some variables which get altered in the driver at different
code paths. The variables are the ps_enabled and ps_flags.
This is easily reprodicible in large network environments when
roaming with the wpa_supplicant simple bgscan. You'd get some
0xdeadbeef read out on certain registers such as:
ath: timeout (100000 us) on reg 0x806c: 0xdeadbeef & 0x01f00000 != 0x00000000
ath: RX failed to go idle in 10 ms RXSM=0xdeadbeef
The fix is to protect the ath9k_config(hw, IEEE80211_CONF_CHANGE_PS)
calls with a spin_lock_irqsave() which will disable contendors for
these variables from interrupt context, timers, re-entry from mac80211
on the same callback, and most importantly from ath9k_ps_restore()
which is the only call which will put the device into network sleep.
There are quite a few threads and bug reports on these a few of them are:
Cc: stable@kernel.org Cc: Paul Stewart <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
To optimize register read/write operations, the HTC firmwares were patched
to change EP3 and EP4 pipe types from Interrupt to Bulk. So register writes
are submitted as bulk urbs, but register reads are not. Also changing the
register read endpoint pipe as bulk type when URBs are filled improves the
register reads considerably which results in reduced scan time and CPU
utilization.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Thu, 16 Sep 2010 12:58:23 +0000 (14:58 +0200)]
mac80211: add p2p device type support
When a driver advertises p2p device support,
mac80211 will handle it, but internally it will
rewrite the interface type to STA/AP rather than
P2P-STA/GO since otherwise a lot of paths need
to be touched that are otherwise identical. A
p2p boolean tells drivers whether or not a given
interface will be used for p2p or not.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k_hw: remove warning in ath9k_hw_def_get_num_ant_config
This patch fixes following warning
drivers/net/wireless/ath/ath9k/eeprom_def.c: In function 'ath9k_hw_def_get_num_ant_config'
drivers/net/wireless/ath/ath9k/eeprom_def.c:1425:47: warning: comparison
between 'enum ath9k_hal_freq_band' and 'enum ieee80211_band'
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
John W. Linville [Wed, 15 Sep 2010 19:26:13 +0000 (15:26 -0400)]
ath9k: make ath_ant_div_conf_fast_divbias static
CHECK drivers/net/wireless/ath/ath9k/recv.c
drivers/net/wireless/ath/ath9k/recv.c:1341:6: warning: symbol 'ath_ant_div_conf_fast_divbias' was not declared. Should it be static?
Signed-off-by: John W. Linville <linville@tuxdriver.com>
John W. Linville [Wed, 15 Sep 2010 19:16:22 +0000 (15:16 -0400)]
iwlwifi: fix sparse warning about wrong enum for band parameter
drivers/net/wireless/iwlwifi/iwl-scan.c:386:27: warning: mixing different enum types
drivers/net/wireless/iwlwifi/iwl-scan.c:386:27: int enum nl80211_band versus
drivers/net/wireless/iwlwifi/iwl-scan.c:386:27: int enum ieee80211_band
drivers/net/wireless/iwlwifi/iwl-scan.c:435:57: warning: mixing different enum types
drivers/net/wireless/iwlwifi/iwl-scan.c:435:57: int enum ieee80211_band versus
drivers/net/wireless/iwlwifi/iwl-scan.c:435:57: int enum nl80211_band
drivers/net/wireless/iwlwifi/iwl-scan.c:474:53: warning: mixing different enum types
drivers/net/wireless/iwlwifi/iwl-scan.c:474:53: int enum ieee80211_band versus
drivers/net/wireless/iwlwifi/iwl-scan.c:474:53: int enum nl80211_band
drivers/net/wireless/iwlwifi/iwl-scan.c:588:72: warning: mixing different enum types
drivers/net/wireless/iwlwifi/iwl-scan.c:588:72: int enum ieee80211_band versus
drivers/net/wireless/iwlwifi/iwl-scan.c:588:72: int enum nl80211_band
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Wed, 15 Sep 2010 13:13:13 +0000 (15:13 +0200)]
mac80211: set running state earlier
When an interface is brought up, the recent changes
to allow changing type-while-up only set the running
bit after everything was done. This broke a number
of things, including idle calculation for monitor
interfaces, and it also broke WDS station insertion
(although nobody noticed yet).
Thus, change the code to set the running bit earlier,
but keep it after the driver's add_interface was
called because otherwise drivers may iterate over
interfaces they haven't fully set up yet.
Reported-by: Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Wed, 15 Sep 2010 11:28:15 +0000 (13:28 +0200)]
cfg80211/mac80211: use lockdep_assert_held
Instead of using a WARN_ON(!mutex_is_locked())
use lockdep_assert_held() which compiles away
completely when lockdep isn't enabled, and
also is a more accurate assertion since it
checks that the current thread is holding the
mutex.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Tue, 14 Sep 2010 20:06:53 +0000 (22:06 +0200)]
mac80211: use correct station flags lock
This code is modifying the station flags, and
as such should hold the flags lock so it can
do so atomically vs. other flags modifications
and readers. This issue was introduced when
this code was added in eccb8e8f, as it used
the wrong lock (thus not fixing the race that
was previously documented in a comment.)
Cc: stable@kernel.org [2.6.31+] Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
git://bbs.cooldavid.org / net-next-2.6.git / log