Atheros top level menu needs a "depends WLAN_80211" to properly indent
within menuconfig and xconfig interfaces.
This is purely a visual issue but it effects all subsequent drivers.
The issue is the top level menu does not include a dependency on
WLAN_80211 so within the tree structure, Atheros is at the same level as
WLAN_80211 but when WLAN_80211 collapsed, the menu disappears along with
all subsequent drives, so it is really a subordinate.
Signed-off-by: Jay Sternberg <jay.e.sternberg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When we reclaim the tx desc, we always assume that the
last desc is a holding desc, which is not true, and skip it.
If the tx queue is drained during channel change, internal
reset and etc, the last descriptor may not be the holding
descriptor and we fail to reclaim them. This results in the
following two issues.
1. Tx stuck - We drop all the frames coming from upper layer
due to shortage in tx desc.
2. Crash - If we fail to reclaim a tx descriptor, we miss to
update the tx BA window with the seq number of the frame
associated to that desc, which, at some point, result in
the following crash due to an assert failure in ath_tx_addto_baw().
This patch fixes these two issues.
kernel BUG at ../drivers/net/wireless/ath/ath9k/xmit.c:180!
[155064.304164] invalid opcode: 0000 [#1] SMP
Call Trace:
[<fbc6d83b>] ? ath9k_tx+0xeb/0x160 [ath9k]
[<fbbc9591>] ipv6? __ieee80211_tx+0x41/0x120 [mac80211]
[<fbbcb5ae>] ? aes_i586ieee80211_master_start_xmit+0x28e/0x560 [mac80211]
[<c037e501>] aes_generic? _spin_lock_irqsave+0x31/0x40
[<c02f347b>] ? dev_hard_start_xmit+0x16b/0x1c0
[<c03058b5>] ? __qdisc_run+0x1b5/0x200
[<fbbcda5a>] ? af_packetieee80211_select_queue+0xa/0x100 [mac80211]
[<c02f53b7>] ? i915dev_queue_xmit+0x2e7/0x3f0
[<fbbc9b49>] ? ieee80211_subif_start_xmit+0x369/0x7a0 [mac80211]
[<c031bc35>] ? ip_output+0x55/0xb0
[<c02e0188>] ? show_memcpy_count+0x18/0x60
[<c02eb186>] ? __kfree_skb+0x36/0x90
[<c02f2202>] ? binfmt_miscdev_queue_xmit_nit+0xd2/0x110
[<c02f347b>] ? dev_hard_start_xmit+0x16b/0x1c0
[<c03058b5>] ? __qdisc_run+0x1b5/0x200
[<c033bca7>] ? scoarp_create+0x57/0x2a0
[<c02f53b7>] ? bridgedev_queue_xmit+0x2e7/0x3f0
[<c03034a0>] ? eth_header+0x0/0xc0
[<c033b95f>] stp? arp_xmit+0x5f/0x70
[<c033bf4f>] ? arp_send+0x5f/0x70
[<c033c8f5>] bnep? arp_solicit+0x105/0x210
[<c02fa5aa>] ? neigh_timer_handler+0x19a/0x390
[<c013bf88>] ? run_timer_softirq+0x138/0x210
[<c02fa410>] ? ppdevneigh_timer_handler+0x0/0x390
[<c02fa410>] ? neigh_timer_handler+0x0/0x390
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6: (43 commits)
via-velocity: Fix velocity driver unmapping incorrect size.
mlx4_en: Remove redundant refill code on RX
mlx4_en: Removed redundant check on lso header size
mlx4_en: Cancel port_up check in transmit function
mlx4_en: using stop/start_all_queues
mlx4_en: Removed redundant skb->len check
mlx4_en: Counting all the dropped packets on the TX side
usbnet cdc_subset: fix issues talking to PXA gadgets
Net: qla3xxx, remove sleeping in atomic
ipv4: fix NULL pointer + success return in route lookup path
isdn: clean up documentation index
cfg80211: validate station settings
cfg80211: allow setting station parameters in mesh
cfg80211: allow adding/deleting stations on mesh
ath5k: fix beacon_int handling
MAINTAINERS: Fix Atheros pattern paths
ath9k: restore PS mode, before we put the chip into FULL SLEEP state.
ath9k: wait for beacon frame along with CAB
acer-wmi: fix rfkill conversion
ath5k: avoid PCI FATAL interrupts by restoring RETRY_TIMEOUT disabling
...
73ca520336
(ath5k: remove conf->beacon_int usage)
removed bintval setting from ath5k_config. We need to init the
interval earlier and don't touch it in add_interface anymore.
Otherwise it will be set only once by upper layer through
bss_info_changed but not on second and further hostap executions.
We ended up having bintval 1000 which rendered the AP useless on
many clients.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Cc: Nick Kossifidis <mickflemm@gmail.com>
Cc: Luis R. Rodriguez <lrodriguez@atheros.com>
Cc: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We want to put the chip into FULL SLEEP state, when we are disabling the
radio, but the the current code always change it to AWAKE/NETWORK SLEEP.
Changes-licensed-under: ISC
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This reverts 'ath5k: remove dummy PCI "retry timeout" fix' on the
same theory as in 'ath9k: Fix PCI FATAL interrupts by restoring
RETRY_TIMEOUT disabling'.
Reported-by: Bob Copeland <me@bobcopeland.com>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
An earlier commit, 'ath9k: remove dummy PCI "retry timeout" fix', removed
code that was documented to disable RETRY_TIMEOUT register (PCI reg
0x41) since it was claimed to be a no-op. However, it turns out that
there are some combinations of hosts and ath9k-supported cards for
which this is not a no-op (reg 0x41 has value 0x80, not 0) and this
code (or something similar) is needed. In such cases, the driver may
be next to unusable due to very frequent PCI FATAL interrupts from the
card.
Reverting the earlier commit, i.e., restoring the RETRY_TIMEOUT
disabling, seems to resolve the issue. Since the removal of this code
was not based on any known issue and was purely a cleanup change, the
safest option here is to just revert that commit. Should there be
desire to clean this up in the future, the change will need to be
tested with a more complete coverage of cards and host systems.
http://bugzilla.kernel.org/show_bug.cgi?id=13483
Cc: stable@kernel.org
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6: (55 commits)
netxen: fix tx ring accounting
netxen: fix detection of cut-thru firmware mode
forcedeth: fix dma api mismatches
atm: sk_wmem_alloc initial value is one
net: correct off-by-one write allocations reports
via-velocity : fix no link detection on boot
Net / e100: Fix suspend of devices that cannot be power managed
TI DaVinci EMAC : Fix rmmod error
net: group address list and its count
ipv4: Fix fib_trie rebalancing, part 2
pkt_sched: Update drops stats in act_police
sky2: version 1.23
sky2: add GRO support
sky2: skb recycling
sky2: reduce default transmit ring
sky2: receive counter update
sky2: fix shutdown synchronization
sky2: PCI irq issues
sky2: more receive shutdown
sky2: turn off pause during shutdown
...
Manually fix trivial conflict in net/core/skbuff.c due to kmemcheck
Many developers use "/debug/" or "/debugfs/" or "/sys/kernel/debug/"
directory name to mount debugfs filesystem for ftrace according to
./Documentation/tracers/ftrace.txt file.
And, three directory names(ex:/debug/, /debugfs/, /sys/kernel/debug/) is
existed in kernel source like ftrace, DRM, Wireless, Documentation,
Network[sky2]files to mount debugfs filesystem.
debugfs means debug filesystem for debugging easy to use by greg kroah
hartman. "/sys/kernel/debug/" name is suitable as directory name
of debugfs filesystem.
- debugfs related reference: http://lwn.net/Articles/334546/
Fix inconsistency of directory name to mount debugfs filesystem.
* From Steven Rostedt
- find_debugfs() and tracing_files() in this patch.
Signed-off-by: GeunSik Lim <geunsik.lim@samsung.com>
Acked-by : Inaky Perez-Gonzalez <inaky@linux.intel.com>
Reviewed-by : Steven Rostedt <rostedt@goodmis.org>
Reviewed-by : James Smart <james.smart@emulex.com>
CC: Jiri Kosina <trivial@kernel.org>
CC: David Airlie <airlied@linux.ie>
CC: Peter Osterlund <petero2@telia.com>
CC: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
CC: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
CC: Masami Hiramatsu <mhiramat@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
If we are in PS mode, we have to process the received frame if
the SC_OP_WAIT_FOR_CAB bit is set.
Changes-licensed-under: ISC
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We have to remain awake if the SC_OP_WAIT_FOR_CAB flag is set.
Changes-licensed-under: ISC
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The ath9k_ps_{wakeup,restore} calls must be in balance.
Changes-licensed-under: ISC
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This ports the ath9k rfkill code to the new API offered by
cfg80211 and thus removes a lot of useless stuff.
("With this series a kernel panic, which is a regression, during module
unload disappears." -- Vasanthakumar Thiagarajan <vasanth@atheros.com>
Other patches in the series:
ath9k: Add helper to get ath9k specific current channel
ath9k: Make sure we have current channel in ah_curchan before rf
disable/enable
-- JWL)
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: Luis Rodriguez <mcgrof@gmail.com>
Tested-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch is from Nick Kossifidis but he forgot to send it. It ensures
that the beacon queue gets started in mesh mode as well, otherwise ath5k
will not beacon in mesh point mode.
At this time, we still need to issue a scan before mesh beaconing will
work but that appears to be a separate problem.
Signed-off-by: Andrey Yurovsky <andrey@cozybit.com>
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Always enable rfkill since the ifdefs in the code is not really worth
the Kconfig option. Also fix a few code style things, and remove the
usage of the ah_gpio[] array so we can remove it later.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch along with my previous patch in mac80211 "Fix the
way ADDBA count..", fixes hang in tx when connected to an HT
AP which rejects/times out on addba req.
AGGR_ADDBA_PROGRESS should be cleared in aggr state when addba
negotiation is terminated due to either addba response is timed out
or addba is denied by the AP. With out clearing this bit,
all frames are queued onto s/w queue for getting tx'd as aggr and
will never be scheduled onto hw queue.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch introduces initial rfkill support for the ath5k driver
based on rfkill support in the cfg80211 framework.
All rfkill related code is separated into newly created rfkill.c.
Changes to existing code are minimal:
* added a new data structure ath5k_rfkill to the ath5k_softc structure
* inserted calls to HW rfkill init/deinit routines
* ath5k_intr() has been extended to handle AR5K_INT_GPIO interrupts
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch is a back-port from aggregation testing code.
In the past, we didn't limit the amount of active tx urbs.
However, ar9170 only has a limited buffer reserved for
pending data frames.
This wasn't much of a problem with the slower 802.11b/g.
We simply stopped the full queue and moved on to something different
in the mean time. But - as you guessed it - this simple approach
stands in way for a decent aggregation implementation.
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This adds new commands that the original firmware will not send
but we can use them to debug firmware.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch removes code (deprecated by "cfg80211: add rfkill support" )
main.c: In function 'ar9170_op_config':
main.c:1306: warning: '__IEEE80211_CONF_CHANGE_RADIO_ENABLED'
is deprecated (declared at include/net/mac80211.h:551)
and a useless device state.
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When we remove the active interface, there's no need to continue
sending beacons; doing so would cause a null pointer deref in
ieee80211_beacon_get(). Disable the interrupt in remove_interface
and add a WARN_ON(!vif) in case there are other instances lurking.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This should help when reviewing issues regarding regulatory
domain on ath5k/ath9k/ar9170.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Handle error condition on copy_from_user() properly and
make sure a NUL terminated char[] is sent to strict_strtoul()
for proper conversion.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch completely rewrites the rfkill core to address
the following deficiencies:
* all rfkill drivers need to implement polling where necessary
rather than having one central implementation
* updating the rfkill state cannot be done from arbitrary
contexts, forcing drivers to use schedule_work and requiring
lots of code
* rfkill drivers need to keep track of soft/hard blocked
internally -- the core should do this
* the rfkill API has many unexpected quirks, for example being
asymmetric wrt. alloc/free and register/unregister
* rfkill can call back into a driver from within a function the
driver called -- this is prone to deadlocks and generally
should be avoided
* rfkill-input pointlessly is a separate module
* drivers need to #ifdef rfkill functions (unless they want to
depend on or select RFKILL) -- rfkill should provide inlines
that do nothing if it isn't compiled in
* the rfkill structure is not opaque -- drivers need to initialise
it correctly (lots of sanity checking code required) -- instead
force drivers to pass the right variables to rfkill_alloc()
* the documentation is hard to read because it always assumes the
reader is completely clueless and contains way TOO MANY CAPS
* the rfkill code needlessly uses a lot of locks and atomic
operations in locked sections
* fix LED trigger to actually change the LED when the radio state
changes -- this wasn't done before
Tested-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> [thinkpad]
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
"[PATCH 3/4 v2] ar9170: fix LED power state handling" revealed
a bug which can cause a ugly crash.
The delayed worker is canceled before the LED class functions are
unregistered... So, if something manages to update the LEDs
while unregister routine is running the timer could fire _after_ the
module has been unloaded.
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch contains a few more mostly random fixes for the USB front-end.
1. handle irq command response, instead of printing it to the console.
2. remove fixed FIXME.
(real fix: "ar9170usb: reset device on resume". )
3. some more one-liner.
- get rid of a useless "return;"
- add a few branch prediction hints in hot-paths
etc.
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch takes care of Johannes' deadlock report by moving the
mutex_lock right after cancel_work_sync in ar9170_op_stop.
Besides, the janitor does not need to hold the mutex anymore,
so this extra lines can be removed as well.
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch fixes a minor visual bug in the led code, which
left the LED in the wrong power state when it was toggled
in a _unexpected_ way (e.g: enabling the LED twice).
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch fixes a bug in configure_filter's (sub-)routines.
We never really cleared the flags once we updated the hardware state,
so we wasted our resources by applying already active settings.
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch introduces 3 new function which are used to update
the MAC state, whenever needed... e.g: after a band switch.
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch replace a few constant magics which may affected
the device when operating in a 40MHz channel.
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch only contains a few uncritical updates for the
hardware definition header.
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch fixes a simple copy & paste error that affected beacon
transmission in 802.11a mode.
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This adds:
USB 0x057C:0x8401 AVM FRITZ!WLAN USB Stick N
USB 0x057C:0x8402 AVM FRITZ!WLAN USB Stick N 2.4
These devices require the 1-stage firmware, if not present we
don't continue.
Cc: Peter Grabienski <Peter.Grabienski@Atheros.com>
Cc: Stephen Chen <Stephen.Chen@Atheros.com>
Cc: Michael Fortin <Michael.Fortin@Atheros.com>
Cc: Johnny Cheng <Johnny.Cheng@Atheros.com>
Cc: Yuan-Gu Wei <Yuan-Gu.Wei@atheros.com>
Cc: Joerg Albert <jal2@gmx.de>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
You can get the stage 1 firmware from here:
http://www.kernel.org/pub/linux/kernel/people/mcgrof/firmware/ar9170/ar9170.fw
md5sum: 34feec4ec0eae3bb92c7c1ea2dfb4530
sha1sum: 6e5250498b815c2940d97242de31e054ae44e079
Its license:
http://www.kernel.org/pub/linux/kernel/people/mcgrof/firmware/ar9170/LICENSE
This is a new firmware, tested with WNDA3100.
Cc: Peter Grabienski <Peter.Grabienski@Atheros.com>
Cc: Stephen Chen <Stephen.Chen@Atheros.com>
Cc: Michael Fortin <Michael.Fortin@Atheros.com>
Cc: Johnny Cheng <Johnny.Cheng@Atheros.com>
Cc: Yuan-Gu Wei <Yuan-Gu.Wei@atheros.com>
Cc: Joerg Albert <jal2@gmx.de>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It looks like mac80211 can request the driver to start beaconing with
a beacon interval of zero in some cases (at least for mesh point). This
does not sound correct and something may need to be fixed in
mac80211. However, taken into account the unpleasantness of getting
stuck in an infinite busy loop with rtnl_lock held, let's add a quick
workaround in the driver to avoid the worst symptom while someone more
familiar with the mesh implementation can figure out what should be done
with mac80211 as far as beacon interval configuration is concerned.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch adds the debug file to the ath9k debugfs, which lets you modify
the debug_mask at runtime, without having to reload the ath9k module.
Signed-off-by: Jeff Hansen <x@jeffhansen.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch combines the legacy and 11n rcstats into one, using the normal
rate table indices instead of two separate indices for each mode. Legacy
rates also get all of the PER and retry information, now, too.
Signed-off-by: Jeff Hansen <x@jeffhansen.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
I have a TrendNet 652-BRP running OpenWRT + ath9k very well. The only
problem is that the beacon gets stuck maybe once a day. After
Vasanthakumar Thiagarajan's "ath9k: cleanup beacon parameters
configuration" patch, ath9k would nearly re-configure the beacons after it
detected the stuck beacon, and did a reset. But it would fail the
SC_OP_TSF_RESET check in ath_beacon_config_ap. This patch gets the beacon
fully reconfigured after the reset.
Signed-off-by: Jeff Hansen <x@jeffhansen.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The patch moves some utility functions from mac80211 to cfg80211.
Because these functions are doing generic 802.11 operations so they
are not mac80211 specific. The moving allows some fullmac drivers
to be also benefit from these utility functions.
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: Samuel Ortiz <samuel.ortiz@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Some APs seem to drift away from the expected TBTT (timestamp %
beacon_int_in_usec differs quite a bit from zero) which can result in
us waking up way too early to receive a Beacon frame. In order to work
around this, re-configure the Beacon timers after having received a
Beacon frame from the AP (i.e., when we know the offset between the
expected TBTT and the actual time the AP is sending out the Beacon
frame).
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The previous version used a simple loop to go through all Beacon
frames when determining the next TBTT and DTIM count. This is not too
bad for the case where the setup happens before timesync (i.e., very
small TSF), but this can become very heavy operation if a short Beacon
interval is used and the current TSF is large.
In preparation for a patch to update timer setup based on Beacon
timestamp, optimize this routine to take fixed time regardless of the
actual TSF value.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is always discarded anyway but lets just set this to our
safest lowest.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath_regd_init() needs to be called with the wiphy already
properly set with the bands. Without this the custom regulatory
settings were not taking effect, and the device would get
the default channel settings from ath9k_[25]ghz_chantable.
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211 does not set PM field for normal data frames, so we need to
update that based on the current PS mode when using PS-Poll
(timeout=0) power save mode.
This allows the AP to remain in sync with our PS state. However, there
is still a potential race condition between PS state changes when
multiple TX queues are used and nullfunc and PS-Poll frames use
different queue. That corner case may need to be handled separately by
changing which queue is used either in ath9k or mac80211.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We must make sure the chip is awake when changing the RX filter
parameters. This could have caused problems, e.g., when changing the
interface to promiscuous mode while in sleep mode.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If the chip complains about TSF sync, make sure we remain awake to
sync with the next Beacon frame. In theory, this should not be needed
since we are currently trying to receive all Beacon frames, anyway,
better have this code ready should we ever change that.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When the chip is in sleep mode, there is no point trying to calibrate
the radio since it will just results in incorrect values being read
from registers and other potential issues. In addition, if we actually
start processing calibrate, do not allow the chip to be put into sleep
until we have completed the calibration step.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When using timeout=0 (PS-Poll) with mac80211, the driver will need to
wake up for TX requests and remain awake until the TX has been
completed (ACK received or timeout) or until the buffer frame(s) have
been received (in case the TX is for a PS-Poll frame).
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If we are trying to interpolate a curve with slope == 0, the return
value will always be the y-coordinate. In this code we are looping
until we reach a minimum y-coordinate on a line, which in the 0-slope
case can never happen, thus the loop never terminates.
The PCDAC steps come from the EEPROM and should never be equal, but
we should gracefully handle that case, so warn and bail out.
Reported-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We do not need to do this in ath_isr() and it looks like the modified
version ends up being more stable as far as being able receive beacon
frames is concerned. Furthermore, this reduces need to move between
AWAKE and NETWORK SLEEP states when processing some unrelated
interrupts.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath5k only generated the beacon when bss_info_changed() was called,
but for AP mode this is not enough, because the TIM IE would never
get updated and consequently PS mode clients wouldn't know about
buffered frames. Instead, get a new beacon on every SWBA interrupt.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch configures the beacon timers with beacon interval
and beacon period passed through vif.bss_conf. Also cache the
currecnt beacon configuration which will be used to configure
the beacon timers when the driver triggers it after reset.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The previous implementation was moving back to NETWORK SLEEP state
immediately after receiving a Beacon frame. This means that we are
unlikely to receive all the buffered broadcast/multicast frames that
would be sent after DTIM Beacon frames. Fix this by parsing the Beacon
frame and remaining awake, if needed, to receive the buffered
broadcast/multicast frames. The last buffered frame will trigger the
move back into NETWORK SLEEP state.
If the last broadcast/multicast frame is not received properly (or if
the AP fails to send it), the next Beacon frame will work as a backup
trigger for returning into NETWORK SLEEP.
A new debug type, PS (debug=0x800 module parameter), is added to make
it easier to debug potential power save issues in the
future. Currently, this is only used for the Beacon frame and buffered
broadcast/multicast receiving.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This makes use of the local fc variable in bit more places and uses a
common helper macro. The part of RX process that delivers skb's to
mac80211 is moved to a separate function in preparation for future
changes that will need to do this from two places. The modifications
here should not result in any functional changes.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The broadcast bit is in the first, not the last octet..
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We are not correctly listening to the regulatory max bandwidth
settings. To actually make use of it we need to redesign things
a bit. This patch does the work for that. We do this to so we
can obey to regulatory rules accordingly for use of HT40.
We end up dealing with HT40 by having two passes for each channel.
The first check will see if a 20 MHz channel fits into the channel's
center freq on a given frequency range. We check for a 20 MHz
banwidth channel as that is the maximum an individual channel
will use, at least for now. The first pass will go ahead and
check if the regulatory rule for that given center of frequency
allows 40 MHz bandwidths and we use this to determine whether
or not the channel supports HT40 or not. So to support HT40 you'll
need at a regulatory rule that allows you to use 40 MHz channels
but you're channel must also be enabled and support 20 MHz by itself.
The second pass is done after we do the regulatory checks over
an device's supported channel list. On each channel we'll check
if the control channel and the extension both:
o exist
o are enabled
o regulatory allows 40 MHz bandwidth on its frequency range
This work allows allows us to idependently check for HT40- and
HT40+.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch makes the return type of some of the functions
void as those functions always return true
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The AR_SREV_9285_1[12]_OR_LATER macros already contains the
AR_SREV_9285 check.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
On x86 this allows us to do the following small savings:
shave off 23 % off of the module's data, and
shave off 6 % off of the module's text.
We save 456 bytes, for those counting.
$ size ath9k.ko
text data bss dec hex filename
250794 3628 1600 256022 3e816 ath9k.ko
$ size ath9k-old.ko
text data bss dec hex filename
239114 15308 1600 256022 3e816 ath9k-old.ko
$ du -b ath9k.ko
4034244 ath9k.ko
$ du -b ath9k-old.ko
4033788 ath9k-old.ko
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fix this build error when CONFIG_PM is not set:
drivers/net/wireless/ath/ar9170/usb.c: In function 'ar9170_usb_probe':
drivers/net/wireless/ath/ar9170/usb.c:692:
error: 'struct usb_device' has no member named 'reset_resume'
Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add LED support on the IBM ThinkPad 11a/b/g Wireless LAN Mini Express
Adapter (AR5BXB6), found on the IBM/Lenovo Thinkpad X60/T60/Z60 series.
Signed-off-by: Paride Legovini <legovini@spiro.fisica.unipd.it>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Update ath5k to use the ctl settings for tx power based on current
regulatory domain.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Add spur filter support for RF5413 and later chips
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Add code to support the various antenna scenarios supported by hw
* For now hardcode the default scenario (single or dual omnis with
tx/rx diversity working and tx antenna handled by session -hw keeps
track on which antenna it got ack from each ap/station and maps each
ap/station to one of the antennas-).
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
After some debuging we were hitting the following bugs so far...
* Due to huge channel list hostapd couldn't get infos from the driver
and couldn't set the channel. If we manualy set the channel after
hostapd starts (by setting channel to 0 -auto), beacons are sent
but they wont show up on scan because they are malformed (they have
channel = 0 because hostapd doesn't update the channel info -this is
probably a hostapd bug so i'm CCing Jouni) and they get dropped. Bob
fixed this by only allowing standard channels to be registered so
now hostapd works as expected.
* Docs (and HAL source) say that we must write 0 on timer0 when
operating on AP mode to start TSF increment but this seems to
mess with DBA in many cases and beacon queue never gets started.
We fixed that on the previous patch.
We have some more things to deal with...
* For some reason (hw bug or something else) after restarting hostapd
a few times, beacon inteval seems to change from 100ms to a sec
(we get one beacon per sec).
* We need to set sleep timers on STA mode and enable power saving +
support PCF.
...but i think it's time we enable AP support "officialy" so that
we can get more feedback from users. I ran ath5k with the mentioned
patches + hostapd 0.6.8 and AP mode worked fine (it had some less
throughput on my tests than IBSS but it worked).
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Write next beacon timer even on AP mode since without this we get
no beacons + ath9k does it too. Docs say that we must write 0 on
this register on AP mode to start TSF increment, we do both to be
on the safe side.
* Fix num_tx_pending function, we never read the register :P that's
why we got all those "beacon queue 7 didn't stop messages".
* Put full prioriy on beacon queue, lock all queues with lower
priority using the arblock and also bypass any arblock by seting
the arblock ignore flag.
* For the CAB queue (do we need this thing ?, it seems crap) since
it's supposed to fire up after each beacon (we don't use it on driver
part, ath9k/MadWiFi does), don't make it DBA gated but instead make
it fire after each beacon by using the beacon sent gated flag.
* Increase bmiss threshold to 10, that's what we used on MadWiFi for
a long time. Also when we have pending frames on the beacon queue (we
got a beacon that didn't make it on the air) it's more likely that
the beacon queue never started, probably due to faulty DBA setting,
so change that "beacon queue didn't stop" message.
Tested this with AP mode and IBSS mode and seems to work fine ;-)
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Put remaining EEPROM information on ee struct and remove is_hb63
function.
Now we also have rfkill stuff available.
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Read Spur channel information from EEPROM and use default channels
for RF5413 compatible chips that don't have this info on EEPROM.
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Now that we have regulatory control enable the driver to set
txpower on hw
* Also use txpower table offset so that we can match
power range set by user/driver with indices on power table.
Tested 2 different cards (a CM9 and an RF5112-based ubnt) and got
the same output using a remote machine to measure per-packet rssi
(conected the cards using attenuators). I also switched between
various tx power levels and i saw an equal power change on the remote
machine (so txpower changes as expected) and verified that we have
the same output on each rate.
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The spin_lock handling uses lots of instructions on some archs.
With this patch the size of the ath9k module will be significantly
smaller.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Check for IEEE80211_TX_CTL_NO_ACK instead of is_multicast_ether_addr
when determining whether to use lowest rate without retries.
Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Ben Greear points out that the "too many interrupts" message will
never print in the intended case since the interrupt counter
will be -1 after the loop. Change it to pre-decrement so it will
be 0 on the thousandth iteration.
Cc: Ben Greear <greearb@candelatech.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
commit 8e218fb24f reverted the previous
patch (commit 925be8a307).
The C99 specification states in section 6.11.5:
The placement of a storage-class specifier other than at the
beginning of the declaration specifiers in a declaration is an
obsolescent feature.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Acked-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
remove redundant test: outlen is unsigned
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch takes care of an outstanding comment in
"[PATCH] ar9170usb: fix hang on resume" commit message.
>However, the device does not accept the firmware on resume.
>and it will exit with:
>
>> firmware part 1 upload failed (-71).
>> device is in a bad state. please reconnect it!
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Tested-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Set null key type even on ar5211, otherwise it en/decrypts every frame with
protected bit set which renders the card unusable on encrypted networks.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Cc: Luis R. Rodriguez <lrodriguez@atheros.com>
Cc: Bob Copeland <me@bobcopeland.com>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch uncomment a few lines that survived the RFCs.
However, there is not much to worry about, since AP mode is
not officially advertised and supported.
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Otus uses slightly different set of "Minimum MPDU Start Spacing" values
than the 802.11n D2.0 specifies. (the whole table is shifted by one and
therefore the 16us spacing is not officially available!)
And while we're at it, we also initialize our MAC's density register.
So, this annoying _feature_ will not break TX A-MPDU later.
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The config_interface method is a little strange, it contains the
BSSID and beacon updates, while bss_info_changed contains most
other BSS information for each interface. This patch removes
config_interface and rolls all the information it previously
passed to drivers into bss_info_changed.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We currently have two beacon interval configuration knobs:
hw.conf.beacon_int and vif.bss_info.beacon_int. This is
rather confusing, even though the former is used when we
beacon ourselves and the latter when we are associated to
an AP.
This just deprecates the hw.conf.beacon_int setting in favour
of always using vif.bss_info.beacon_int. Since it touches all
the beaconing IBSS code anyway, we can also add support for
the cfg80211 IBSS beacon interval configuration easily.
NOTE: The hw.conf.beacon_int setting is retained for now due
to drivers still using it -- I couldn't untangle all
drivers, some are updated in this patch.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
net/mac80211/tx.c: In function ‘ieee80211_tx_h_select_key’:
net/mac80211/tx.c:448: warning: ‘key’ may be used uninitialized in this function
drivers/net/wireless/ath/ath9k/rc.c: In function ‘ath_rc_rate_getidx’:
drivers/net/wireless/ath/ath9k/rc.c:815: warning: ‘nextindex’ may be used uninitialized in this function
drivers/net/wireless/hostap/hostap_plx.c: In function ‘prism2_plx_probe’:
drivers/net/wireless/hostap/hostap_plx.c:438: warning: ‘cor_index’ may be used uninitialized in this function
drivers/net/wireless/hostap/hostap_plx.c:438: warning: ‘cor_offset’ may be used uninitialized in this function
Signed-off-by: John W. Linville <linville@tuxdriver.com>
With this patch ar9170 is capable of receiving aggregated 802.11n frames
and sniffing on most networks without having a "debug message overhead".
(Includes phy initialization requested by
Johannes Berg <johannes@sipsolutions.net> -- JWL)
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch adds support for configuring HT40 channels
and receiving HT40 to ar9170. Receiving aggregation
doesn't seem to work right now, so it's not enabled.
Same goes for TX aggregation, but that probably needs
even more work.
With this, I can receive roughly 33 Mbits/sec.
The HT capabilities are a little odd, I tried following
otus here -- in particular having SGI_40 but not SGI_20
is a little weird but afaict that's what otus does.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Trying to separate header files into net/wireless.h and
net/cfg80211.h has been a source of confusion. Remove
net/wireless.h (because there also is the linux/wireless.h)
and subsume everything into net/cfg80211.h -- except the
definitions for regulatory structures which get moved to
a new header net/regulatory.h.
The "new" net/cfg80211.h is now divided into sections.
There are no real changes in this patch but code shuffling
and some very minor documentation fixes.
I have also, to make things reflect reality, put in a
copyright line for Luis to net/regulatory.h since that
is probably exclusively written by him but was formerly
in a file that only had my copyright line.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When the EEPROM is not in good condition we cannot continue so
we currently bail out but only ath5k is bailing out properly.
Both ath9k and ar9170 were proceeding and if a user were to run
into this they'd see an obscure panic. Lets propagate the error
as intended and make sure we inform the user by lifting the
error message from debug to a kernel error.
Stable note: You can find a port of this page here:
http://bombadil.infradead.org/~mcgrof/patches/ath9k/ath9k-fix-eeprom.patch.txt
Cc: stable@kernel.org
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Grabbing an ath5k_buf then dropping the lock is racy because the
referenced descriptor can be obtained in another thread and released
before the buffer is handed to the hardware. Likewise, manipulating
sc->rxlink without the lock can lead to having multiple self-linked
hardware descriptors.
Changes-licensed-under: 3-Clause-BSD
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch simplifies the code used to detect when the
self-linked DMA buffer is still in use by hardware, by
checking the hardware's rxdp register instead of looking
at the software buffer list.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
