| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
Helps with debugging virtual interfaces.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
|
|
|
|
|
|
| |
This patch ensures fair beacon distribution in IBSS mode
by configuring proper CWmin based on slot time.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
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>
|
|\
| |
| |
| |
| |
| |
| |
| | |
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
Conflicts:
drivers/net/wireless/ath/ath5k/base.c
net/mac80211/main.c
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
commit 8c0c709eea5cbab97fb464cd68b06f24acc58ee1
Author: Johannes Berg <johannes@sipsolutions.net>
Date: Wed Nov 25 17:46:15 2009 +0100
mac80211: move cmntr flag out of rx flags
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When uCode error condition detected, driver try to perform either
rf reset or firmware reload in order bring device back to
working condition.
If rf reset is required and scan is in process, there is no need
to issue rf reset since scan already reset the rf.
If firmware reload is required and scan is in process, skip the
reload request. There is a possibility firmware reload during
scan cause problem.
[ 485.804046] WARNING: at net/mac80211/main.c:310 ieee80211_restart_hw+0x28/0x62()
[ 485.804049] Hardware name: Latitude E6400
[ 485.804052] ieee80211_restart_hw called with hardware scan in progress
[ 485.804054] Modules linked in: iwlagn iwlcore bnep sco rfcomm l2cap crc16 bluetooth [last unloaded: iwlcore]
[ 485.804069] Pid: 812, comm: kworker/u:3 Tainted: G W 2.6.36-rc3-wl+ #74
[ 485.804072] Call Trace:
[ 485.804079] [<c103019a>] warn_slowpath_common+0x60/0x75
[ 485.804084] [<c1030213>] warn_slowpath_fmt+0x26/0x2a
[ 485.804089] [<c145da67>] ieee80211_restart_hw+0x28/0x62
[ 485.804102] [<f8b35dc6>] iwl_bg_restart+0x113/0x150 [iwlagn]
[ 485.804108] [<c10415d5>] process_one_work+0x181/0x25c
[ 485.804119] [<f8b35cb3>] ? iwl_bg_restart+0x0/0x150 [iwlagn]
[ 485.804124] [<c104190a>] worker_thread+0xf9/0x1f2
[ 485.804128] [<c1041811>] ? worker_thread+0x0/0x1f2
[ 485.804133] [<c10451b0>] kthread+0x64/0x69
[ 485.804137] [<c104514c>] ? kthread+0x0/0x69
[ 485.804141] [<c1002df6>] kernel_thread_helper+0x6/0x10
[ 485.804145] ---[ end trace 3d4ebdc02d524bbb ]---
[ 485.804148] WG> 1
[ 485.804153] Pid: 812, comm: kworker/u:3 Tainted: G W 2.6.36-rc3-wl+ #74
[ 485.804156] Call Trace:
[ 485.804161] [<c145da9b>] ? ieee80211_restart_hw+0x5c/0x62
[ 485.804172] [<f8b35dcb>] iwl_bg_restart+0x118/0x150 [iwlagn]
[ 485.804177] [<c10415d5>] process_one_work+0x181/0x25c
[ 485.804188] [<f8b35cb3>] ? iwl_bg_restart+0x0/0x150 [iwlagn]
[ 485.804192] [<c104190a>] worker_thread+0xf9/0x1f2
[ 485.804197] [<c1041811>] ? worker_thread+0x0/0x1f2
[ 485.804201] [<c10451b0>] kthread+0x64/0x69
[ 485.804205] [<c104514c>] ? kthread+0x0/0x69
[ 485.804209] [<c1002df6>] kernel_thread_helper+0x6/0x10
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The 5 GHz CTL indexes were not being read for all hardware
devices due to the masking out through the CTL_MODE_M mask
being one bit too short. Without this the calibrated regulatory
maximum values were not being picked up when devices operate
on 5 GHz in HT40 mode. The final output power used for Atheros
devices is the minimum between the calibrated CTL values and
what CRDA provides.
Cc: stable@kernel.org [2.6.27+]
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The EEPROM is compressed on AR9003, upon decompression
the wrong upper limit was being used for the block which
prevented the 5 GHz CTL indexes from being used, which are
stored towards the end of the EEPROM block. This fix allows
the actual intended regulatory limits to be used on AR9003
hardware.
Cc: stable@kernel.org [2.6.36+]
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Otherwise lockdep complains...
https://bugzilla.kernel.org/show_bug.cgi?id=17311
[ INFO: possible circular locking dependency detected ]
2.6.36-rc2-git4 #12
-------------------------------------------------------
kworker/0:3/3630 is trying to acquire lock:
(rtnl_mutex){+.+.+.}, at: [<ffffffff813396c7>] rtnl_lock+0x12/0x14
but task is already holding lock:
(rfkill_global_mutex){+.+.+.}, at: [<ffffffffa014b129>]
rfkill_switch_all+0x24/0x49 [rfkill]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (rfkill_global_mutex){+.+.+.}:
[<ffffffff81079ad7>] lock_acquire+0x120/0x15b
[<ffffffff813ae869>] __mutex_lock_common+0x54/0x52e
[<ffffffff813aede9>] mutex_lock_nested+0x34/0x39
[<ffffffffa014b4ab>] rfkill_register+0x2b/0x29c [rfkill]
[<ffffffffa0185ba0>] wiphy_register+0x1ae/0x270 [cfg80211]
[<ffffffffa0206f01>] ieee80211_register_hw+0x1b4/0x3cf [mac80211]
[<ffffffffa0292e98>] iwl_ucode_callback+0x9e9/0xae3 [iwlagn]
[<ffffffff812d3e9d>] request_firmware_work_func+0x54/0x6f
[<ffffffff81065d15>] kthread+0x8c/0x94
[<ffffffff8100ac24>] kernel_thread_helper+0x4/0x10
-> #1 (cfg80211_mutex){+.+.+.}:
[<ffffffff81079ad7>] lock_acquire+0x120/0x15b
[<ffffffff813ae869>] __mutex_lock_common+0x54/0x52e
[<ffffffff813aede9>] mutex_lock_nested+0x34/0x39
[<ffffffffa018605e>] cfg80211_get_dev_from_ifindex+0x1b/0x7c [cfg80211]
[<ffffffffa0189f36>] cfg80211_wext_giwscan+0x58/0x990 [cfg80211]
[<ffffffff8139a3ce>] ioctl_standard_iw_point+0x1a8/0x272
[<ffffffff8139a529>] ioctl_standard_call+0x91/0xa7
[<ffffffff8139a687>] T.723+0xbd/0x12c
[<ffffffff8139a727>] wext_handle_ioctl+0x31/0x6d
[<ffffffff8133014e>] dev_ioctl+0x63d/0x67a
[<ffffffff8131afd9>] sock_ioctl+0x48/0x21d
[<ffffffff81102abd>] do_vfs_ioctl+0x4ba/0x509
[<ffffffff81102b5d>] sys_ioctl+0x51/0x74
[<ffffffff81009e02>] system_call_fastpath+0x16/0x1b
-> #0 (rtnl_mutex){+.+.+.}:
[<ffffffff810796b0>] __lock_acquire+0xa93/0xd9a
[<ffffffff81079ad7>] lock_acquire+0x120/0x15b
[<ffffffff813ae869>] __mutex_lock_common+0x54/0x52e
[<ffffffff813aede9>] mutex_lock_nested+0x34/0x39
[<ffffffff813396c7>] rtnl_lock+0x12/0x14
[<ffffffffa0185cb5>] cfg80211_rfkill_set_block+0x1a/0x7b [cfg80211]
[<ffffffffa014aed0>] rfkill_set_block+0x80/0xd5 [rfkill]
[<ffffffffa014b07e>] __rfkill_switch_all+0x3f/0x6f [rfkill]
[<ffffffffa014b13d>] rfkill_switch_all+0x38/0x49 [rfkill]
[<ffffffffa014b821>] rfkill_op_handler+0x105/0x136 [rfkill]
[<ffffffff81060708>] process_one_work+0x248/0x403
[<ffffffff81062620>] worker_thread+0x139/0x214
[<ffffffff81065d15>] kthread+0x8c/0x94
[<ffffffff8100ac24>] kernel_thread_helper+0x4/0x10
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Wireless extensions have an unfortunate, undocumented
requirement which requires drivers to always fill
iwp->length when returning a successful status. When
a driver doesn't do this, it leads to a kernel heap
content leak when userspace offers a larger buffer
than would have been necessary.
Arguably, this is a driver bug, as it should, if it
returns 0, fill iwp->length, even if it separately
indicated that the buffer contents was not valid.
However, we can also at least avoid the memory content
leak if the driver doesn't do this by setting the iwp
length to max_tokens, which then reflects how big the
buffer is that the driver may fill, regardless of how
big the userspace buffer is.
To illustrate the point, this patch also fixes a
corresponding cfg80211 bug (since this requirement
isn't documented nor was ever pointed out by anyone
during code review, I don't trust all drivers nor
all cfg80211 handlers to implement it correctly).
Cc: stable@kernel.org [all the way back]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
| |
| |
| |
| | |
Reported-by: Joe Perches <joe@perches.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The new workqueue changes helped me find this bug
that's been lingering since the changes to the work
processing in mac80211 -- the work timer is never
deleted properly. Do that to avoid having it fire
after all data structures have been freed. It can't
be re-armed because all it will do, if running, is
schedule the work, but that gets flushed later and
won't have anything to do since all work items are
gone by now (by way of interface removal).
Cc: stable@kernel.org [2.6.34+]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Michael reported that p54* never really entered power
save mode, even tough it was enabled.
It turned out that upon a power save mode change the
firmware will set a special flag onto the last outgoing
frame tx status (which in this case is almost always the
designated PSM nullfunc frame). This flag confused the
driver; It erroneously reported transmission failures
to the stack, which then generated the next nullfunc.
and so on...
Cc: <stable@kernel.org>
Reported-by: Michael Buesch <mb@bu3sch.de>
Tested-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This avoids a NULL pointer dereference as reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=625889
When the WARN condition is hit in ieee80211_get_tx_rate, it will return
NULL. So, we need to check the return value and avoid dereferencing it
in that case.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cc: stable@kernel.org
Acked-by: Bob Copeland <me@bobcopeland.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The commit 886275ce41a9751117367fb387ed171049eb6148 (param: lock
if_sdio's lbs_helper_name and lbs_fw_name against sysfs changes)
introduced new fields into the if_sdio_card structure. It caused
missalignment of the if_sdio_card.buffer field and failure at driver
load time:
~# modprobe libertas_sdio
[ 62.315124] libertas_sdio: Libertas SDIO driver
[ 62.319976] libertas_sdio: Copyright Pierre Ossman
[ 63.020629] DMA misaligned error with device 48
[ 63.025207] mmci-omap-hs mmci-omap-hs.1: unexpected dma status 800
[ 66.005035] libertas: command 0x0003 timed out
[ 66.009826] libertas: Timeout submitting command 0x0003
[ 66.016296] libertas: PREP_CMD: command 0x0003 failed: -110
Adding explicit alignment attribute for the if_sdio_card.buffer field
fixes this problem.
Signed-off-by: Mike Rapoport <mike@compulab.co.il>
Acked-by: Marek Vasut <marek.vasut@gmail.com>
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
| |
| |
| |
| |
| |
| | |
ath9k can use minstrel_ht instead, so it makes sense to save some space here.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
| |
| |
| |
| |
| |
| | |
It is not used anywhere else and can be made static
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| | |
typo - while looking for specific bits we should do a bitwise-AND instead of logical-AND.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Acked-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
copy the rx_status directly to skb->cb (control buffer) instead of copying
it to a local struct and then copying it again (for each rx packet)
Signed-off-by: Eliad Peller <eliad@wizery.com>
Acked-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
This is a obvious bug, skb_queue_walk does not
work if the iterator gets removed from the queue.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This patch prevents the tasklet code from
interfering while the firmware is down for
an unscheduled maintenance.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
| |
| |
| |
| |
| |
| | |
According to Atheros, chain 1 is not connected.
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>
|
| |
| |
| |
| |
| |
| |
| |
| | |
The eeprom provides a mask for all present rx chains.
Why not use it instead of the generic initval default?
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Add the mac80211 callback function to configure the tx queue properties like
cw_min, cw_max and aifs.
Signed-off-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Add a counter to show how many times a queue got stuck in the debugfs queue
file.
Signed-off-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
Ported from ath9k commit 164ace38536849966ffa377b1b1132993a5a375d.
Signed-off-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
| |
| |
| |
| |
| |
| | |
Clearer separation between queue handling and what we do with completed frames.
Signed-off-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It does not make sense to stop queues for NF calibration. This will not stop
transmissions from the card, if there are queued packets.
If we run out of TX buffers we need to stop all queues, not only one.
Signed-off-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
| |
| |
| |
| |
| |
| | |
Take txq lock in debug file and fix reporting of used buffers.
Signed-off-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixing up a merge issue / concurrent development:
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This patch is loosely based on an ath9k patch called:
"ath9k_hw: sync initvals for ar9001 and ar9002 with Atheros"
It includes the following changes/fixes:
- AGC setting improvements
- timing changes for improved performance
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add MMC3 support on ZOOM, which has the wl1271 device hardwired to.
The wl1271 is a 4-wire, 1.8V, embedded SDIO WLAN device with an
external IRQ line, and power-controlled by a GPIO-based fixed regulator.
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add a fixed regulator vmmc device to enable power control
of the wl1271 wlan device.
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The wl1271 device is using a reference clock that may change
between board to board.
Make the ref_clock parameter configurable by board settings
instead of having a hard coded value in the sources.
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Remove the hard coded irq information, and instead take
the irq information from the board's platform data.
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|