d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
8eb6573e25
freebsd-skq/sys/dev/ath/if_ath.c

7061 lines
188 KiB
C
Raw Normal View History

Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
/*-
sys/dev: further adoption of SPDX licensing ID tags. Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.
2017-11-27 14:52:40 +00:00
* SPDX-License-Identifier: BSD-2-Clause-FreeBSD
*
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
* Copyright (c) 2002-2009 Sam Leffler, Errno Consulting
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer,
* without modification.
* 2. Redistributions in binary form must reproduce at minimum a disclaimer
* similar to the "NO WARRANTY" disclaimer below ("Disclaimer") and any
* redistribution must be conditioned upon including a substantially
* similar Disclaimer requirement for further binary redistribution.
*
* NO WARRANTY
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
* LIMITED TO, THE IMPLIED WARRANTIES OF NONINFRINGEMENT, MERCHANTIBILITY
* AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
* THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR SPECIAL, EXEMPLARY,
* OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
* IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
* THE POSSIBILITY OF SUCH DAMAGES.
*/
#include <sys/cdefs.h>
__FBSDID("$FreeBSD$");
/*
* Driver for the Atheros Wireless LAN controller.
acknowledge the contribution of Atsushi Onoe
2003-06-30 04:51:11 +00:00
*
* This software is derived from work of Atsushi Onoe; his contribution
* is greatly appreciated.
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
*/
#include "opt_inet.h"
o add opt_ath.h enable tweaking various config parameters for the driver without modifying the source code o default debug msgs and diag support to off MFC after: 3 days
2006-04-03 18:14:02 +00:00
#include "opt_ath.h"
Include opt_ah.h when compiling the driver. There are HAL methods which are actually direct register access, rather than simply HAL calls. Because of this, these register accesses would use the non-debug path in ah_osdep.h as opt_ah.h isn't included. With this, the correct register access methods are used, so debugging traces show things such as TXDP checking and TSF32 access.
2011-10-18 02:43:59 +00:00
/*
* This is needed for register operations which are performed
* by the driver - eg, calls to ath_hal_gettsf32().
Add a dependency on ALQ if IEEE80211_ALQ and/or AH_DEBUG_ALQ is included.
2012-03-16 23:12:40 +00:00
*
* It's also required for any AH_DEBUG checks in here, eg the
* module dependencies.
Include opt_ah.h when compiling the driver. There are HAL methods which are actually direct register access, rather than simply HAL calls. Because of this, these register accesses would use the non-debug path in ah_osdep.h as opt_ah.h isn't included. With this, the correct register access methods are used, so debugging traces show things such as TXDP checking and TSF32 access.
2011-10-18 02:43:59 +00:00
*/
#include "opt_ah.h"
Remove ATH_SUPPORT_TDMA and use IEEE80211_SUPPORT_TDMA instead. It doesn't make much sense to configure driver support w/o net80211. Note this means ath now depends on opt_wlan.h.
2009-03-30 19:23:49 +00:00
#include "opt_wlan.h"
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
#include <sys/param.h>
Correct spelling of reseting (found while researching the "bb hang detected" messages that are plaguing me). While I'm here, delete trailing whitespace.
2010-02-19 18:23:45 +00:00
#include <sys/systm.h>
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
#include <sys/sysctl.h>
Correct spelling of reseting (found while researching the "bb hang detected" messages that are plaguing me). While I'm here, delete trailing whitespace.
2010-02-19 18:23:45 +00:00
#include <sys/mbuf.h>
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
#include <sys/malloc.h>
#include <sys/lock.h>
#include <sys/mutex.h>
#include <sys/kernel.h>
#include <sys/socket.h>
#include <sys/sockio.h>
#include <sys/errno.h>
#include <sys/callout.h>
#include <sys/bus.h>
#include <sys/endian.h>
use a private task queue thread MFC after: 2 weeks
2006-02-09 21:48:51 +00:00
#include <sys/kthread.h>
#include <sys/taskqueue.h>
add SIOCZATHSTATS ioctl to zero driver statistics
2009-02-13 05:38:03 +00:00
#include <sys/priv.h>
Break out the ath PCI logic into a separate device/module. Introduce the AHB glue for Atheros embedded systems. Right now it's hard-coded for the AR9130 chip whose support isn't yet in this HAL; it'll be added in a subsequent commit. Kernel configuration files now need both 'ath' and 'ath_pci' devices; both modules need to be loaded for the ath device to work.
2011-03-31 08:07:13 +00:00
#include <sys/module.h>
Add KTR tracepoints to the ath driver, in order to debug TX, RX and interrupt handling. Sponsored by: Hobnob, Inc.
2011-11-08 19:02:59 +00:00
#include <sys/ktr.h>
Introduce a work-around for issues with the AR5416 based MAC on SMP devices. The AR5416 MAC (which shows up in the AR5008, AR9001, AR9002 devices) has issues with PCI transactions on SMP machines. This work-around enforces that register access is serialised through a (global for now) spinlock. This should stop the hangs people have seen with the AR5416 PCI devices on SMP hosts. Obtained by: Linux, Atheros
2011-11-09 22:39:44 +00:00
#include <sys/smp.h> /* for mp_ncpus */
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
#include <machine/bus.h>
Correct spelling of reseting (found while researching the "bb hang detected" messages that are plaguing me). While I'm here, delete trailing whitespace.
2010-02-19 18:23:45 +00:00
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
#include <net/if.h>
The r48589 promised to remove implicit inclusion of if_var.h soon. Prepare to this event, adding if_var.h to files that do need it. Also, include all includes that now are included due to implicit pollution via if_var.h Sponsored by: Netflix Sponsored by: Nginx, Inc.
2013-10-26 17:58:36 +00:00
#include <net/if_var.h>
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
#include <net/if_dl.h>
#include <net/if_media.h>
Stop embedding struct ifnet at the top of driver softcs. Instead the struct ifnet or the layer 2 common structure it was embedded in have been replaced with a struct ifnet pointer to be filled by a call to the new function, if_alloc(). The layer 2 common structure is also allocated via if_alloc() based on the interface type. It is hung off the new struct ifnet member, if_l2com. This change removes the size of these structures from the kernel ABI and will allow us to better manage them as interfaces come and go. Other changes of note: - Struct arpcom is no longer referenced in normal interface code. Instead the Ethernet address is accessed via the IFP2ENADDR() macro. To enforce this ac_enaddr has been renamed to _ac_enaddr. - The second argument to ether_ifattach is now always the mac address from driver private storage rather than sometimes being ac_enaddr. Reviewed by: sobomax, sam
2005-06-10 16:49:24 +00:00
#include <net/if_types.h>
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
#include <net/if_arp.h>
#include <net/ethernet.h>
#include <net/if_llc.h>
#include <net80211/ieee80211_var.h>
Overhaul regulatory support: o remove HAL_CHANNEL; convert the hal to use net80211 channels; this mostly involves mechanical changes to variable names and channel attribute macros o gut HAL_CHANNEL_PRIVATE as most of the contents are now redundant with the net80211 channel available o change api for ath_hal_init_channels: no more reglass id's, no more outdoor indication (was a noop), anM contents o add ath_hal_getchannels to have the hal construct a channel list without altering runtime state; this is used to retrieve the calibration list for the device in ath_getradiocaps o add ath_hal_set_channels to take a channel list and regulatory data from above and construct internal state to match (maps frequencies for 900MHz cards, setup for CTL lookups, etc) o compact the private channel table: we keep one private channel per frequency instead of one per HAL_CHANNEL; this gives a big space savings and potentially improves ani and calibration by sharing state (to be seen; didn't see anything in testing); a new config option AH_MAXCHAN controls the table size (default to 96 which was chosen to be ~3x the largest expected size) o shrink ani state and change to mirror private channel table (one entry per frequency indexed by ic_devdata) o move ani state flags to private channel state o remove country codes; use net80211 definitions instead o remove GSM regulatory support; it's no longer needed now that we pass in channel lists from above o consolidate ADHOC_NO_11A attribute with DISALLOW_ADHOC_11A o simplify initial channel list construction based on the EEPROM contents; we preserve country code support for now but may want to just fallback to a WWR sku and dispatch the discovered country code up to user space so the channel list can be constructed using the master regdomain tables o defer to net80211 for max antenna gain o eliminate sorting of internal channel table; now that we use ic_devdata as an index, table lookups are O(1) o remove internal copy of the country code; the public one is sufficient o remove AH_SUPPORT_11D conditional compilation; we always support 11d o remove ath_hal_ispublicsafetysku; not needed any more o remove ath_hal_isgsmsku; no more GSM stuff o move Conformance Test Limit (CTL) state from private channel to a lookup using per-band pointers cached in the private state block o remove regulatory class id support; was unused and belongs in net80211 o fix channel list construction to set IEEE80211_CHAN_NOADHOC, IEEE80211_CHAN_NOHOSTAP, and IEEE80211_CHAN_4MSXMIT o remove private channel flags CHANNEL_DFS and CHANNEL_4MS_LIMIT; these are now set in the constructed net80211 channel o store CHANNEL_NFCREQUIRED (Noise Floor Required) channel attribute in one of the driver-private flag bits of the net80211 channel o move 900MHz frequency mapping into the hal; the mapped frequency is stored in the private channel and used throughout the hal (no more mapping in the driver and/or net80211) o remove ath_hal_mhz2ieee; it's no longer needed as net80211 does the calculation and available in the net80211 channel o change noise floor calibration logic to work with compacted private channel table setup; this may require revisiting as we no longer can distinguish channel attributes (e.g. 11b vs 11g vs turbo) but since the data is used only to calculate status data we can live with it for now o change ah_getChipPowerLimits internal method to operate on a single channel instead of all channels in the private channel table o add ath_hal_gethwchannel to map a net80211 channel to a h/w frequency (always the same except for 900MHz channels) o add HAL_EEBADREG and HAL_EEBADCC status codes to better identify regulatory problems o remove CTRY_DEBUG and CTRY_DEFAULT enum's; these come from net80211 now o change ath_hal_getwirelessmodes to really return wireless modes supported by the hardware (was previously applying regulatory constraints) o return channel interference status with IEEE80211_CHANSTATE_CWINT (should change to a callback so hal api's can take const pointers) o remove some #define's no longer needed with the inclusion of <net80211/_ieee80211.h> Sponsored by: Carlson Wireless
2009-01-28 18:00:22 +00:00
#include <net80211/ieee80211_regdomain.h>
Hoist 802.11 encapsulation up into net80211: o call ieee80211_encap in ieee80211_start so frames passed down to drivers are already encapsulated o remove ieee80211_encap calls in drivers o fixup wi so it recreates the 802.3 head it requires from the 802.11 header contents o move fast-frame aggregation from ath to net80211 (conditional on IEEE80211_SUPPORT_SUPERG): - aggregation is now done in ieee80211_start; it is enabled when the packets/sec exceeds ieee80211_ffppsmin (net.wlan.ffppsmin) and frames are held on a staging queue according to ieee80211_ffagemax (net.wlan.ffagemax) to wait for a frame to combine with - drivers must call back to age/flush the staging queue (ath does this on tx done, at swba, and on rx according to the state of the tx queues and/or the contents of the staging queue) - remove fast-frame-related data structures from ath - add ieee80211_ff_node_init and ieee80211_ff_node_cleanup to handle per-node fast-frames state (we reuse 11n tx ampdu state) o change ieee80211_encap calling convention to include an explicit vap so frames coming through a WDS vap are recognized w/o setting M_WDS With these changes any device able to tx/rx 3Kbyte+ frames can use fast-frames. Reviewed by: thompsa, rpaulo, avatar, imp, sephe
2009-03-30 21:53:27 +00:00
#ifdef IEEE80211_SUPPORT_SUPERG
#include <net80211/ieee80211_superg.h>
#endif
Remove ATH_SUPPORT_TDMA and use IEEE80211_SUPPORT_TDMA instead. It doesn't make much sense to configure driver support w/o net80211. Note this means ath now depends on opt_wlan.h.
2009-03-30 19:23:49 +00:00
#ifdef IEEE80211_SUPPORT_TDMA
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
#include <net80211/ieee80211_tdma.h>
#endif
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
#include <net/bpf.h>
#ifdef INET
Correct spelling of reseting (found while researching the "bb hang detected" messages that are plaguing me). While I'm here, delete trailing whitespace.
2010-02-19 18:23:45 +00:00
#include <netinet/in.h>
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
#include <netinet/if_ether.h>
#endif
#include <dev/ath/if_athvar.h>
Switch to ath hal source code. Note this removes the ath_hal module; the ath module now brings in the hal support. Kernel config files are almost backwards compatible; supplying device ath_hal gives you the same chip support that the binary hal did but you must also include options AH_SUPPORT_AR5416 to enable the extended format descriptors used by 11n parts. It is now possible to control the chip support included in a build by specifying exactly which chips are to be supported in the config file; consult ath_hal(4) for information.
2008-12-01 16:53:01 +00:00
#include <dev/ath/ath_hal/ah_devid.h> /* XXX for softled */
Break out the diagnostic codes from ah_internal.h and place them in ah_diagcodes.h. Since we now have the source code, there's no reason to hide the diag codes from other areas. They live in the HAL as they form part of the HAL API and should still be treate as "potentially flexible; don't publish as a public API." But since they're already used as a public API (see follow-up commit), we may as well use them in place of magic constants.
2011-01-20 04:57:26 +00:00
#include <dev/ath/ath_hal/ah_diagcodes.h>
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
Break out the debug macros from if_ath.c into if_ath_debug.[ch] . This is prep work for breaking out the TX path into a separate set of source files.
2011-01-29 05:08:21 +00:00
#include <dev/ath/if_ath_debug.h>
Migrate the TX path code out of if_ath and into a separate source file. There's two reasons for this: * the raw and non-raw TX path shares a lot of duplicate code which should be refactored; * the 11n-ready chip TX path needs a little reworking.
2011-01-29 11:35:23 +00:00
#include <dev/ath/if_ath_misc.h>
Migrate the bulk of the RX routines out from if_ath.c to if_ath_rx.[ch]. * migrate the rx processing out into if_ath_rx.c * migrate the TSF functions into if_ath_tsf.h, as inlines This is in prepration for supporting the EDMA RX routines, required to support the AR93xx series NICs. TODO: * ath_start() shouldn't be private, but it's called as part of the RX path. I should likely migrate ath_rx_tasklet() back into if_ath.c and then return this to be 'static'. The RX code really shouldn't need to see TX routines (and vice versa.) * ath_beacon_* should be in if_ath_beacon.[ch]. * ath_tdma_* should be in if_ath_tdma.[ch] ...
2012-05-20 02:05:10 +00:00
#include <dev/ath/if_ath_tsf.h>
Migrate the TX path code out of if_ath and into a separate source file. There's two reasons for this: * the raw and non-raw TX path shares a lot of duplicate code which should be refactored; * the 11n-ready chip TX path needs a little reworking.
2011-01-29 11:35:23 +00:00
#include <dev/ath/if_ath_tx.h>
Migrate the sysctl related routines (statistics, debugging, etc) out of if_ath.c and into if_ath_sysctl.c .
2011-03-02 16:03:19 +00:00
#include <dev/ath/if_ath_sysctl.h>
First pass of LED related code changes. Migrate the LED code out of if_ath.c and into if_ath_led.c. These routines are _all_ software based LED blinking.
2011-12-26 05:37:09 +00:00
#include <dev/ath/if_ath_led.h>
Break the keycache management functions out into if_ath_keycache.c .
2011-03-02 17:19:54 +00:00
#include <dev/ath/if_ath_keycache.h>
Migrate the bulk of the RX routines out from if_ath.c to if_ath_rx.[ch]. * migrate the rx processing out into if_ath_rx.c * migrate the TSF functions into if_ath_tsf.h, as inlines This is in prepration for supporting the EDMA RX routines, required to support the AR93xx series NICs. TODO: * ath_start() shouldn't be private, but it's called as part of the RX path. I should likely migrate ath_rx_tasklet() back into if_ath.c and then return this to be 'static'. The RX code really shouldn't need to see TX routines (and vice versa.) * ath_beacon_* should be in if_ath_beacon.[ch]. * ath_tdma_* should be in if_ath_tdma.[ch] ...
2012-05-20 02:05:10 +00:00
#include <dev/ath/if_ath_rx.h>
Begin abstracting out the RX path in preparation for RX EDMA support. The RX EDMA support requires a modified approach to the RX descriptor handling. Specifically: * There's now two RX queues - high and low priority; * The RX queues are implemented as FIFOs; they're now an array of pointers to buffers; * .. and the RX buffer and descriptor are in the same "buffer", rather than being separate. So to that end, this commit abstracts out most of the RX related functions from the bulk of the driver. Notably, the RX DMA/buffer allocation isn't updated, primarily because I haven't yet fleshed out what it should look like. Whilst I'm here, create a set of matching but mostly unimplemented EDMA stubs. Tested: * AR9280, station mode TODO: * Thorough AP and other mode testing for non-EDMA chips; * Figure out how to allocate RX buffers suitable for RX EDMA, including correctly setting the mbuf length to compensate for the RX descriptor and completion status area.
2012-07-03 06:59:12 +00:00
#include <dev/ath/if_ath_rx_edma.h>
Begin separating out the TX DMA setup in preparation for TX EDMA support. * Introduce TX DMA setup/teardown methods, mirroring what's done in the RX path. Although the TX DMA descriptor is setup via ath_desc_alloc() / ath_desc_free(), there TX status descriptor ring will be allocated in this path. * Remove some of the TX EDMA capability probing from the RX path and push it into the new TX EDMA path.
2012-07-23 03:52:18 +00:00
#include <dev/ath/if_ath_tx_edma.h>
Migrate the TDMA management functions out of if_ath.c into if_ath_tdma.c. There's some TX path TDMA code in if_ath_tx.c which should be migrated out, but first I should likely try and verify/fix/repair the TDMA support in 9.x and -HEAD.
2012-05-20 02:49:42 +00:00
#include <dev/ath/if_ath_beacon.h>
Bring over the initial static bluetooth coexistence configuration for the WB195 combo NIC - an AR9285 w/ an AR3011 USB bluetooth NIC. The AR3011 is wired up using a 3-wire coexistence scheme to the AR9285. The code in if_ath_btcoex.c sets up the initial hardware mapping and coexistence configuration. There's nothing special about it - it's static; it doesn't try to configure bluetooth / MAC traffic priorities or try to figure out what's actually going on. It's enough to stop basic bluetooth traffic from causing traffic stalls and diassociation from the wireless network. To use this code, you must have the above NIC. No, it won't work for the AR9287+AR3012, nor the AR9485, AR9462 or AR955x combo cards. Then you set a kernel hint before boot or before kldload, where 'X' is the unit number of your AR9285 NIC: # kenv hint.ath.X.btcoex_profile=wb195 This will then appear in your boot messages: [100482] athX: Enabling WB195 BTCOEX This code is going to evolve pretty quickly (well, depending upon my spare time) so don't assume the btcoex API is going to stay stable. In order to use the bluetooth side, you must also load in firmware using ath3kfw and the binary firmware file (ath3k-1.fw in my case.) Tested: * AR9280, no interference * WB195 - AR9285 + AR3011 combo; STA mode; basic bluetooth inquiries were enough to cause traffic stalls and disassociations. This has stopped with the btcoex profile code. TODO: * Importantly - the AR9285 needs ASPM disabled if bluetooth coexistence is enabled. No, I don't know why. It's likely some kind of bug to do with the AR3011 sending bluetooth coexistence signals whilst the device is asleep. Since we don't actually sleep the MAC just yet, it shouldn't be a problem. That said, to be totally correct: + ASPM should be disabled - upon attach and wakeup + The PCIe powersave HAL code should never be called Look at what the ath9k driver does for inspiration. * Add WB197 (AR9287+AR3012) support * Add support for the AR9485, which is another combo like the AR9285 * The later NICs have a different signaling mechanism between the MAC and the bluetooth device; I haven't even begun to experiment with making that HAL code work. But it should be a lot more automatic. * The hardware can do much more interesting traffic weighting with bluetooth and wifi traffic. None of this is currently used. Ideally someone would code up something to watch the bluetooth traffic GPIO (via an interrupt) and then watch it go high/low; then figure out what the bluetooth traffic is and adjust things appropriately. * If I get the time I may add in some code to at least track this stuff and expose statistics. But it's up to someone else to experiment with the bluetooth coexistence support and add the interesting stuff (like "real" detection of bulk, audio, etc bluetooth traffic patterns and change wifi parameters appropriately - eg, maximum aggregate length, transmit power, using quiet time to control TX duty cycle, etc.)
2013-06-07 09:02:02 +00:00
#include <dev/ath/if_ath_btcoex.h>
[ath] commit initial bluetooth coexistence support for the MCI NICs. This is the initial framework to call into the MCI HAL routines and drive the basic state engine. The MCI bluetooth coex model uses a command channel between wlan and bluetooth, rather than a 2-wire or 3-wire signaling protocol to control things. This means the wlan and bluetooth chip exchange a lot more information and signaling, even at the per-packet level. The NICs in question can share the input LNA and output PA on the die, so they absolutely can't stomp on each other in a silly fashion. It also allows for the bluetooth side to signal when profiles come and go, so the driver can take appropriate control. There's also the possibility of dynamic bluetooth/wlan duty cycle control which I haven't yet really played with. It configures things up with a static "wlan wins everything" coexistence, configures up the available 2GHz channel map for bluetooth, sets a static duty cycle for bluetooth/wifi traffic priority and drives the basics needed to keep the MCI HAL code happy. It doesn't do any actual coexistence except to default to "wlan wins everything", which at least demonstrates that things do indeed work. Bluetooth inquiry frames still trump wifi (including beacons), so that demonstrates things really do indeed seem to work. Tested: * AR9462 (WB222), STA mode + bt * QCA9565 (WB335), STA mode + bt TODO: * .. the rest of coexistence. yes, bluetooth, not people. That stuff's hard. * It doesn't do the initial BT side calibration, which requires a WLAN chip reset. I'll fix up the reset path a bit more first before I enable that. * The 1-ant and 2-ant configuration bits aren't being set correctly in if_ath_btcoex.c - I'll dig into that and fix it in a subsequent commit. * It's not enabled by default for WB222/WB225 even though I believe it now can be - I'll chase that up in a subsequent commit. Obtained from: Qualcomm Atheros, Linux ath9k
2016-06-02 00:51:36 +00:00
#include <dev/ath/if_ath_btcoex_mci.h>
Add a new (skeleton) spectral mode manager module.
2013-01-02 03:59:02 +00:00
#include <dev/ath/if_ath_spectral.h>
Migrate the LNA mixing diversity machinery from the AR9285 HAL to the driver. The AR9485 chip and AR933x SoC both implement LNA diversity. There are a few extra things that need to happen before this can be flipped on for those chips (mostly to do with setting up the different bias values and LNA1/LNA2 RSSI differences) but the first stage is putting this code into the driver layer so it can be reused. This has the added benefit of making it easier to expose configuration options and diagnostic information via the ioctl API. That's not yet being done but it sure would be nice to do so. Tested: * AR9285, with LNA diversity enabled * AR9285, with LNA diversity disabled in EEPROM
2013-06-12 14:52:57 +00:00
#include <dev/ath/if_ath_lna_div.h>
Flesh out the radar detection related operations for the ath driver. This is in no way a complete DFS/radar detection implementation! It merely creates an abstracted interface which allows for future development of the DFS radar detection code. Note: Net80211 already handles the bulk of the DFS machinery, all we need to do here is figure out that a radar event has occured and inform it as such. It then drives the DFS state engine for us. The "null" DFS radar detection module is included by default; it doesn't require a device line. This commit: * Adds a simple abstracted layer for radar detection state - sys/dev/ath/ath_dfs/; * Implements a null DFS module which doesn't do anything; (ie, implements the exact behaviour at the moment); * Adds hooks to the ath driver to process received radar events and gives the DFS module a chance to determine whether a radar has been detected. Obtained from: Atheros
2011-06-01 20:09:49 +00:00
#include <dev/ath/if_athdfs.h>
[ath] migrate ioctl and busdma memory operations out into separate source files. This should be a big no-op pass; and reduces the size of if_ath.c. I'm hopefully soon going to take a whack at the USB support for ath(4) and this'll require some reuse of the busdma memory code.
2015-11-24 03:42:58 +00:00
#include <dev/ath/if_ath_ioctl.h>
#include <dev/ath/if_ath_descdma.h>
Break out the debug macros from if_ath.c into if_ath_debug.[ch] . This is prep work for breaking out the TX path into a separate set of source files.
2011-01-29 05:08:21 +00:00
add tx99 hooks MFC after: 2 weeks
2006-02-09 21:28:11 +00:00
#ifdef ATH_TX99_DIAG
#include <dev/ath/ath_tx99/ath_tx99.h>
#endif
Don't compile in my (not yet committed) ath_alq code unless ATH_DEBUG_ALQ is defined. This will unbreak ATH_DEBUG builds.
2012-11-07 16:34:09 +00:00
#ifdef ATH_DEBUG_ALQ
Disable my software queue TIM and PS handling for now. ps-poll is totally broken in its current form. This should unbreak things enough to let people use PS-POLL devices, but leave it in place for me to finish PS-POLL handling.
2012-11-07 06:29:45 +00:00
#include <dev/ath/if_ath_alq.h>
#endif
/*
* Only enable this if you're working on PS-POLL support.
*/
Implement my first cut at "correct" node power-save and PS-POLL support. This implements PS-POLL awareness i nthe * Implement frame "leaking", which allows for a software queue to be scheduled even though it's asleep * Track whether a frame has been leaked or not * Leak out a single non-AMPDU frame when transmitting aggregates * Queue BAR frames if the node is asleep * Direct-dispatch the rest of control and management frames. This allows for things like re-association to occur (which involves sending probe req/resp as well as assoc request/response) when the node is asleep and then tries reassociating. * Limit how many frames can set in the software node queue whilst the node is asleep. net80211 is already buffering frames for us so this is mostly just paranoia. * Add a PS-POLL method which leaks out a frame if there's something in the software queue, else it calls net80211's ps-poll routine. Since the ath PS-POLL routine marks the node as having a single frame to leak, either a software queued frame would leak, OR the next queued frame would leak. The next queued frame could be something from the net80211 power save queue, OR it could be a NULL frame from net80211. TODO: * Don't transmit further BAR frames (eg via a timeout) if the node is currently asleep. Otherwise we may end up exhausting management frames due to the lots of queued BAR frames. I may just undo this bit later on and direct-dispatch BAR frames even if the node is asleep. * It would be nice to burst out a single A-MPDU frame if both ends support this. I may end adding a FreeBSD IE soon to negotiate this power save behaviour. * I should make STAs timeout of power save mode if they've been in power save for more than a handful of seconds. This way cards that get "stuck" in power save mode don't stay there for the "inactivity" timeout in net80211. * Move the queue depth check into the driver layer (ath_start / ath_transmit) rather than doing it in the TX path. * There could be some naughty corner cases with ps-poll leaking. Specifically, if net80211 generates a NULL data frame whilst another transmitter sends a normal data frame out net80211 output / transmit, we need to ensure that the NULL data frame goes out first. This is one of those things that should occur inside the VAP/ic TX lock. Grr, more investigations to do.. Tested: * STA: AR5416, AR9280 * AP: AR5416, AR9280, AR9160
2013-05-15 18:33:05 +00:00
#define ATH_SW_PSQ
Disable my software queue TIM and PS handling for now. ps-poll is totally broken in its current form. This should unbreak things enough to let people use PS-POLL devices, but leave it in place for me to finish PS-POLL handling.
2012-11-07 06:29:45 +00:00
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
/*
* ATH_BCBUF determines the number of vap's that can transmit
* beacons and also (currently) the number of vap's that can
* have unique mac addresses/bssid. When staggering beacons
* 4 is probably a good max as otherwise the beacons become
* very closely spaced and there is limited time for cab q traffic
* to go out. You can burst beacons instead but that is not good
* for stations in power save and at some point you really want
* another radio (and channel).
*
* The limit on the number of mac addresses is tied to our use of
* the U/L bit and tracking addresses in a byte; it would be
* worthwhile to allow more for applications like proxy sta.
*/
CTASSERT(ATH_BCBUF <= 8);
static struct ieee80211vap *ath_vap_create(struct ieee80211com *,
Fix some net80211 enum nits: - ic_vap_create() uses an ieee80211_opmode argument - ieee80211_rate2media() takes an ieee80211_phymode argument - ieee80211_plcp2rate() takes an ieee80211_phytype argument - cast to enum ieee80211_protmode and ieee80211_roamingmode to silence compiler warnings Submitted by: arundel@
2011-12-17 10:23:17 +00:00
const char [IFNAMSIZ], int, enum ieee80211_opmode, int,
const uint8_t [IEEE80211_ADDR_LEN],
const uint8_t [IEEE80211_ADDR_LEN]);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
static void ath_vap_delete(struct ieee80211vap *);
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
static int ath_init(struct ath_softc *);
static void ath_stop(struct ath_softc *);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
static int ath_reset_vap(struct ieee80211vap *, u_long);
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
static int ath_transmit(struct ieee80211com *, struct mbuf *);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
static int ath_media_change(struct ifnet *);
replace if_watchdog w/ private callout; probably can merge this with the calibration work sometime in the future
2009-03-09 23:10:19 +00:00
static void ath_watchdog(void *);
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
static void ath_parent(struct ieee80211com *);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
static void ath_fatal_proc(void *, int);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
static void ath_bmiss_vap(struct ieee80211vap *);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
static void ath_bmiss_proc(void *, int);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
static void ath_key_update_begin(struct ieee80211vap *);
static void ath_key_update_end(struct ieee80211vap *);
Break out the multicast programming into its own hardware specific call, which assumes the hardware is awake. Turn ath_update_mcast() into a routine that's only called from the net80211 layer - and it forces the hardware awake first. This fixes a LOR from the EDMA RX path which calls ath_mode_init() with the RX lock held - the driver lock can't also be grabbed. This path assumes that the ath_mode_init() callers all wake up the NIC first. Tested: * AR9485, STA mode, powersave
2014-05-05 08:12:21 +00:00
static void ath_update_mcast_hw(struct ath_softc *);
Change three methods in struct ieee80211com, namely ic_updateslot, ic_update_mcast and ic_update_promisc, to pass pointer to the ieee80211com, not to the ifnet. Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-05-25 19:53:29 +00:00
static void ath_update_mcast(struct ieee80211com *);
static void ath_update_promisc(struct ieee80211com *);
static void ath_updateslot(struct ieee80211com *);
Update with last year of work.
2004-12-08 17:34:36 +00:00
static void ath_bstuck_proc(void *, int);
Attempt to further fix some of the concurrency/reset issues that occur. * ath_reset() is being called in softclock context, which may have the thing sleep on a lock. To avoid this, since we really _shouldn't_ be sleeping on any locks, break out the no-loss reset path into a tasklet and call that from: + ath_calibrate() + ath_watchdog() This has the added advantage that it'll end up also doing the frame RX cleanup from within the taskqueue context, rather than the softclock context. * Shuffle around the taskqueue_block() call to be before we grab the lock and disable interrupts. The trouble here is that taskqueue_block() doesn't block currently queued (but not yet running) tasks so calling it doesn't guarantee no further tasks (that weren't running on _A_ CPU at the time of this call) will complete. Calling taskqueue_drain() on these tasks won't work because if any _other_ thread calls taskqueue_enqueue() for whatever reason, everything gets very angry and stops working. This slightly changes the race condition enough to let ath_rx_tasklet() run before we try disabling it, and thus quietens the warnings a bit. The (more) true solution will be doing something like the following: * having a taskqueue_blocked mask in ath_softc; * having an interrupt_blocked mask in ath_softc; * only calling taskqueue_drain() on each individual task _after_ the lock has been acquired - that way no further tasklet scheduling is going to occur. * Then once the tasks have been blocked _and_ the interrupt has been disabled, call taskqueue_drain() on each, ensuring that anything that _was_ scheduled or running is removed. The trouble is if something calls taskqueue_enqueue() on a task after taskqueue_blocked() has been called but BEFORE taskqueue_drain() has been called, ta_pending will be set to 1 and taskqueue_drain() will sit there stuck in msleep() until you hard-kill the machine. PR: kern/165382 PR: kern/165220
2012-02-25 19:12:54 +00:00
static void ath_reset_proc(void *, int);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
static int ath_desc_alloc(struct ath_softc *);
static void ath_desc_free(struct ath_softc *);
Change the calling convention for ic_node_alloc to deal with some longstanding issues: o pass the vap since it's now the "coin of the realm" and required to do things like set initial tx parameters in private node state for use prior to association o pass the mac address as cards that maintain outboard station tables require this to create an entry (e.g. in ibss mode) o remove the node table reference, we only have one node table and it's unlikely this will change so this is not needed to find the com structure
2008-06-07 18:38:02 +00:00
static struct ieee80211_node *ath_node_alloc(struct ieee80211vap *,
const uint8_t [IEEE80211_ADDR_LEN]);
Break out the node cleanup and node free path, in preparation for doing software TX queue management. The software queued TX frames will be freed by the new cleanup function. Sponsored by: Hobnob, Inc.
2011-11-08 18:48:26 +00:00
static void ath_node_cleanup(struct ieee80211_node *);
Update with last year of work.
2004-12-08 17:34:36 +00:00
static void ath_node_free(struct ieee80211_node *);
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
static void ath_node_getsignal(const struct ieee80211_node *,
int8_t *, int8_t *);
Close race in handling mcast traffic when operating as an ap with stations in power save: add a new q where mcast frames are stashed and on beacon update (at DTIM) move frames from the mcast q to the cabq and start it. This ensures the cabq is only manipulated in one place. Sponsored by: Hobnob MFC after: 2 weeks
2006-06-26 03:10:45 +00:00
static void ath_txq_init(struct ath_softc *sc, struct ath_txq *, int);
Update with last year of work.
2004-12-08 17:34:36 +00:00
static struct ath_txq *ath_txq_setup(struct ath_softc*, int qtype, int subtype);
static int ath_tx_setup(struct ath_softc *, int, int);
static void ath_tx_cleanupq(struct ath_softc *, struct ath_txq *);
static void ath_tx_cleanup(struct ath_softc *);
Break out ath_draintxq() into a method and un-methodize ath_tx_processq(). Now that I understand what's going on with this, I've realised that it's going to be quite difficult to implement a processq method in the EDMA case. Because there's a separate TX status FIFO, I can't just run processq() on each EDMA TXQ to see what's finished. i have to actually run the TX status queue and handle individual TXQs. So: * unmethodize ath_tx_processq(); * leave ath_tx_draintxq() as a method, as it only uses the completion status for debugging rather than actively completing the frames (ie, all frames here are failed); * Methodize ath_draintxq(). The EDMA ath_draintxq() will have to take care of running the TX completion FIFO before (potentially) freeing frames in the queue. The only two places where ath_tx_draintxq() (on a single TXQ) are used: * ath_draintxq(); and * the CABQ handling in the beacon setup code - it drains the CABQ before populating the CABQ with frames for a new beacon (when doing multi-VAP operation.) So it's quite possible that once I methodize the CABQ and beacon handling, I can just drop ath_tx_draintxq() in its entirety. Finally, it's also quite possible that I can remove ath_tx_draintxq() in the future and just "teach" it to not check the status when doing EDMA.
2012-08-12 00:37:29 +00:00
static int ath_tx_processq(struct ath_softc *sc, struct ath_txq *txq,
int dosched);
Update with last year of work.
2004-12-08 17:34:36 +00:00
static void ath_tx_proc_q0(void *, int);
static void ath_tx_proc_q0123(void *, int);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
static void ath_tx_proc(void *, int);
Defer the rescheduling of TID -> TXQ frames in some instances. Right now ath_txq_sched() is mainly called from the TX ath_tx_processq() routine, which is (mostly) done as part of the taskqueue. It shouldn't be called outside the taskqueue. But now that I'm about to flip back on BAR TX, I'm going to start stressing the ath_tx_tid_pause() and ath_tx_tid_resume() paths. What I don't want to have happen is a reschedule of the TID traffic _during_ the completion of TX frames. Ideally I'd like to have a way to flag back up to the processing code that the current hardware queue should be rechecked for software TID queue frames. But for now, this should suffice for the BAR TX case. I may eventually delete this code once I've brought some further sanity to the general TX queue/completion path.
2012-03-29 17:39:18 +00:00
static void ath_txq_sched_tasklet(void *, int);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
static int ath_chan_set(struct ath_softc *, struct ieee80211_channel *);
Update with last year of work.
2004-12-08 17:34:36 +00:00
static void ath_chan_change(struct ath_softc *, struct ieee80211_channel *);
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
static void ath_scan_start(struct ieee80211com *);
static void ath_scan_end(struct ieee80211com *);
static void ath_set_channel(struct ieee80211com *);
* Since the API changed along the -CURRENT path (december 2011), add a FreeBSD_version check. It should work fine for compiling on -HEAD, 9.x and 8.x. * Conditionally compile the 11n options only when 11n is enabled. The above changes allow the ath(4) driver to compile and run on 8.1-RELEASE (Hi old PC-BSD!) but with the 11n stuff disabled. I've done a test against the net80211 and tools in 8.1-RELEASE. The NIC used in testing is the AR2427 in an EEEPC. Just to be clear - this change is to allow the -HEAD ath/hal/rate code to run on 9.x _and_ 8.x with no source changes. However, when running on earlier kernels, it should only be used for legacy mode. (Don't define ATH_ENABLE_11N.)
2012-04-10 06:25:11 +00:00
#ifdef ATH_ENABLE_11N
Add the new channel width change field to the ath(4) driver. This is not entirely correct as it simply resets the channel, flushing whatever is in the TX/RX queue. This can and will break aggregation BAW tracking. But the alternative (HT40 frames being sent with the hardware in HT20 mode) is even worse. There's still a small window between the htinfo being received (and the ni_chw field being updated) which could cause problems. I'll look at fleshing this out in follow-up commits. PR: kern/166286
2012-03-25 03:14:31 +00:00
static void ath_update_chw(struct ieee80211com *);
* Since the API changed along the -CURRENT path (december 2011), add a FreeBSD_version check. It should work fine for compiling on -HEAD, 9.x and 8.x. * Conditionally compile the 11n options only when 11n is enabled. The above changes allow the ath(4) driver to compile and run on 8.1-RELEASE (Hi old PC-BSD!) but with the 11n stuff disabled. I've done a test against the net80211 and tools in 8.1-RELEASE. The NIC used in testing is the AR2427 in an EEEPC. Just to be clear - this change is to allow the -HEAD ath/hal/rate code to run on 9.x _and_ 8.x with no source changes. However, when running on earlier kernels, it should only be used for legacy mode. (Don't define ATH_ENABLE_11N.)
2012-04-10 06:25:11 +00:00
#endif /* ATH_ENABLE_11N */
[ath] initial station side quiet IE support. This implements hardware assisted quiet IE support. Quiet time is an optional interval on DFS channels (but doesn't have to be DFS only channels! sigh) where the station and AP can be quiet in order to allow for channel utilisation measurements. Typically that's stuff like radar detection, spectral scan, other-BSS frame sniffing, checking how busy the air is, etc. The hardware implements it as one of the generic timers, which is supplied a period, offset from the trigger period and duration to stay quiet. The AP can announce quiet time configurations which change, and so this code also tracks that. Implementation details: * track the current quiet time IE * compare the new one against the previous one - if only the TBTT counter changes, don't update things * If tbttcount=1 then program it into the hardware - that is when it is easiest to program the correct starting offset (one TBTT + configured offset). * .. later on check to see if it can be done on any tbttcount * If the IE goes away then remove the quiet timer and clear the config * Upon reset, state change, new beacon - clear quiet time IE and just let it resync from the next beacon. History: This was work done initially by sibridgetech.com in 2011/2012/2013 as part of some FreeBSD wifi DFS contracting work they had for a third party. They implemented the net80211 quiet time IE pieces and had some test code for the station side which didn't entirely use the timers correctly. I figured out how to use the timers correctly without stopping/starting the transmit DMA engine each time. When done correctly, the timer just needs to be programmed once and left alone until the next configuration change. So, thanks to Himali Patel and Parthiv Shah for their work way back then. I finally figured it out and finished it! TODO: * Now, I'd rather net80211 did the quiet time IE tracking and parsing, pushing configurations into the driver is needed. I'll look at doing that in a subsequent update. * This doesn't handle multiple quiet time IEs, which will currently just mess things up. I'll look into supporting that in the future (at least by only obeying "one" of them, and then ignoring subsequent IEs in a beacon/probe frame.) * This also implements the STA side and not the AP side - the AP side will come later, and involves taking various other intervals into account (eg the beacon offset for multi-VAP modes, the SWBA time, etc, etc) as well as obtaining the configuration when a beacon is configured/generated rather than "hearing" an IE. * .. investigate supporting quiet IE in mesh, tdma, ibss modes * .. investigate supporting quiet IE for non-DFS channels (so this can be done for say, 2GHz channels.) * Chances are i should commit NULL methods for the ar5210, ar5211 HALs.. Tested: * AR9380, STA mode - announcing quiet, removing quiet, changing quite time config, whilst doing iperf testing; * AR9380, AP mode.
2017-02-09 23:15:11 +00:00
static int ath_set_quiet_ie(struct ieee80211_node *, uint8_t *);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
static void ath_calibrate(void *);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
static int ath_newstate(struct ieee80211vap *, enum ieee80211_state, int);
Misc keycache changes: o purge ath_initkeytable; it's not needed o add multicast key search support for supporting multiple group keys (disabled for now; requires updated hal) o create keycache entry for stations using open auth so they get h/w antenna management support o add keycache -> node mapping table; eliminates mac-based lookup in the net80211 layer
2005-06-06 16:39:21 +00:00
static void ath_setup_stationkey(struct ieee80211_node *);
simplify ic_newassoc callback MFC after: 3 days
2005-07-22 17:57:16 +00:00
static void ath_newassoc(struct ieee80211_node *, int);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
static int ath_setregdomain(struct ieee80211com *,
struct ieee80211_regdomain *, int,
struct ieee80211_channel []);
change ic_getradiocaps driver callback to include the max # channels so callers know the size of the array passed down
2009-01-27 23:19:36 +00:00
static void ath_getradiocaps(struct ieee80211com *, int, int *,
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
struct ieee80211_channel []);
static int ath_getchannels(struct ath_softc *);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
Update with last year of work.
2004-12-08 17:34:36 +00:00
static int ath_rate_setup(struct ath_softc *, u_int mode);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
static void ath_setcurmode(struct ath_softc *, enum ieee80211_phymode);
Update with last year of work.
2004-12-08 17:34:36 +00:00
static void ath_announce(struct ath_softc *);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
Flesh out the radar detection related operations for the ath driver. This is in no way a complete DFS/radar detection implementation! It merely creates an abstracted interface which allows for future development of the DFS radar detection code. Note: Net80211 already handles the bulk of the DFS machinery, all we need to do here is figure out that a radar event has occured and inform it as such. It then drives the DFS state engine for us. The "null" DFS radar detection module is included by default; it doesn't require a device line. This commit: * Adds a simple abstracted layer for radar detection state - sys/dev/ath/ath_dfs/; * Implements a null DFS module which doesn't do anything; (ie, implements the exact behaviour at the moment); * Adds hooks to the ath driver to process received radar events and gives the DFS module a chance to determine whether a radar has been detected. Obtained from: Atheros
2011-06-01 20:09:49 +00:00
static void ath_dfs_tasklet(void *, int);
Pause and unpause the software queues for a given node based on the net80211 node power save state. * Add an ATH_NODE_UNLOCK_ASSERT() check * Add a new node field - an_is_powersave * Pause/unpause the queue based on the node state * Attempt to handle net80211 concurrency issues so the queue doesn't get paused/unpaused more than once at a time from the net80211 power save code. Whilst here (and breaking my usual rule), set CLRDMASK when a queue is unpaused, regardless of whether the queue has some pending traffic. This means the first frame from that TID (now or later) will hvae CLRDMASK set. Also whilst here, bump the swretrymax counters whenever the filtered frames code expires a frame. Again, breaking my rule, but this is just a statistics thing rather than a functional change. This doesn't fix ps-poll (but it doesn't break it too much worse than it is at the present) or correcting the TID updates. That's next on the list. Tested: * AR9220 AP (Atheros AP96 reference design) * Macbook Pro and LG Optimus 1 Android phone, both setting and clearing power save state (but not using PS-POLL.)
2012-10-03 23:23:45 +00:00
static void ath_node_powersave(struct ieee80211_node *, int);
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
static int ath_node_set_tim(struct ieee80211_node *, int);
Implement my first cut at "correct" node power-save and PS-POLL support. This implements PS-POLL awareness i nthe * Implement frame "leaking", which allows for a software queue to be scheduled even though it's asleep * Track whether a frame has been leaked or not * Leak out a single non-AMPDU frame when transmitting aggregates * Queue BAR frames if the node is asleep * Direct-dispatch the rest of control and management frames. This allows for things like re-association to occur (which involves sending probe req/resp as well as assoc request/response) when the node is asleep and then tries reassociating. * Limit how many frames can set in the software node queue whilst the node is asleep. net80211 is already buffering frames for us so this is mostly just paranoia. * Add a PS-POLL method which leaks out a frame if there's something in the software queue, else it calls net80211's ps-poll routine. Since the ath PS-POLL routine marks the node as having a single frame to leak, either a software queued frame would leak, OR the next queued frame would leak. The next queued frame could be something from the net80211 power save queue, OR it could be a NULL frame from net80211. TODO: * Don't transmit further BAR frames (eg via a timeout) if the node is currently asleep. Otherwise we may end up exhausting management frames due to the lots of queued BAR frames. I may just undo this bit later on and direct-dispatch BAR frames even if the node is asleep. * It would be nice to burst out a single A-MPDU frame if both ends support this. I may end adding a FreeBSD IE soon to negotiate this power save behaviour. * I should make STAs timeout of power save mode if they've been in power save for more than a handful of seconds. This way cards that get "stuck" in power save mode don't stay there for the "inactivity" timeout in net80211. * Move the queue depth check into the driver layer (ath_start / ath_transmit) rather than doing it in the TX path. * There could be some naughty corner cases with ps-poll leaking. Specifically, if net80211 generates a NULL data frame whilst another transmitter sends a normal data frame out net80211 output / transmit, we need to ensure that the NULL data frame goes out first. This is one of those things that should occur inside the VAP/ic TX lock. Grr, more investigations to do.. Tested: * STA: AR5416, AR9280 * AP: AR5416, AR9280, AR9160
2013-05-15 18:33:05 +00:00
static void ath_node_recv_pspoll(struct ieee80211_node *, struct mbuf *);
Flesh out the radar detection related operations for the ath driver. This is in no way a complete DFS/radar detection implementation! It merely creates an abstracted interface which allows for future development of the DFS radar detection code. Note: Net80211 already handles the bulk of the DFS machinery, all we need to do here is figure out that a radar event has occured and inform it as such. It then drives the DFS state engine for us. The "null" DFS radar detection module is included by default; it doesn't require a device line. This commit: * Adds a simple abstracted layer for radar detection state - sys/dev/ath/ath_dfs/; * Implements a null DFS module which doesn't do anything; (ie, implements the exact behaviour at the moment); * Adds hooks to the ath driver to process received radar events and gives the DFS module a chance to determine whether a radar has been detected. Obtained from: Atheros
2011-06-01 20:09:49 +00:00
Remove ATH_SUPPORT_TDMA and use IEEE80211_SUPPORT_TDMA instead. It doesn't make much sense to configure driver support w/o net80211. Note this means ath now depends on opt_wlan.h.
2009-03-30 19:23:49 +00:00
#ifdef IEEE80211_SUPPORT_TDMA
Migrate the TDMA management functions out of if_ath.c into if_ath_tdma.c. There's some TX path TDMA code in if_ath_tx.c which should be migrated out, but first I should likely try and verify/fix/repair the TDMA support in 9.x and -HEAD.
2012-05-20 02:49:42 +00:00
#include <dev/ath/if_ath_tdma.h>
#endif
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
SYSCTL_DECL(_hw_ath);
/* XXX validate sysctl values */
New periodic calibration scheme needed for 11n parts that have multiple algorithms and potentially collect multiple samples. Instead of a single calibration interval we now have short and long intervals; the long interval roughly corresponds to the previous single interval. The short interval is used to speedup collection of samples and happens much quicker. We make calls using the short interval until we're told the calibration work is complete at which point we fallback to the long interval. In addition there is a much longer reset interval used to flush all calibration state and cause everthing to start anew. With these changes you can also disable calibration entirely by setting the long interval to zero.
2008-12-07 19:26:34 +00:00
static int ath_longcalinterval = 30; /* long cals every 30 secs */
SYSCTL_INT(_hw_ath, OID_AUTO, longcal, CTLFLAG_RW, &ath_longcalinterval,
0, "long chip calibration interval (secs)");
static int ath_shortcalinterval = 100; /* short cals every 100 ms */
SYSCTL_INT(_hw_ath, OID_AUTO, shortcal, CTLFLAG_RW, &ath_shortcalinterval,
0, "short chip calibration interval (msecs)");
static int ath_resetcalinterval = 20*60; /* reset cal state 20 mins */
SYSCTL_INT(_hw_ath, OID_AUTO, resetcal, CTLFLAG_RW, &ath_resetcalinterval,
0, "reset chip calibration results (secs)");
ANI changes #1 - split out the ANI polling from the RxMonitor hook. The rxmonitor hook is called on each received packet. This can get very, very busy as the tx/rx/chanbusy registers are thus read each time a packet is received. Instead, shuffle out the true per-packet processing which is needed and move the rest of the ANI processing into a periodic event which runs every 100ms by default.
2011-01-21 05:21:00 +00:00
static int ath_anicalinterval = 100; /* ANI calibration - 100 msec */
SYSCTL_INT(_hw_ath, OID_AUTO, anical, CTLFLAG_RW, &ath_anicalinterval,
0, "ANI calibration (msecs)");
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
Further preparations for the RX EDMA support. Break out the DMA descriptor setup/teardown code into a method. The EDMA RX code doesn't allocate descriptors, just ath_buf entries.
2012-07-09 08:37:59 +00:00
int ath_rxbuf = ATH_RXBUF; /* # rx buffers to allocate */
Pull in r267961 and r267973 again. Fix for issues reported will follow.
2014-06-28 03:56:17 +00:00
SYSCTL_INT(_hw_ath, OID_AUTO, rxbuf, CTLFLAG_RWTUN, &ath_rxbuf,
allow the size of tx+rx buffer pools to be tuned MFC after: 2 weeks
2006-02-09 21:03:25 +00:00
0, "rx buffers allocated");
Further preparations for the RX EDMA support. Break out the DMA descriptor setup/teardown code into a method. The EDMA RX code doesn't allocate descriptors, just ath_buf entries.
2012-07-09 08:37:59 +00:00
int ath_txbuf = ATH_TXBUF; /* # tx buffers to allocate */
Pull in r267961 and r267973 again. Fix for issues reported will follow.
2014-06-28 03:56:17 +00:00
SYSCTL_INT(_hw_ath, OID_AUTO, txbuf, CTLFLAG_RWTUN, &ath_txbuf,
allow the size of tx+rx buffer pools to be tuned MFC after: 2 weeks
2006-02-09 21:03:25 +00:00
0, "tx buffers allocated");
Further preparations for the RX EDMA support. Break out the DMA descriptor setup/teardown code into a method. The EDMA RX code doesn't allocate descriptors, just ath_buf entries.
2012-07-09 08:37:59 +00:00
int ath_txbuf_mgmt = ATH_MGMT_TXBUF; /* # mgmt tx buffers to allocate */
Pull in r267961 and r267973 again. Fix for issues reported will follow.
2014-06-28 03:56:17 +00:00
SYSCTL_INT(_hw_ath, OID_AUTO, txbuf_mgmt, CTLFLAG_RWTUN, &ath_txbuf_mgmt,
Implement a separate, smaller pool of ath_buf entries for use by management traffic. * Create sc_mgmt_txbuf and sc_mgmt_txdesc, initialise/free them appropriately. * Create an enum to represent buffer types in the API. * Extend ath_getbuf() and _ath_getbuf_locked() to take the above enum. * Right now anything sent via ic_raw_xmit() allocates via ATH_BUFTYPE_MGMT. This may not be very useful. * Add ATH_BUF_MGMT flag (ath_buf.bf_flags) which indicates the current buffer is a mgmt buffer and should go back onto the mgmt free list. * Extend 'txagg' to include debugging output for both normal and mgmt txbufs. * When checking/clearing ATH_BUF_BUSY, do it on both TX pools. Tested: * STA mode, with heavy UDP injection via iperf. This filled the TX queue however BARs were still going out successfully. TODO: * Initialise the mgmt buffers with ATH_BUF_MGMT and then ensure the right type is being allocated and freed on the appropriate list. That'd save a write operation (to bf->bf_flags) on each buffer alloc/free. * Test on AP mode, ensure that BAR TX and probe responses go out nicely when the main TX queue is filled (eg with paused traffic to a TID, awaiting a BAR to complete.) PR: kern/168170
2012-06-13 06:57:55 +00:00
0, "tx (mgmt) buffers allocated");
allow the size of tx+rx buffer pools to be tuned MFC after: 2 weeks
2006-02-09 21:03:25 +00:00
Migrate the TDMA management functions out of if_ath.c into if_ath_tdma.c. There's some TX path TDMA code in if_ath_tx.c which should be migrated out, but first I should likely try and verify/fix/repair the TDMA support in 9.x and -HEAD.
2012-05-20 02:49:42 +00:00
int ath_bstuck_threshold = 4; /* max missed beacons */
add hw.ath.bstuck to control the stuck beacon threshold
2009-02-10 19:26:42 +00:00
SYSCTL_INT(_hw_ath, OID_AUTO, bstuck, CTLFLAG_RW, &ath_bstuck_threshold,
0, "max missed beacon xmits before chip reset");
Migrate the STAILQ lists to TAILQs. A bunch of the 11n TX aggregation logic wants to traverse lists of buffers in various ways. In order to provide O(1) behaviour in this instance, use TAILQs. This does blow out the memory footprint and CPU cycles slightly for some of these operations. I may convert some of these back to STAILQs once the rest of the software transmit queue handling has been stabilised. Sponsored by: Hobnob, Inc.
2011-11-08 17:08:12 +00:00
MALLOC_DEFINE(M_ATHDEV, "athdev", "ath driver dma buffers");
Update with last year of work.
2004-12-08 17:34:36 +00:00
Migrate some more TX side setup routines to be methods.
2012-07-31 03:09:48 +00:00
void
ath_legacy_attach_comp_func(struct ath_softc *sc)
{
/*
* Special case certain configurations. Note the
* CAB queue is handled by these specially so don't
* include them when checking the txq setup mask.
*/
switch (sc->sc_txqsetup &~ (1<<sc->sc_cabq->axq_qnum)) {
case 0x01:
TASK_INIT(&sc->sc_txtask, 0, ath_tx_proc_q0, sc);
break;
case 0x0f:
TASK_INIT(&sc->sc_txtask, 0, ath_tx_proc_q0123, sc);
break;
default:
TASK_INIT(&sc->sc_txtask, 0, ath_tx_proc, sc);
break;
}
}
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
/*
* Set the target power mode.
*
* If this is called during a point in time where
* the hardware is being programmed elsewhere, it will
* simply store it away and update it when all current
* uses of the hardware are completed.
[ath] force wake the hardware if we see a missed beacon. This adds a workaround to incorrectly behaving APs (ie, FreeBSD APs) which don't beacon out exactly when they should (at TBTT multiples of beacon intervals.) It forces the hardware awake (but leaves it in network-sleep so self generated frames still state that the hardware is asleep!) and will remain awake until the next sleep transition driven by net80211. That way if the beacons are just at the wrong interval, we get a much better chance of hearing more consecutive beacons before we go to sleep, thus not constantly disconnecting. Tested: * AR9485, STA mode, against a misbehaving FreeBSD AP.
2016-11-28 17:54:29 +00:00
*
* If the chip is going into network sleep or power off, then
* we will wait until all uses of the chip are done before
* going into network sleep or power off.
*
* If the chip is being programmed full-awake, then immediately
* program it full-awake so we can actually stay awake rather than
* the chip potentially going to sleep underneath us.
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
*/
void
[ath] force wake the hardware if we see a missed beacon. This adds a workaround to incorrectly behaving APs (ie, FreeBSD APs) which don't beacon out exactly when they should (at TBTT multiples of beacon intervals.) It forces the hardware awake (but leaves it in network-sleep so self generated frames still state that the hardware is asleep!) and will remain awake until the next sleep transition driven by net80211. That way if the beacons are just at the wrong interval, we get a much better chance of hearing more consecutive beacons before we go to sleep, thus not constantly disconnecting. Tested: * AR9485, STA mode, against a misbehaving FreeBSD AP.
2016-11-28 17:54:29 +00:00
_ath_power_setpower(struct ath_softc *sc, int power_state, int selfgen,
const char *file, int line)
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
{
ATH_LOCK_ASSERT(sc);
[ath] force wake the hardware if we see a missed beacon. This adds a workaround to incorrectly behaving APs (ie, FreeBSD APs) which don't beacon out exactly when they should (at TBTT multiples of beacon intervals.) It forces the hardware awake (but leaves it in network-sleep so self generated frames still state that the hardware is asleep!) and will remain awake until the next sleep transition driven by net80211. That way if the beacons are just at the wrong interval, we get a much better chance of hearing more consecutive beacons before we go to sleep, thus not constantly disconnecting. Tested: * AR9485, STA mode, against a misbehaving FreeBSD AP.
2016-11-28 17:54:29 +00:00
DPRINTF(sc, ATH_DEBUG_PWRSAVE, "%s: (%s:%d) state=%d, refcnt=%d, target=%d, cur=%d\n",
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
__func__,
file,
line,
power_state,
[ath] force wake the hardware if we see a missed beacon. This adds a workaround to incorrectly behaving APs (ie, FreeBSD APs) which don't beacon out exactly when they should (at TBTT multiples of beacon intervals.) It forces the hardware awake (but leaves it in network-sleep so self generated frames still state that the hardware is asleep!) and will remain awake until the next sleep transition driven by net80211. That way if the beacons are just at the wrong interval, we get a much better chance of hearing more consecutive beacons before we go to sleep, thus not constantly disconnecting. Tested: * AR9485, STA mode, against a misbehaving FreeBSD AP.
2016-11-28 17:54:29 +00:00
sc->sc_powersave_refcnt,
sc->sc_target_powerstate,
sc->sc_cur_powerstate);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
[ath] force wake the hardware if we see a missed beacon. This adds a workaround to incorrectly behaving APs (ie, FreeBSD APs) which don't beacon out exactly when they should (at TBTT multiples of beacon intervals.) It forces the hardware awake (but leaves it in network-sleep so self generated frames still state that the hardware is asleep!) and will remain awake until the next sleep transition driven by net80211. That way if the beacons are just at the wrong interval, we get a much better chance of hearing more consecutive beacons before we go to sleep, thus not constantly disconnecting. Tested: * AR9485, STA mode, against a misbehaving FreeBSD AP.
2016-11-28 17:54:29 +00:00
sc->sc_target_powerstate = power_state;
/*
* Don't program the chip into network sleep if the chip
* is being programmed elsewhere.
*
* However, if the chip is being programmed /awake/, force
* the chip awake so we stay awake.
*/
if ((sc->sc_powersave_refcnt == 0 || power_state == HAL_PM_AWAKE) &&
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
power_state != sc->sc_cur_powerstate) {
sc->sc_cur_powerstate = power_state;
ath_hal_setpower(sc->sc_ah, power_state);
Add tracking for self-generated frames when the VAP is in sleep state. The hardware can generate its own frames (eg RTS/CTS exchanges, other kinds of 802.11 management stuff, especially when it comes to 802.11n) and these also have PWRMGT flags. So if the VAP is asleep but the NIC is in force-awake for some reason, ensure that the self-generated frames have PWRMGT set to 1. Now, this (like basically everything to do with powersave) is still racy - the only way to guarantee that it's all actually consistent is to pause transmit and let it finish before transitioning the VAP to sleep, but this at least gets the basic method of tracking and updating the state debugged. Tested: * AR5416, STA mode * AR9380, STA mode
2014-05-02 00:48:09 +00:00
/*
* If the NIC is force-awake, then set the
* self-gen frame state appropriately.
*
* If the nic is in network sleep or full-sleep,
* we let the above call leave the self-gen
* state as "sleep".
*/
[ath] force wake the hardware if we see a missed beacon. This adds a workaround to incorrectly behaving APs (ie, FreeBSD APs) which don't beacon out exactly when they should (at TBTT multiples of beacon intervals.) It forces the hardware awake (but leaves it in network-sleep so self generated frames still state that the hardware is asleep!) and will remain awake until the next sleep transition driven by net80211. That way if the beacons are just at the wrong interval, we get a much better chance of hearing more consecutive beacons before we go to sleep, thus not constantly disconnecting. Tested: * AR9485, STA mode, against a misbehaving FreeBSD AP.
2016-11-28 17:54:29 +00:00
if (selfgen &&
sc->sc_cur_powerstate == HAL_PM_AWAKE &&
Add tracking for self-generated frames when the VAP is in sleep state. The hardware can generate its own frames (eg RTS/CTS exchanges, other kinds of 802.11 management stuff, especially when it comes to 802.11n) and these also have PWRMGT flags. So if the VAP is asleep but the NIC is in force-awake for some reason, ensure that the self-generated frames have PWRMGT set to 1. Now, this (like basically everything to do with powersave) is still racy - the only way to guarantee that it's all actually consistent is to pause transmit and let it finish before transitioning the VAP to sleep, but this at least gets the basic method of tracking and updating the state debugged. Tested: * AR5416, STA mode * AR9380, STA mode
2014-05-02 00:48:09 +00:00
sc->sc_target_selfgen_state != HAL_PM_AWAKE) {
ath_hal_setselfgenpower(sc->sc_ah,
sc->sc_target_selfgen_state);
}
}
}
/*
* Set the current self-generated frames state.
*
* This is separate from the target power mode. The chip may be
* awake but the desired state is "sleep", so frames sent to the
* destination has PWRMGT=1 in the 802.11 header. The NIC also
* needs to know to set PWRMGT=1 in self-generated frames.
*/
void
_ath_power_set_selfgen(struct ath_softc *sc, int power_state, const char *file, int line)
{
ATH_LOCK_ASSERT(sc);
DPRINTF(sc, ATH_DEBUG_PWRSAVE, "%s: (%s:%d) state=%d, refcnt=%d\n",
__func__,
file,
line,
power_state,
sc->sc_target_selfgen_state);
sc->sc_target_selfgen_state = power_state;
/*
* If the NIC is force-awake, then set the power state.
* Network-state and full-sleep will already transition it to
* mark self-gen frames as sleeping - and we can't
* guarantee the NIC is awake to program the self-gen frame
* setting anyway.
*/
if (sc->sc_cur_powerstate == HAL_PM_AWAKE) {
ath_hal_setselfgenpower(sc->sc_ah, power_state);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
}
}
/*
* Set the hardware power mode and take a reference.
*
* This doesn't update the target power mode in the driver;
* it just updates the hardware power state.
*
* XXX it should only ever force the hardware awake; it should
* never be called to set it asleep.
*/
void
_ath_power_set_power_state(struct ath_softc *sc, int power_state, const char *file, int line)
{
ATH_LOCK_ASSERT(sc);
DPRINTF(sc, ATH_DEBUG_PWRSAVE, "%s: (%s:%d) state=%d, refcnt=%d\n",
__func__,
file,
line,
power_state,
sc->sc_powersave_refcnt);
sc->sc_powersave_refcnt++;
[ath] force wake the hardware if we see a missed beacon. This adds a workaround to incorrectly behaving APs (ie, FreeBSD APs) which don't beacon out exactly when they should (at TBTT multiples of beacon intervals.) It forces the hardware awake (but leaves it in network-sleep so self generated frames still state that the hardware is asleep!) and will remain awake until the next sleep transition driven by net80211. That way if the beacons are just at the wrong interval, we get a much better chance of hearing more consecutive beacons before we go to sleep, thus not constantly disconnecting. Tested: * AR9485, STA mode, against a misbehaving FreeBSD AP.
2016-11-28 17:54:29 +00:00
/*
* Only do the power state change if we're not programming
* it elsewhere.
*/
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
if (power_state != sc->sc_cur_powerstate) {
ath_hal_setpower(sc->sc_ah, power_state);
sc->sc_cur_powerstate = power_state;
Add tracking for self-generated frames when the VAP is in sleep state. The hardware can generate its own frames (eg RTS/CTS exchanges, other kinds of 802.11 management stuff, especially when it comes to 802.11n) and these also have PWRMGT flags. So if the VAP is asleep but the NIC is in force-awake for some reason, ensure that the self-generated frames have PWRMGT set to 1. Now, this (like basically everything to do with powersave) is still racy - the only way to guarantee that it's all actually consistent is to pause transmit and let it finish before transitioning the VAP to sleep, but this at least gets the basic method of tracking and updating the state debugged. Tested: * AR5416, STA mode * AR9380, STA mode
2014-05-02 00:48:09 +00:00
/*
* Adjust the self-gen powerstate if appropriate.
*/
if (sc->sc_cur_powerstate == HAL_PM_AWAKE &&
sc->sc_target_selfgen_state != HAL_PM_AWAKE) {
ath_hal_setselfgenpower(sc->sc_ah,
sc->sc_target_selfgen_state);
}
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
}
}
/*
* Restore the power save mode to what it once was.
*
* This will decrement the reference counter and once it hits
* zero, it'll restore the powersave state.
*/
void
_ath_power_restore_power_state(struct ath_softc *sc, const char *file, int line)
{
ATH_LOCK_ASSERT(sc);
DPRINTF(sc, ATH_DEBUG_PWRSAVE, "%s: (%s:%d) refcnt=%d, target state=%d\n",
__func__,
file,
line,
sc->sc_powersave_refcnt,
sc->sc_target_powerstate);
if (sc->sc_powersave_refcnt == 0)
device_printf(sc->sc_dev, "%s: refcnt=0?\n", __func__);
else
sc->sc_powersave_refcnt--;
if (sc->sc_powersave_refcnt == 0 &&
sc->sc_target_powerstate != sc->sc_cur_powerstate) {
sc->sc_cur_powerstate = sc->sc_target_powerstate;
ath_hal_setpower(sc->sc_ah, sc->sc_target_powerstate);
}
Add tracking for self-generated frames when the VAP is in sleep state. The hardware can generate its own frames (eg RTS/CTS exchanges, other kinds of 802.11 management stuff, especially when it comes to 802.11n) and these also have PWRMGT flags. So if the VAP is asleep but the NIC is in force-awake for some reason, ensure that the self-generated frames have PWRMGT set to 1. Now, this (like basically everything to do with powersave) is still racy - the only way to guarantee that it's all actually consistent is to pause transmit and let it finish before transitioning the VAP to sleep, but this at least gets the basic method of tracking and updating the state debugged. Tested: * AR5416, STA mode * AR9380, STA mode
2014-05-02 00:48:09 +00:00
/*
* Adjust the self-gen powerstate if appropriate.
*/
if (sc->sc_cur_powerstate == HAL_PM_AWAKE &&
sc->sc_target_selfgen_state != HAL_PM_AWAKE) {
ath_hal_setselfgenpower(sc->sc_ah,
sc->sc_target_selfgen_state);
}
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
}
Add initial support for the AR9485 CUS198 / CUS230 variants. These variants have a few differences from the default AR9485 NIC, namely: * a non-default antenna switch config; * slightly different RX gain table setup; * an external XLNA hooked up to a GPIO pin; * (and not yet done) RSSI threshold differences when doing slow diversity. To make this possible: * Add the PCI device list from Linux ath9k, complete with vendor and sub-vendor IDs for various things to be enabled; * .. and until FreeBSD learns about a PCI device list like this, write a search function inspired by the USB device enumeration code; * add HAL_OPS_CONFIG to the HAL attach methods; the HAL can use this to initialise its local driver parameters upon attach; * copy these parameters over in the AR9300 HAL; * don't default to override the antenna switch - only do it for the chips that require it; * I brought over ar9300_attenuation_apply() from ath9k which is cleaner and easier to read for this particular NIC. This is a work in progress. I'm worried that there's some post-AR9380 NIC out there which doesn't work without the antenna override set as I currently haven't implemented bluetooth coexistence for the AR9380 and later HAL. But I'd rather have this code in the tree and fix it up before 11.0-RELEASE happens versus having a set of newer NICs in laptops be effectively RX deaf. Tested: * AR9380 (STA) * AR9485 CUS198 (STA) Obtained from: Qualcomm Atheros, Linux ath9k
2014-09-30 03:19:29 +00:00
/*
* Configure the initial HAL configuration values based on bus
* specific parameters.
*
* Some PCI IDs and other information may need tweaking.
*
* XXX TODO: ath9k and the Atheros HAL only program comm2g_switch_enable
* if BT antenna diversity isn't enabled.
*
* So, let's also figure out how to enable BT diversity for AR9485.
*/
static void
ath_setup_hal_config(struct ath_softc *sc, HAL_OPS_CONFIG *ah_config)
{
/* XXX TODO: only for PCI devices? */
if (sc->sc_pci_devinfo & (ATH_PCI_CUS198 | ATH_PCI_CUS230)) {
ah_config->ath_hal_ext_lna_ctl_gpio = 0x200; /* bit 9 */
ah_config->ath_hal_ext_atten_margin_cfg = AH_TRUE;
ah_config->ath_hal_min_gainidx = AH_TRUE;
ah_config->ath_hal_ant_ctrl_comm2g_switch_enable = 0x000bbb88;
/* XXX low_rssi_thresh */
/* XXX fast_div_bias */
device_printf(sc->sc_dev, "configuring for %s\n",
(sc->sc_pci_devinfo & ATH_PCI_CUS198) ?
"CUS198" : "CUS230");
}
if (sc->sc_pci_devinfo & ATH_PCI_CUS217)
device_printf(sc->sc_dev, "CUS217 card detected\n");
if (sc->sc_pci_devinfo & ATH_PCI_CUS252)
device_printf(sc->sc_dev, "CUS252 card detected\n");
if (sc->sc_pci_devinfo & ATH_PCI_AR9565_1ANT)
device_printf(sc->sc_dev, "WB335 1-ANT card detected\n");
if (sc->sc_pci_devinfo & ATH_PCI_AR9565_2ANT)
device_printf(sc->sc_dev, "WB335 2-ANT card detected\n");
[ath] commit initial bluetooth coexistence support for the MCI NICs. This is the initial framework to call into the MCI HAL routines and drive the basic state engine. The MCI bluetooth coex model uses a command channel between wlan and bluetooth, rather than a 2-wire or 3-wire signaling protocol to control things. This means the wlan and bluetooth chip exchange a lot more information and signaling, even at the per-packet level. The NICs in question can share the input LNA and output PA on the die, so they absolutely can't stomp on each other in a silly fashion. It also allows for the bluetooth side to signal when profiles come and go, so the driver can take appropriate control. There's also the possibility of dynamic bluetooth/wlan duty cycle control which I haven't yet really played with. It configures things up with a static "wlan wins everything" coexistence, configures up the available 2GHz channel map for bluetooth, sets a static duty cycle for bluetooth/wifi traffic priority and drives the basics needed to keep the MCI HAL code happy. It doesn't do any actual coexistence except to default to "wlan wins everything", which at least demonstrates that things do indeed work. Bluetooth inquiry frames still trump wifi (including beacons), so that demonstrates things really do indeed seem to work. Tested: * AR9462 (WB222), STA mode + bt * QCA9565 (WB335), STA mode + bt TODO: * .. the rest of coexistence. yes, bluetooth, not people. That stuff's hard. * It doesn't do the initial BT side calibration, which requires a WLAN chip reset. I'll fix up the reset path a bit more first before I enable that. * The 1-ant and 2-ant configuration bits aren't being set correctly in if_ath_btcoex.c - I'll dig into that and fix it in a subsequent commit. * It's not enabled by default for WB222/WB225 even though I believe it now can be - I'll chase that up in a subsequent commit. Obtained from: Qualcomm Atheros, Linux ath9k
2016-06-02 00:51:36 +00:00
if (sc->sc_pci_devinfo & ATH_PCI_BT_ANT_DIV)
device_printf(sc->sc_dev,
"Bluetooth Antenna Diversity card detected\n");
Add initial support for the AR9485 CUS198 / CUS230 variants. These variants have a few differences from the default AR9485 NIC, namely: * a non-default antenna switch config; * slightly different RX gain table setup; * an external XLNA hooked up to a GPIO pin; * (and not yet done) RSSI threshold differences when doing slow diversity. To make this possible: * Add the PCI device list from Linux ath9k, complete with vendor and sub-vendor IDs for various things to be enabled; * .. and until FreeBSD learns about a PCI device list like this, write a search function inspired by the USB device enumeration code; * add HAL_OPS_CONFIG to the HAL attach methods; the HAL can use this to initialise its local driver parameters upon attach; * copy these parameters over in the AR9300 HAL; * don't default to override the antenna switch - only do it for the chips that require it; * I brought over ar9300_attenuation_apply() from ath9k which is cleaner and easier to read for this particular NIC. This is a work in progress. I'm worried that there's some post-AR9380 NIC out there which doesn't work without the antenna override set as I currently haven't implemented bluetooth coexistence for the AR9380 and later HAL. But I'd rather have this code in the tree and fix it up before 11.0-RELEASE happens versus having a set of newer NICs in laptops be effectively RX deaf. Tested: * AR9380 (STA) * AR9485 CUS198 (STA) Obtained from: Qualcomm Atheros, Linux ath9k
2014-09-30 03:19:29 +00:00
if (sc->sc_pci_devinfo & ATH_PCI_KILLER)
device_printf(sc->sc_dev, "Killer Wireless card detected\n");
#if 0
/*
* Some WB335 cards do not support antenna diversity. Since
* we use a hardcoded value for AR9565 instead of using the
* EEPROM/OTP data, remove the combining feature from
* the HW capabilities bitmap.
*/
if (sc->sc_pci_devinfo & (ATH9K_PCI_AR9565_1ANT | ATH9K_PCI_AR9565_2ANT)) {
if (!(sc->sc_pci_devinfo & ATH9K_PCI_BT_ANT_DIV))
pCap->hw_caps &= ~ATH9K_HW_CAP_ANT_DIV_COMB;
}
if (sc->sc_pci_devinfo & ATH9K_PCI_BT_ANT_DIV) {
pCap->hw_caps |= ATH9K_HW_CAP_BT_ANT_DIV;
device_printf(sc->sc_dev, "Set BT/WLAN RX diversity capability\n");
}
#endif
if (sc->sc_pci_devinfo & ATH_PCI_D3_L1_WAR) {
ah_config->ath_hal_pcie_waen = 0x0040473b;
device_printf(sc->sc_dev, "Enable WAR for ASPM D3/L1\n");
}
#if 0
if (sc->sc_pci_devinfo & ATH9K_PCI_NO_PLL_PWRSAVE) {
ah->config.no_pll_pwrsave = true;
device_printf(sc->sc_dev, "Disable PLL PowerSave\n");
}
#endif
}
Update if_ath(4) to check for "hint.ath.X.macaddr" for an override MAC address. This is used by the AR71xx platform code to choose a local MAC based on the "board MAC address", versus whatever potentially invalid/garbage values are stored in the Atheros calibration data.
2015-03-28 23:41:23 +00:00
/*
* Attempt to fetch the MAC address from the kernel environment.
*
* Returns 0, macaddr in macaddr if successful; -1 otherwise.
*/
static int
ath_fetch_mac_kenv(struct ath_softc *sc, uint8_t *macaddr)
{
char devid_str[32];
int local_mac = 0;
char *local_macstr;
/*
* Fetch from the kenv rather than using hints.
*
* Hints would be nice but the transition to dynamic
* hints/kenv doesn't happen early enough for this
* to work reliably (eg on anything embedded.)
*/
snprintf(devid_str, 32, "hint.%s.%d.macaddr",
device_get_name(sc->sc_dev),
device_get_unit(sc->sc_dev));
if ((local_macstr = kern_getenv(devid_str)) != NULL) {
uint32_t tmpmac[ETHER_ADDR_LEN];
int count;
int i;
/* Have a MAC address; should use it */
device_printf(sc->sc_dev,
"Overriding MAC address from environment: '%s'\n",
local_macstr);
/* Extract out the MAC address */
count = sscanf(local_macstr, "%x%*c%x%*c%x%*c%x%*c%x%*c%x",
&tmpmac[0], &tmpmac[1],
&tmpmac[2], &tmpmac[3],
&tmpmac[4], &tmpmac[5]);
if (count == 6) {
/* Valid! */
local_mac = 1;
for (i = 0; i < ETHER_ADDR_LEN; i++)
macaddr[i] = tmpmac[i];
}
/* Done! */
freeenv(local_macstr);
local_macstr = NULL;
}
if (local_mac)
return (0);
return (-1);
}
Add in the (very!) optional glue to flip the 11n bits for if_ath. There's still a lot of random issues to sort out with the radio side of things and AMPDU RX handling (and completely missing AMPDU TX handling!) but if people wish to give this a go and assist in debugging the issues, they can define ATH_DO_11N to enable it. I'm just re-iterating - this is here to allow people to assist in further 11n development; it is not any indication that the 11n support is complete and functional. Important notes: * This doesn't support 1-stream cards yet - (eg AR9285) - the various bits that negotiate TX/RX MCS don't know not to try >1 stream TX or negotiate 1-stream RX; so don't enable 11n unless you've first taught the rate control module and the net80211 stack to negotiate 1-stream stuff; * The only rate control module minimally 11n aware is ath_rate_sample; * ath_rate_sample doesn't know about HT/40; so airtime will be incorrectly calculated; * The AR9160 and AR9280 radio code is unreliable at the higher MCS rates for some reason; this will definitely impact 11n performance; * AMPDU-TX isn't yet implemented; * AMPDU-RX may be a bit buggy still and will definitely suffer from the radio unreliability mentioned above (ie, don't expect 150/300mbit RX just yet.)
2011-02-09 15:43:38 +00:00
#define HAL_MODE_HT20 (HAL_MODE_11NG_HT20 | HAL_MODE_11NA_HT20)
#define HAL_MODE_HT40 \
(HAL_MODE_11NG_HT40PLUS | HAL_MODE_11NG_HT40MINUS | \
HAL_MODE_11NA_HT40PLUS | HAL_MODE_11NA_HT40MINUS)
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
int
ath_attach(u_int16_t devid, struct ath_softc *sc)
{
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
struct ieee80211com *ic = &sc->sc_ic;
Stop embedding struct ifnet at the top of driver softcs. Instead the struct ifnet or the layer 2 common structure it was embedded in have been replaced with a struct ifnet pointer to be filled by a call to the new function, if_alloc(). The layer 2 common structure is also allocated via if_alloc() based on the interface type. It is hung off the new struct ifnet member, if_l2com. This change removes the size of these structures from the kernel ABI and will allow us to better manage them as interfaces come and go. Other changes of note: - Struct arpcom is no longer referenced in normal interface code. Instead the Ethernet address is accessed via the IFP2ENADDR() macro. To enforce this ac_enaddr has been renamed to _ac_enaddr. - The second argument to ether_ifattach is now always the mac address from driver private storage rather than sometimes being ac_enaddr. Reviewed by: sobomax, sam
2005-06-10 16:49:24 +00:00
struct ath_hal *ah = NULL;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
HAL_STATUS status;
Update with last year of work.
2004-12-08 17:34:36 +00:00
int error = 0, i;
prepare for a new hal
2008-10-27 18:30:33 +00:00
u_int wmodes;
Add in a new driver feature to allow the TX and RX chainmask to be overridden at attach time. Some 802.11n NICs may only have one physical antenna connected. The radios will be very upset if you try enabling radios which aren't connected to antennas. This allows hints to override the TX and RX chainmask. These hints are: hint.ath.X.rx_chainmask hint.ath.X.tx_chainmask They can be set at either boot time or in kenv before the module is loaded. This and the previous HAL commit were sponsored in late 2011 by Hobnob, Inc. Sponsored by: Hobnob, Inc.
2012-02-10 10:01:09 +00:00
int rx_chainmask, tx_chainmask;
Add initial support for the AR9485 CUS198 / CUS230 variants. These variants have a few differences from the default AR9485 NIC, namely: * a non-default antenna switch config; * slightly different RX gain table setup; * an external XLNA hooked up to a GPIO pin; * (and not yet done) RSSI threshold differences when doing slow diversity. To make this possible: * Add the PCI device list from Linux ath9k, complete with vendor and sub-vendor IDs for various things to be enabled; * .. and until FreeBSD learns about a PCI device list like this, write a search function inspired by the USB device enumeration code; * add HAL_OPS_CONFIG to the HAL attach methods; the HAL can use this to initialise its local driver parameters upon attach; * copy these parameters over in the AR9300 HAL; * don't default to override the antenna switch - only do it for the chips that require it; * I brought over ar9300_attenuation_apply() from ath9k which is cleaner and easier to read for this particular NIC. This is a work in progress. I'm worried that there's some post-AR9380 NIC out there which doesn't work without the antenna override set as I currently haven't implemented bluetooth coexistence for the AR9380 and later HAL. But I'd rather have this code in the tree and fix it up before 11.0-RELEASE happens versus having a set of newer NICs in laptops be effectively RX deaf. Tested: * AR9380 (STA) * AR9485 CUS198 (STA) Obtained from: Qualcomm Atheros, Linux ath9k
2014-09-30 03:19:29 +00:00
HAL_OPS_CONFIG ah_config;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
Update with last year of work.
2004-12-08 17:34:36 +00:00
DPRINTF(sc, ATH_DEBUG_ANY, "%s: devid 0x%x\n", __func__, devid);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
Set ic_softc in all 802.11 drivers. Not required right now, but will be used quite soon. Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-05-25 18:50:26 +00:00
ic->ic_softc = sc;
Make net80211 drivers supply their device name to the net80211 layer, so that the latter doesn't need to go through struct ifnet to get their name. Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-05-25 13:51:13 +00:00
ic->ic_name = device_get_nameunit(sc->sc_dev);
Stop embedding struct ifnet at the top of driver softcs. Instead the struct ifnet or the layer 2 common structure it was embedded in have been replaced with a struct ifnet pointer to be filled by a call to the new function, if_alloc(). The layer 2 common structure is also allocated via if_alloc() based on the interface type. It is hung off the new struct ifnet member, if_l2com. This change removes the size of these structures from the kernel ABI and will allow us to better manage them as interfaces come and go. Other changes of note: - Struct arpcom is no longer referenced in normal interface code. Instead the Ethernet address is accessed via the IFP2ENADDR() macro. To enforce this ac_enaddr has been renamed to _ac_enaddr. - The second argument to ether_ifattach is now always the mac address from driver private storage rather than sometimes being ac_enaddr. Reviewed by: sobomax, sam
2005-06-10 16:49:24 +00:00
Add initial support for the AR9485 CUS198 / CUS230 variants. These variants have a few differences from the default AR9485 NIC, namely: * a non-default antenna switch config; * slightly different RX gain table setup; * an external XLNA hooked up to a GPIO pin; * (and not yet done) RSSI threshold differences when doing slow diversity. To make this possible: * Add the PCI device list from Linux ath9k, complete with vendor and sub-vendor IDs for various things to be enabled; * .. and until FreeBSD learns about a PCI device list like this, write a search function inspired by the USB device enumeration code; * add HAL_OPS_CONFIG to the HAL attach methods; the HAL can use this to initialise its local driver parameters upon attach; * copy these parameters over in the AR9300 HAL; * don't default to override the antenna switch - only do it for the chips that require it; * I brought over ar9300_attenuation_apply() from ath9k which is cleaner and easier to read for this particular NIC. This is a work in progress. I'm worried that there's some post-AR9380 NIC out there which doesn't work without the antenna override set as I currently haven't implemented bluetooth coexistence for the AR9380 and later HAL. But I'd rather have this code in the tree and fix it up before 11.0-RELEASE happens versus having a set of newer NICs in laptops be effectively RX deaf. Tested: * AR9380 (STA) * AR9485 CUS198 (STA) Obtained from: Qualcomm Atheros, Linux ath9k
2014-09-30 03:19:29 +00:00
/*
* Configure the initial configuration data.
*
* This is stuff that may be needed early during attach
* rather than done via configuration calls later.
*/
bzero(&ah_config, sizeof(ah_config));
ath_setup_hal_config(sc, &ah_config);
Do a quick style(9) pass of some of the code introduced with 802.11n support.
2011-12-26 05:26:35 +00:00
ah = ath_hal_attach(devid, sc, sc->sc_st, sc->sc_sh,
Add initial support for the AR9485 CUS198 / CUS230 variants. These variants have a few differences from the default AR9485 NIC, namely: * a non-default antenna switch config; * slightly different RX gain table setup; * an external XLNA hooked up to a GPIO pin; * (and not yet done) RSSI threshold differences when doing slow diversity. To make this possible: * Add the PCI device list from Linux ath9k, complete with vendor and sub-vendor IDs for various things to be enabled; * .. and until FreeBSD learns about a PCI device list like this, write a search function inspired by the USB device enumeration code; * add HAL_OPS_CONFIG to the HAL attach methods; the HAL can use this to initialise its local driver parameters upon attach; * copy these parameters over in the AR9300 HAL; * don't default to override the antenna switch - only do it for the chips that require it; * I brought over ar9300_attenuation_apply() from ath9k which is cleaner and easier to read for this particular NIC. This is a work in progress. I'm worried that there's some post-AR9380 NIC out there which doesn't work without the antenna override set as I currently haven't implemented bluetooth coexistence for the AR9380 and later HAL. But I'd rather have this code in the tree and fix it up before 11.0-RELEASE happens versus having a set of newer NICs in laptops be effectively RX deaf. Tested: * AR9380 (STA) * AR9485 CUS198 (STA) Obtained from: Qualcomm Atheros, Linux ath9k
2014-09-30 03:19:29 +00:00
sc->sc_eepromdata, &ah_config, &status);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
if (ah == NULL) {
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
device_printf(sc->sc_dev,
"unable to attach hardware; HAL status %u\n", status);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
error = ENXIO;
goto bad;
}
sc->sc_ah = ah;
Close a race where ath_intr is installed and may be called before the HAL is setup: use sc_invalid to discard such entries into ath_intr. This can easily happen if the device is assigned a shared IRQ.
2003-08-13 21:29:35 +00:00
sc->sc_invalid = 0; /* ready to go, enable interrupt handling */
shuffle debug setup to simplify debugging events during attach
2008-10-27 17:19:39 +00:00
#ifdef ATH_DEBUG
sc->sc_debug = ath_debug;
#endif
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
[ath] fix "doing stuff before wakeup" warning; add comments for ACK/CTS handling during DFS/PASSIVE channels * Although the hardware is awake, the power state handling doesn't think so. So just explicitly wake it up early in setup so ath_hal calls don't complain. * We shouldn't be transmitting or ACKing frames during DFS CAC or on passive channels before we hear a beacon. So, start laying down comments in the places where this work has to be done. Note: * The main bit missing from finishing this particular bit of work is a state call to transition a VAP from passive to non-passive when a beacon is heard. CAC is easy, it's an interface state. So, I'll go and add a method to control that soon.
2017-01-27 01:17:00 +00:00
/*
* Force the chip awake during setup, just to keep
* the HAL/driver power tracking happy.
*
* There are some methods (eg ath_hal_setmac())
* that poke the hardware.
*/
ATH_LOCK(sc);
ath_power_setpower(sc, HAL_PM_AWAKE, 1);
ATH_UNLOCK(sc);
Begin abstracting out the RX path in preparation for RX EDMA support. The RX EDMA support requires a modified approach to the RX descriptor handling. Specifically: * There's now two RX queues - high and low priority; * The RX queues are implemented as FIFOs; they're now an array of pointers to buffers; * .. and the RX buffer and descriptor are in the same "buffer", rather than being separate. So to that end, this commit abstracts out most of the RX related functions from the bulk of the driver. Notably, the RX DMA/buffer allocation isn't updated, primarily because I haven't yet fleshed out what it should look like. Whilst I'm here, create a set of matching but mostly unimplemented EDMA stubs. Tested: * AR9280, station mode TODO: * Thorough AP and other mode testing for non-EDMA chips; * Figure out how to allocate RX buffers suitable for RX EDMA, including correctly setting the mbuf length to compensate for the RX descriptor and completion status area.
2012-07-03 06:59:12 +00:00
/*
* Setup the DMA/EDMA functions based on the current
* hardware support.
*
* This is required before the descriptors are allocated.
*/
Further preparations for the RX EDMA support. Break out the DMA descriptor setup/teardown code into a method. The EDMA RX code doesn't allocate descriptors, just ath_buf entries.
2012-07-09 08:37:59 +00:00
if (ath_hal_hasedma(sc->sc_ah)) {
sc->sc_isedma = 1;
Begin abstracting out the RX path in preparation for RX EDMA support. The RX EDMA support requires a modified approach to the RX descriptor handling. Specifically: * There's now two RX queues - high and low priority; * The RX queues are implemented as FIFOs; they're now an array of pointers to buffers; * .. and the RX buffer and descriptor are in the same "buffer", rather than being separate. So to that end, this commit abstracts out most of the RX related functions from the bulk of the driver. Notably, the RX DMA/buffer allocation isn't updated, primarily because I haven't yet fleshed out what it should look like. Whilst I'm here, create a set of matching but mostly unimplemented EDMA stubs. Tested: * AR9280, station mode TODO: * Thorough AP and other mode testing for non-EDMA chips; * Figure out how to allocate RX buffers suitable for RX EDMA, including correctly setting the mbuf length to compensate for the RX descriptor and completion status area.
2012-07-03 06:59:12 +00:00
ath_recv_setup_edma(sc);
Begin separating out the TX DMA setup in preparation for TX EDMA support. * Introduce TX DMA setup/teardown methods, mirroring what's done in the RX path. Although the TX DMA descriptor is setup via ath_desc_alloc() / ath_desc_free(), there TX status descriptor ring will be allocated in this path. * Remove some of the TX EDMA capability probing from the RX path and push it into the new TX EDMA path.
2012-07-23 03:52:18 +00:00
ath_xmit_setup_edma(sc);
} else {
Begin abstracting out the RX path in preparation for RX EDMA support. The RX EDMA support requires a modified approach to the RX descriptor handling. Specifically: * There's now two RX queues - high and low priority; * The RX queues are implemented as FIFOs; they're now an array of pointers to buffers; * .. and the RX buffer and descriptor are in the same "buffer", rather than being separate. So to that end, this commit abstracts out most of the RX related functions from the bulk of the driver. Notably, the RX DMA/buffer allocation isn't updated, primarily because I haven't yet fleshed out what it should look like. Whilst I'm here, create a set of matching but mostly unimplemented EDMA stubs. Tested: * AR9280, station mode TODO: * Thorough AP and other mode testing for non-EDMA chips; * Figure out how to allocate RX buffers suitable for RX EDMA, including correctly setting the mbuf length to compensate for the RX descriptor and completion status area.
2012-07-03 06:59:12 +00:00
ath_recv_setup_legacy(sc);
Begin separating out the TX DMA setup in preparation for TX EDMA support. * Introduce TX DMA setup/teardown methods, mirroring what's done in the RX path. Although the TX DMA descriptor is setup via ath_desc_alloc() / ath_desc_free(), there TX status descriptor ring will be allocated in this path. * Remove some of the TX EDMA capability probing from the RX path and push it into the new TX EDMA path.
2012-07-23 03:52:18 +00:00
ath_xmit_setup_legacy(sc);
}
Begin abstracting out the RX path in preparation for RX EDMA support. The RX EDMA support requires a modified approach to the RX descriptor handling. Specifically: * There's now two RX queues - high and low priority; * The RX queues are implemented as FIFOs; they're now an array of pointers to buffers; * .. and the RX buffer and descriptor are in the same "buffer", rather than being separate. So to that end, this commit abstracts out most of the RX related functions from the bulk of the driver. Notably, the RX DMA/buffer allocation isn't updated, primarily because I haven't yet fleshed out what it should look like. Whilst I'm here, create a set of matching but mostly unimplemented EDMA stubs. Tested: * AR9280, station mode TODO: * Thorough AP and other mode testing for non-EDMA chips; * Figure out how to allocate RX buffers suitable for RX EDMA, including correctly setting the mbuf length to compensate for the RX descriptor and completion status area.
2012-07-03 06:59:12 +00:00
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
if (ath_hal_hasmybeacon(sc->sc_ah)) {
sc->sc_do_mybeacon = 1;
}
Update with last year of work.
2004-12-08 17:34:36 +00:00
/*
* Check if the MAC has multi-rate retry support.
* We do this by trying to setup a fake extended
* descriptor. MAC's that don't have support will
* return false w/o doing anything. MAC's that do
* support it will return true w/o doing anything.
*/
sc->sc_mrretry = ath_hal_setupxtxdesc(ah, NULL, 0,0, 0,0, 0,0);
/*
* Check if the device has hardware counters for PHY
* errors. If so we need to enable the MIB interrupt
* so we can act on stat triggers.
*/
if (ath_hal_hwphycounters(ah))
sc->sc_needmib = 1;
/*
* Get the hardware key cache size.
*/
sc->sc_keymax = ath_hal_keycachesize(ah);
Misc keycache changes: o purge ath_initkeytable; it's not needed o add multicast key search support for supporting multiple group keys (disabled for now; requires updated hal) o create keycache entry for stations using open auth so they get h/w antenna management support o add keycache -> node mapping table; eliminates mac-based lookup in the net80211 layer
2005-06-06 16:39:21 +00:00
if (sc->sc_keymax > ATH_KEYMAX) {
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
device_printf(sc->sc_dev,
"Warning, using only %u of %u key cache slots\n",
ATH_KEYMAX, sc->sc_keymax);
Misc keycache changes: o purge ath_initkeytable; it's not needed o add multicast key search support for supporting multiple group keys (disabled for now; requires updated hal) o create keycache entry for stations using open auth so they get h/w antenna management support o add keycache -> node mapping table; eliminates mac-based lookup in the net80211 layer
2005-06-06 16:39:21 +00:00
sc->sc_keymax = ATH_KEYMAX;
Update with last year of work.
2004-12-08 17:34:36 +00:00
}
/*
* Reset the key cache since some parts do not
* reset the contents on initial power up.
*/
for (i = 0; i < sc->sc_keymax; i++)
ath_hal_keyreset(ah, i);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
/*
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
* Collect the default channel list.
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
*/
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
error = ath_getchannels(sc);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
if (error != 0)
goto bad;
/*
* Setup rate tables for all potential media types.
*/
ath_rate_setup(sc, IEEE80211_MODE_11A);
ath_rate_setup(sc, IEEE80211_MODE_11B);
ath_rate_setup(sc, IEEE80211_MODE_11G);
Update with last year of work.
2004-12-08 17:34:36 +00:00
ath_rate_setup(sc, IEEE80211_MODE_TURBO_A);
ath_rate_setup(sc, IEEE80211_MODE_TURBO_G);
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
ath_rate_setup(sc, IEEE80211_MODE_STURBO_A);
ath_rate_setup(sc, IEEE80211_MODE_11NA);
ath_rate_setup(sc, IEEE80211_MODE_11NG);
Add initial support for 900MHz cards like the Ubiquiti SR9: o eliminate assumptions that half/quarter rate channels on exist in 11a o handle frequency mapping between hal and net80211; hal gives us freq's in the range 2422..2437 that we remap MFC after: 1 month
2007-01-15 01:15:57 +00:00
ath_rate_setup(sc, IEEE80211_MODE_HALF);
ath_rate_setup(sc, IEEE80211_MODE_QUARTER);
Add half/quarter rate 11a channel support: o change handling of regdomain-related mib knobs so they can be set post-attach: regdomain, countrycode, outdoor, and xchanmode; the hal will not permit changing the regdomain but we expose it for now o on regdomain/countrycode change recalculate the channel list and push it to the net80211 layer (NB: looks to need more tweaking) o setup rate tables for half/quarter rate channels o honor half/quarter rate channel configs when changing channels o honor half/quarter rate channel configs when setting the slot time o use hack/nonstandard channel numbering scheme for the public safety band to avoid overlapping 2.4G channels on dual-band cards o remove setup of ic_sup_rates; the net80211 layer can do this for us and it simplifies handling of half/quarter rate channels Tested only in Public Safety Band with cards that have RF5112.
2006-12-27 19:07:09 +00:00
Update with last year of work.
2004-12-08 17:34:36 +00:00
/* NB: setup here so ath_rate_update is happy */
ath_setcurmode(sc, IEEE80211_MODE_11A);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
Update with last year of work.
2004-12-08 17:34:36 +00:00
/*
Begin separating out the TX DMA setup in preparation for TX EDMA support. * Introduce TX DMA setup/teardown methods, mirroring what's done in the RX path. Although the TX DMA descriptor is setup via ath_desc_alloc() / ath_desc_free(), there TX status descriptor ring will be allocated in this path. * Remove some of the TX EDMA capability probing from the RX path and push it into the new TX EDMA path.
2012-07-23 03:52:18 +00:00
* Allocate TX descriptors and populate the lists.
Update with last year of work.
2004-12-08 17:34:36 +00:00
*/
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
error = ath_desc_alloc(sc);
if (error != 0) {
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
device_printf(sc->sc_dev,
"failed to allocate TX descriptors: %d\n", error);
Begin separating out the TX DMA setup in preparation for TX EDMA support. * Introduce TX DMA setup/teardown methods, mirroring what's done in the RX path. Although the TX DMA descriptor is setup via ath_desc_alloc() / ath_desc_free(), there TX status descriptor ring will be allocated in this path. * Remove some of the TX EDMA capability probing from the RX path and push it into the new TX EDMA path.
2012-07-23 03:52:18 +00:00
goto bad;
}
error = ath_txdma_setup(sc);
if (error != 0) {
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
device_printf(sc->sc_dev,
"failed to allocate TX descriptors: %d\n", error);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
goto bad;
}
Further preparations for the RX EDMA support. Break out the DMA descriptor setup/teardown code into a method. The EDMA RX code doesn't allocate descriptors, just ath_buf entries.
2012-07-09 08:37:59 +00:00
Begin separating out the TX DMA setup in preparation for TX EDMA support. * Introduce TX DMA setup/teardown methods, mirroring what's done in the RX path. Although the TX DMA descriptor is setup via ath_desc_alloc() / ath_desc_free(), there TX status descriptor ring will be allocated in this path. * Remove some of the TX EDMA capability probing from the RX path and push it into the new TX EDMA path.
2012-07-23 03:52:18 +00:00
/*
* Allocate RX descriptors and populate the lists.
*/
Further preparations for the RX EDMA support. Break out the DMA descriptor setup/teardown code into a method. The EDMA RX code doesn't allocate descriptors, just ath_buf entries.
2012-07-09 08:37:59 +00:00
error = ath_rxdma_setup(sc);
if (error != 0) {
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
device_printf(sc->sc_dev,
"failed to allocate RX descriptors: %d\n", error);
Further preparations for the RX EDMA support. Break out the DMA descriptor setup/teardown code into a method. The EDMA RX code doesn't allocate descriptors, just ath_buf entries.
2012-07-09 08:37:59 +00:00
goto bad;
}
Convert the callouts back to using mutexes. I did this wrong - I should've included a state flag for each callout to see if it was supposed to run or not. I didn't do that. Instead, just use mutexes anyway. Suggested by: jhb
2014-11-15 01:18:49 +00:00
callout_init_mtx(&sc->sc_cal_ch, &sc->sc_mtx, 0);
callout_init_mtx(&sc->sc_wd_ch, &sc->sc_mtx, 0);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
o convert mutex calls to #defines for portability, etc. o destroy mutex's on detach (was missing)
2003-10-14 22:51:45 +00:00
ATH_TXBUF_LOCK_INIT(sc);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
use a private task queue thread MFC after: 2 weeks
2006-02-09 21:48:51 +00:00
sc->sc_tq = taskqueue_create("ath_taskq", M_NOWAIT,
taskqueue_thread_enqueue, &sc->sc_tq);
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
taskqueue_start_threads(&sc->sc_tq, 1, PI_NET, "%s taskq",
device_get_nameunit(sc->sc_dev));
use a private task queue thread MFC after: 2 weeks
2006-02-09 21:48:51 +00:00
Begin abstracting out the RX path in preparation for RX EDMA support. The RX EDMA support requires a modified approach to the RX descriptor handling. Specifically: * There's now two RX queues - high and low priority; * The RX queues are implemented as FIFOs; they're now an array of pointers to buffers; * .. and the RX buffer and descriptor are in the same "buffer", rather than being separate. So to that end, this commit abstracts out most of the RX related functions from the bulk of the driver. Notably, the RX DMA/buffer allocation isn't updated, primarily because I haven't yet fleshed out what it should look like. Whilst I'm here, create a set of matching but mostly unimplemented EDMA stubs. Tested: * AR9280, station mode TODO: * Thorough AP and other mode testing for non-EDMA chips; * Figure out how to allocate RX buffers suitable for RX EDMA, including correctly setting the mbuf length to compensate for the RX descriptor and completion status area.
2012-07-03 06:59:12 +00:00
TASK_INIT(&sc->sc_rxtask, 0, sc->sc_rx.recv_tasklet, sc);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
TASK_INIT(&sc->sc_bmisstask, 0, ath_bmiss_proc, sc);
Update for rev 0.9.16.16 hal: o add dfs+radar hooks; DFS is presently disabled in the hal o channel and mode handling changes o various api changes o be more aggressive about iq calibration settling so ap mode operation is better immediately after startup o rfkill/rfsilent sysctl support o tpc ack/cts sysctl support MFC after: 2 weeks
2006-02-10 19:07:08 +00:00
TASK_INIT(&sc->sc_bstucktask,0, ath_bstuck_proc, sc);
Attempt to further fix some of the concurrency/reset issues that occur. * ath_reset() is being called in softclock context, which may have the thing sleep on a lock. To avoid this, since we really _shouldn't_ be sleeping on any locks, break out the no-loss reset path into a tasklet and call that from: + ath_calibrate() + ath_watchdog() This has the added advantage that it'll end up also doing the frame RX cleanup from within the taskqueue context, rather than the softclock context. * Shuffle around the taskqueue_block() call to be before we grab the lock and disable interrupts. The trouble here is that taskqueue_block() doesn't block currently queued (but not yet running) tasks so calling it doesn't guarantee no further tasks (that weren't running on _A_ CPU at the time of this call) will complete. Calling taskqueue_drain() on these tasks won't work because if any _other_ thread calls taskqueue_enqueue() for whatever reason, everything gets very angry and stops working. This slightly changes the race condition enough to let ath_rx_tasklet() run before we try disabling it, and thus quietens the warnings a bit. The (more) true solution will be doing something like the following: * having a taskqueue_blocked mask in ath_softc; * having an interrupt_blocked mask in ath_softc; * only calling taskqueue_drain() on each individual task _after_ the lock has been acquired - that way no further tasklet scheduling is going to occur. * Then once the tasks have been blocked _and_ the interrupt has been disabled, call taskqueue_drain() on each, ensuring that anything that _was_ scheduled or running is removed. The trouble is if something calls taskqueue_enqueue() on a task after taskqueue_blocked() has been called but BEFORE taskqueue_drain() has been called, ta_pending will be set to 1 and taskqueue_drain() will sit there stuck in msleep() until you hard-kill the machine. PR: kern/165382 PR: kern/165220
2012-02-25 19:12:54 +00:00
TASK_INIT(&sc->sc_resettask,0, ath_reset_proc, sc);
Implement frame (data) transmission using if_transmit(), rather than if_start(). This removes the overlapping data path TX from occuring, which solves quite a number of the potential TX queue races in ath(4). It doesn't fix the net80211 layer TX queue races and it doesn't fix the raw TX path yet, but it's an important step towards this. This hasn't dropped the TX performance in my testing; primarily because now the TX path can quickly queue frames and continue along processing. This involves a few rather deep changes: * Use the ath_buf as a queue placeholder for now, as we need to be able to support queuing a list of mbufs (ie, when transmitting fragments) and m_nextpkt can't be used here (because it's what is joining the fragments together) * if_transmit() now simply allocates the ath_buf and queues it to a driver TX staging queue. * TX is now moved into a taskqueue function. * The TX taskqueue function now dequeues and transmits frames. * Fragments are handled correctly here - as the current API passes the fragment list as one mbuf list (joined with m_nextpkt) through to the driver if_transmit(). * For the couple of places where ath_start() may be called (mostly from net80211 when starting the VAP up again), just reimplement it using the new enqueue and taskqueue methods. What I don't like (about this work and the TX code in general): * I'm using the same lock for the staging TX queue management and the actual TX. This isn't required; I'm just being slack. * I haven't yet moved TX to a separate taskqueue (but the taskqueue is created); it's easy enough to do this later if necessary. I just need to make sure it's a higher priority queue, so TX has the same behaviour as it used to (where it would preempt existing RX..) * I need to re-review the TX path a little more and make sure that ieee80211_node_*() functions aren't called within the TX lock. When queueing, I should just push failed frames into a queue and when I'm wrapping up the TX code, unlock the TX lock and call ieee80211_node_free() on each. * It would be nice if I could hold the TX lock for the entire TX and TX completion, rather than this release/re-acquire behaviour. But that requires that I shuffle around the TX completion code to handle actual ath_buf free and net80211 callback/free outside of the TX lock. That's one of my next projects. * the ic_raw_xmit() path doesn't use this yet - so it still has sequencing problems with parallel, overlapping calls to the data path. I'll fix this later. Tested: * Hostap - AR9280, AR9220 * STA - AR5212, AR9280, AR5416
2013-01-15 18:01:23 +00:00
TASK_INIT(&sc->sc_txqtask, 0, ath_txq_sched_tasklet, sc);
TASK_INIT(&sc->sc_fataltask, 0, ath_fatal_proc, sc);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
/*
Update with last year of work.
2004-12-08 17:34:36 +00:00
* Allocate hardware transmit queues: one queue for
* beacon frames and one data queue for each QoS
Correct spelling of reseting (found while researching the "bb hang detected" messages that are plaguing me). While I'm here, delete trailing whitespace.
2010-02-19 18:23:45 +00:00
* priority. Note that the hal handles resetting
Update with last year of work.
2004-12-08 17:34:36 +00:00
* these queues at the needed time.
*
* XXX PS-Poll
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
*/
Extend the beacon code slightly to support AP mode beaconing for the EDMA HAL hardware. * The EDMA HAL code assumes the nexttbtt and intval values are in TU/8 units, rather than TU. For now, just "hack" around that here, at least until I code up something to translate it in the HAL. * Setup some different TXQ flags for EDMA hardware. * The EDMA HAL doesn't support setting the first rate series via ath_hal_setuptxdesc() - instead, a call to ath_hal_set11nratescenario() is always required. So for now, just do an 11n rate series setup for EDMA beacon frames. This allows my AR9380 to successfully transmit beacon frames. However, CABQ TX and all normal data frame TX and TX completion is still not functional and will require some more significant code churn to make work.
2012-08-11 23:26:19 +00:00
sc->sc_bhalq = ath_beaconq_setup(sc);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
if (sc->sc_bhalq == (u_int) -1) {
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
device_printf(sc->sc_dev,
"unable to setup a beacon xmit queue!\n");
Update with last year of work.
2004-12-08 17:34:36 +00:00
error = EIO;
goto bad2;
}
sc->sc_cabq = ath_txq_setup(sc, HAL_TX_QUEUE_CAB, 0);
if (sc->sc_cabq == NULL) {
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
device_printf(sc->sc_dev, "unable to setup CAB xmit queue!\n");
Update with last year of work.
2004-12-08 17:34:36 +00:00
error = EIO;
goto bad2;
}
/* NB: insure BK queue is the lowest priority h/w queue */
if (!ath_tx_setup(sc, WME_AC_BK, HAL_WME_AC_BK)) {
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
device_printf(sc->sc_dev,
"unable to setup xmit queue for %s traffic!\n",
ieee80211_wme_acnames[WME_AC_BK]);
Update with last year of work.
2004-12-08 17:34:36 +00:00
error = EIO;
goto bad2;
}
if (!ath_tx_setup(sc, WME_AC_BE, HAL_WME_AC_BE) ||
!ath_tx_setup(sc, WME_AC_VI, HAL_WME_AC_VI) ||
!ath_tx_setup(sc, WME_AC_VO, HAL_WME_AC_VO)) {
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
/*
Update with last year of work.
2004-12-08 17:34:36 +00:00
* Not enough hardware tx queues to properly do WME;
* just punt and assign them all to the same h/w queue.
* We could do a better job of this if, for example,
* we allocate queues when we switch from station to
* AP mode.
*/
if (sc->sc_ac2q[WME_AC_VI] != NULL)
ath_tx_cleanupq(sc, sc->sc_ac2q[WME_AC_VI]);
if (sc->sc_ac2q[WME_AC_BE] != NULL)
ath_tx_cleanupq(sc, sc->sc_ac2q[WME_AC_BE]);
sc->sc_ac2q[WME_AC_BE] = sc->sc_ac2q[WME_AC_BK];
sc->sc_ac2q[WME_AC_VI] = sc->sc_ac2q[WME_AC_BK];
sc->sc_ac2q[WME_AC_VO] = sc->sc_ac2q[WME_AC_BK];
}
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
/*
Migrate some more TX side setup routines to be methods.
2012-07-31 03:09:48 +00:00
* Attach the TX completion function.
*
* The non-EDMA chips may have some special case optimisations;
* this method gives everyone a chance to attach cleanly.
Update with last year of work.
2004-12-08 17:34:36 +00:00
*/
Migrate some more TX side setup routines to be methods.
2012-07-31 03:09:48 +00:00
sc->sc_tx.xmit_attach_comp_func(sc);
Update with last year of work.
2004-12-08 17:34:36 +00:00
/*
* Setup rate control. Some rate control modules
* call back to change the anntena state so expose
* the necessary entry points.
* XXX maybe belongs in struct ath_ratectrl?
*/
sc->sc_setdefantenna = ath_setdefantenna;
sc->sc_rc = ath_rate_attach(sc);
if (sc->sc_rc == NULL) {
error = EIO;
cleanup descriptor allocation if attach fails Obtained from: madwifi
2004-04-02 23:47:39 +00:00
goto bad2;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
Flesh out the radar detection related operations for the ath driver. This is in no way a complete DFS/radar detection implementation! It merely creates an abstracted interface which allows for future development of the DFS radar detection code. Note: Net80211 already handles the bulk of the DFS machinery, all we need to do here is figure out that a radar event has occured and inform it as such. It then drives the DFS state engine for us. The "null" DFS radar detection module is included by default; it doesn't require a device line. This commit: * Adds a simple abstracted layer for radar detection state - sys/dev/ath/ath_dfs/; * Implements a null DFS module which doesn't do anything; (ie, implements the exact behaviour at the moment); * Adds hooks to the ath driver to process received radar events and gives the DFS module a chance to determine whether a radar has been detected. Obtained from: Atheros
2011-06-01 20:09:49 +00:00
/* Attach DFS module */
if (! ath_dfs_attach(sc)) {
Do a quick style(9) pass of some of the code introduced with 802.11n support.
2011-12-26 05:26:35 +00:00
device_printf(sc->sc_dev,
"%s: unable to attach DFS\n", __func__);
Flesh out the radar detection related operations for the ath driver. This is in no way a complete DFS/radar detection implementation! It merely creates an abstracted interface which allows for future development of the DFS radar detection code. Note: Net80211 already handles the bulk of the DFS machinery, all we need to do here is figure out that a radar event has occured and inform it as such. It then drives the DFS state engine for us. The "null" DFS radar detection module is included by default; it doesn't require a device line. This commit: * Adds a simple abstracted layer for radar detection state - sys/dev/ath/ath_dfs/; * Implements a null DFS module which doesn't do anything; (ie, implements the exact behaviour at the moment); * Adds hooks to the ath driver to process received radar events and gives the DFS module a chance to determine whether a radar has been detected. Obtained from: Atheros
2011-06-01 20:09:49 +00:00
error = EIO;
goto bad2;
}
Add a new (skeleton) spectral mode manager module.
2013-01-02 03:59:02 +00:00
/* Attach spectral module */
if (ath_spectral_attach(sc) < 0) {
device_printf(sc->sc_dev,
"%s: unable to attach spectral\n", __func__);
error = EIO;
goto bad2;
}
Bring over the initial static bluetooth coexistence configuration for the WB195 combo NIC - an AR9285 w/ an AR3011 USB bluetooth NIC. The AR3011 is wired up using a 3-wire coexistence scheme to the AR9285. The code in if_ath_btcoex.c sets up the initial hardware mapping and coexistence configuration. There's nothing special about it - it's static; it doesn't try to configure bluetooth / MAC traffic priorities or try to figure out what's actually going on. It's enough to stop basic bluetooth traffic from causing traffic stalls and diassociation from the wireless network. To use this code, you must have the above NIC. No, it won't work for the AR9287+AR3012, nor the AR9485, AR9462 or AR955x combo cards. Then you set a kernel hint before boot or before kldload, where 'X' is the unit number of your AR9285 NIC: # kenv hint.ath.X.btcoex_profile=wb195 This will then appear in your boot messages: [100482] athX: Enabling WB195 BTCOEX This code is going to evolve pretty quickly (well, depending upon my spare time) so don't assume the btcoex API is going to stay stable. In order to use the bluetooth side, you must also load in firmware using ath3kfw and the binary firmware file (ath3k-1.fw in my case.) Tested: * AR9280, no interference * WB195 - AR9285 + AR3011 combo; STA mode; basic bluetooth inquiries were enough to cause traffic stalls and disassociations. This has stopped with the btcoex profile code. TODO: * Importantly - the AR9285 needs ASPM disabled if bluetooth coexistence is enabled. No, I don't know why. It's likely some kind of bug to do with the AR3011 sending bluetooth coexistence signals whilst the device is asleep. Since we don't actually sleep the MAC just yet, it shouldn't be a problem. That said, to be totally correct: + ASPM should be disabled - upon attach and wakeup + The PCIe powersave HAL code should never be called Look at what the ath9k driver does for inspiration. * Add WB197 (AR9287+AR3012) support * Add support for the AR9485, which is another combo like the AR9285 * The later NICs have a different signaling mechanism between the MAC and the bluetooth device; I haven't even begun to experiment with making that HAL code work. But it should be a lot more automatic. * The hardware can do much more interesting traffic weighting with bluetooth and wifi traffic. None of this is currently used. Ideally someone would code up something to watch the bluetooth traffic GPIO (via an interrupt) and then watch it go high/low; then figure out what the bluetooth traffic is and adjust things appropriately. * If I get the time I may add in some code to at least track this stuff and expose statistics. But it's up to someone else to experiment with the bluetooth coexistence support and add the interesting stuff (like "real" detection of bulk, audio, etc bluetooth traffic patterns and change wifi parameters appropriately - eg, maximum aggregate length, transmit power, using quiet time to control TX duty cycle, etc.)
2013-06-07 09:02:02 +00:00
/* Attach bluetooth coexistence module */
if (ath_btcoex_attach(sc) < 0) {
device_printf(sc->sc_dev,
"%s: unable to attach bluetooth coexistence\n", __func__);
error = EIO;
goto bad2;
}
Migrate the LNA mixing diversity machinery from the AR9285 HAL to the driver. The AR9485 chip and AR933x SoC both implement LNA diversity. There are a few extra things that need to happen before this can be flipped on for those chips (mostly to do with setting up the different bias values and LNA1/LNA2 RSSI differences) but the first stage is putting this code into the driver layer so it can be reused. This has the added benefit of making it easier to expose configuration options and diagnostic information via the ioctl API. That's not yet being done but it sure would be nice to do so. Tested: * AR9285, with LNA diversity enabled * AR9285, with LNA diversity disabled in EEPROM
2013-06-12 14:52:57 +00:00
/* Attach LNA diversity module */
if (ath_lna_div_attach(sc) < 0) {
device_printf(sc->sc_dev,
"%s: unable to attach LNA diversity\n", __func__);
error = EIO;
goto bad2;
}
Flesh out the radar detection related operations for the ath driver. This is in no way a complete DFS/radar detection implementation! It merely creates an abstracted interface which allows for future development of the DFS radar detection code. Note: Net80211 already handles the bulk of the DFS machinery, all we need to do here is figure out that a radar event has occured and inform it as such. It then drives the DFS state engine for us. The "null" DFS radar detection module is included by default; it doesn't require a device line. This commit: * Adds a simple abstracted layer for radar detection state - sys/dev/ath/ath_dfs/; * Implements a null DFS module which doesn't do anything; (ie, implements the exact behaviour at the moment); * Adds hooks to the ath driver to process received radar events and gives the DFS module a chance to determine whether a radar has been detected. Obtained from: Atheros
2011-06-01 20:09:49 +00:00
/* Start DFS processing tasklet */
TASK_INIT(&sc->sc_dfstask, 0, ath_dfs_tasklet, sc);
Flesh out configurable hardware based LED blinking. The hardware (MAC) LED blinking involves a few things: * Selecting which GPIO pins map to the MAC "power" and "network" lines; * Configuring the MAC LED state (associated, scanning, idle); * Configuring the MAC LED blinking type and speed. The AR5416 HAL configures the normal blinking setup - ie, blink rate based on TX/RX throughput. The default AR5212 HAL doesn't program in any specific blinking type, but the default of 0 is the same. This code introduces a few things: * The hardware led override is configured via sysctl 'hardled'; * The MAC network and power LED GPIO lines can be set, or left at -1 if needed. This is intended to allow only one of the hardware MUX entries to be configured (eg for PCIe cards which only have one LED exposed.) TODO: * For AR2417, the software LED blinking involves software blinking the Network LED. For the AR5416 and later, this can just be configured as a GPIO output line. I'll chase that up with a subsequent commit. * Add another software LED blink for "Link", separate from "activity", which blinks based on the association state. This would make my D-Link DWA-552 have consistent and useful LED behaviour (as they're marked "Link" and "Activity." * Don't expose the hardware LED override unless it's an AR5416 or later, as the previous generation hardware doesn't have this multiplexing setup.
2011-12-26 07:47:05 +00:00
/* Configure LED state */
better led blinking
2005-01-18 19:03:04 +00:00
sc->sc_blinking = 0;
Update with last year of work.
2004-12-08 17:34:36 +00:00
sc->sc_ledstate = 1;
better led blinking
2005-01-18 19:03:04 +00:00
sc->sc_ledon = 0; /* low true */
sc->sc_ledidle = (2700*hz)/1000; /* 2.7sec */
CALLOUT_MPSAFE has lost its meaning since r141428, i.e., for more than ten years for head. However, it is continuously misused as the mpsafe argument for callout_init(9). Deprecate the flag and clean up callout_init() calls to make them more consistent. Differential Revision: https://reviews.freebsd.org/D2613 Reviewed by: jhb MFC after: 2 weeks
2015-05-22 17:05:21 +00:00
callout_init(&sc->sc_ledtimer, 1);
Flesh out configurable hardware based LED blinking. The hardware (MAC) LED blinking involves a few things: * Selecting which GPIO pins map to the MAC "power" and "network" lines; * Configuring the MAC LED state (associated, scanning, idle); * Configuring the MAC LED blinking type and speed. The AR5416 HAL configures the normal blinking setup - ie, blink rate based on TX/RX throughput. The default AR5212 HAL doesn't program in any specific blinking type, but the default of 0 is the same. This code introduces a few things: * The hardware led override is configured via sysctl 'hardled'; * The MAC network and power LED GPIO lines can be set, or left at -1 if needed. This is intended to allow only one of the hardware MUX entries to be configured (eg for PCIe cards which only have one LED exposed.) TODO: * For AR2417, the software LED blinking involves software blinking the Network LED. For the AR5416 and later, this can just be configured as a GPIO output line. I'll chase that up with a subsequent commit. * Add another software LED blink for "Link", separate from "activity", which blinks based on the association state. This would make my D-Link DWA-552 have consistent and useful LED behaviour (as they're marked "Link" and "Activity." * Don't expose the hardware LED override unless it's an AR5416 or later, as the previous generation hardware doesn't have this multiplexing setup.
2011-12-26 07:47:05 +00:00
/*
* Don't setup hardware-based blinking.
*
* Although some NICs may have this configured in the
* default reset register values, the user may wish
* to alter which pins have which function.
*
* The reference driver attaches the MAC network LED to GPIO1 and
* the MAC power LED to GPIO2. However, the DWA-552 cardbus
* NIC has these reversed.
*/
sc->sc_hardled = (1 == 0);
sc->sc_led_net_pin = -1;
sc->sc_led_pwr_pin = -1;
Update with last year of work.
2004-12-08 17:34:36 +00:00
/*
* Auto-enable soft led processing for IBM cards and for
* 5211 minipci cards. Users can also manually enable/disable
* support with a sysctl.
*/
sc->sc_softled = (devid == AR5212_DEVID_IBM || devid == AR5211_DEVID);
Refactor out the software LED config code into a common function, called ath_led_config(). The eventual aim is to have both software and hardware based LED configuration done here.
2011-12-26 05:46:22 +00:00
ath_led_config(sc);
Setup the initial LED state on attach and resume. Some of the NICs I have here power up with the LEDs blinking, which is incorrect. The blinking should only occur when the NIC is attempting to associate. * On powerup, set the state to HAL_LED_INIT, which turns on the "Power" MAC LED but leaves the "Network" MAC LED the way it is. * On resume, also init it to HAL_LED_INIT unless in station mode, where it's forced to HAL_LED_RUN. Hopefully the net80211 state machine will call newstate() at some point, which will refiddle the LEDs. I've tested this on a handful of 11n and pre-11n NICs. The blinking behaviour is slightly more sensible now.
2011-12-26 06:25:12 +00:00
ath_hal_setledstate(ah, HAL_LED_INIT);
Update with last year of work.
2004-12-08 17:34:36 +00:00
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
/* XXX not right but it's not used anywhere important */
ic->ic_phytype = IEEE80211_T_OFDM;
ic->ic_opmode = IEEE80211_M_STA;
Update with last year of work.
2004-12-08 17:34:36 +00:00
ic->ic_caps =
Minor cleanup of vap create work: o add IEEE80211_C_STA capability to indicate sta mode is supported (was previously assumed) and mark drivers as capable o add ieee80211_opcap array to map an opmode to the equivalent capability bit o move IEEE80211_C_OPMODE definition to where capabilities are defined so it's clear it should be kept in sync (on future additions) o check device capabilities in clone create before trying to create a vap; this makes driver checks unneeded o make error codes return on failed clone request unique o temporarily add console printfs on clone request failures to aid in debugging; these will move under DIAGNOSTIC or similar before release
2008-05-12 00:15:30 +00:00
IEEE80211_C_STA /* station mode */
| IEEE80211_C_IBSS /* ibss, nee adhoc, mode */
indicate device receives all management frames
2003-10-17 21:55:53 +00:00
| IEEE80211_C_HOSTAP /* hostap mode */
| IEEE80211_C_MONITOR /* monitor mode */
add adhoc demo mode support MFC after: 2 weeks
2006-02-09 21:42:53 +00:00
| IEEE80211_C_AHDEMO /* adhoc demo mode */
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
| IEEE80211_C_WDS /* 4-address traffic works */
Implementation of the upcoming Wireless Mesh standard, 802.11s, on the net80211 wireless stack. This work is based on the March 2009 D3.0 draft standard. This standard is expected to become final next year. This includes two main net80211 modules, ieee80211_mesh.c which deals with peer link management, link metric calculation, routing table control and mesh configuration and ieee80211_hwmp.c which deals with the actually routing process on the mesh network. HWMP is the mandatory routing protocol on by the mesh standard, but others, such as RA-OLSR, can be implemented. Authentication and encryption are not implemented. There are several scripts under tools/tools/net80211/scripts that can be used to test different mesh network topologies and they also teach you how to setup a mesh vap (for the impatient: ifconfig wlan0 create wlandev ... wlanmode mesh). A new build option is available: IEEE80211_SUPPORT_MESH and it's enabled by default on GENERIC kernels for i386, amd64, sparc64 and pc98. Drivers that support mesh networks right now are: ath, ral and mwl. More information at: http://wiki.freebsd.org/WifiMesh Please note that this work is experimental. Also, please note that bridging a mesh vap with another network interface is not yet supported. Many thanks to the FreeBSD Foundation for sponsoring this project and to Sam Leffler for his support. Also, I would like to thank Gateworks Corporation for sending me a Cambria board which was used during the development of this project. Reviewed by: sam Approved by: re (kensmith) Obtained from: projects/mesh11s
2009-07-11 15:02:45 +00:00
| IEEE80211_C_MBSS /* mesh point link mode */
indicate device receives all management frames
2003-10-17 21:55:53 +00:00
| IEEE80211_C_SHPREAMBLE /* short preamble supported */
Update with last year of work.
2004-12-08 17:34:36 +00:00
| IEEE80211_C_SHSLOT /* short slot time supported */
| IEEE80211_C_WPA /* capable of WPA1+WPA2 */
Disable BGSCAN for 802.11n for now. Until scanning during traffic is fixed for 802.11n TX, this needs to be disabled or users wlil see randomly hanging aggregation sessions. Whilst I'm here, remove the warning about 802.11n being full of dragons. It's nowhere near that scary now.
2012-06-14 04:14:06 +00:00
#ifndef ATH_ENABLE_11N
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
| IEEE80211_C_BGSCAN /* capable of bg scanning */
Disable BGSCAN for 802.11n for now. Until scanning during traffic is fixed for 802.11n TX, this needs to be disabled or users wlil see randomly hanging aggregation sessions. Whilst I'm here, remove the warning about 802.11n being full of dragons. It's nowhere near that scary now.
2012-06-14 04:14:06 +00:00
#endif
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
| IEEE80211_C_TXFRAG /* handle tx frags */
Add ATH_ENABLE_DFS which enables the DFS flag so the DFS code can be tested. This doesn't at all actually do radar detection! It's just so developers who wish to test the net80211 DFS code can easily do so. Without this flag, the DFS channels are never marked DFS and thus the DFS stuff doesn't run.
2011-06-26 13:43:15 +00:00
#ifdef ATH_ENABLE_DFS
Do a quick style(9) pass of some of the code introduced with 802.11n support.
2011-12-26 05:26:35 +00:00
| IEEE80211_C_DFS /* Enable radar detection */
Add ATH_ENABLE_DFS which enables the DFS flag so the DFS code can be tested. This doesn't at all actually do radar detection! It's just so developers who wish to test the net80211 DFS code can easily do so. Without this flag, the DFS channels are never marked DFS and thus the DFS stuff doesn't run.
2011-06-26 13:43:15 +00:00
#endif
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
| IEEE80211_C_PMGT /* Station side power mgmt */
| IEEE80211_C_SWSLEEP
remove use IEEE80211_C_RCVMGT
2004-04-02 23:37:00 +00:00
;
Update with last year of work.
2004-12-08 17:34:36 +00:00
/*
* Query the hal to figure out h/w crypto support.
*/
if (ath_hal_ciphersupported(ah, HAL_CIPHER_WEP))
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
ic->ic_cryptocaps |= IEEE80211_CRYPTO_WEP;
Update with last year of work.
2004-12-08 17:34:36 +00:00
if (ath_hal_ciphersupported(ah, HAL_CIPHER_AES_OCB))
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
ic->ic_cryptocaps |= IEEE80211_CRYPTO_AES_OCB;
Update with last year of work.
2004-12-08 17:34:36 +00:00
if (ath_hal_ciphersupported(ah, HAL_CIPHER_AES_CCM))
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
ic->ic_cryptocaps |= IEEE80211_CRYPTO_AES_CCM;
Update with last year of work.
2004-12-08 17:34:36 +00:00
if (ath_hal_ciphersupported(ah, HAL_CIPHER_CKIP))
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
ic->ic_cryptocaps |= IEEE80211_CRYPTO_CKIP;
Update with last year of work.
2004-12-08 17:34:36 +00:00
if (ath_hal_ciphersupported(ah, HAL_CIPHER_TKIP)) {
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
ic->ic_cryptocaps |= IEEE80211_CRYPTO_TKIP;
Update with last year of work.
2004-12-08 17:34:36 +00:00
/*
* Check if h/w does the MIC and/or whether the
* separate key cache entries are required to
* handle both tx+rx MIC keys.
*/
if (ath_hal_ciphersupported(ah, HAL_CIPHER_MIC))
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
ic->ic_cryptocaps |= IEEE80211_CRYPTO_TKIPMIC;
Add support for newer parts that do not require separate keycache entries for tx+rx mic keys. This requires a newer hal, but works fine with the current hal in cvs. MFC after: 2 weeks
2006-09-18 16:26:19 +00:00
/*
* If the h/w supports storing tx+rx MIC keys
* in one cache slot automatically enable use.
*/
if (ath_hal_hastkipsplit(ah) ||
!ath_hal_settkipsplit(ah, AH_FALSE))
Update with last year of work.
2004-12-08 17:34:36 +00:00
sc->sc_splitmic = 1;
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
/*
* If the h/w can do TKIP MIC together with WME then
* we use it; otherwise we force the MIC to be done
* in software by the net80211 layer.
*/
if (ath_hal_haswmetkipmic(ah))
sc->sc_wmetkipmic = 1;
Update with last year of work.
2004-12-08 17:34:36 +00:00
}
Misc keycache changes: o purge ath_initkeytable; it's not needed o add multicast key search support for supporting multiple group keys (disabled for now; requires updated hal) o create keycache entry for stations using open auth so they get h/w antenna management support o add keycache -> node mapping table; eliminates mac-based lookup in the net80211 layer
2005-06-06 16:39:21 +00:00
sc->sc_hasclrkey = ath_hal_ciphersupported(ah, HAL_CIPHER_CLR);
Add multicast key search support. This fixes corrupted mcast packets when we have more than one hostap vap. Submitted by: Russell Yount <russell.yount at gmail.com> MFC after: 2 weeks
2010-02-08 20:23:20 +00:00
/*
Fix typo in comment. Pointed out by: danfe
2010-02-10 11:12:39 +00:00
* Check for multicast key search support.
Add multicast key search support. This fixes corrupted mcast packets when we have more than one hostap vap. Submitted by: Russell Yount <russell.yount at gmail.com> MFC after: 2 weeks
2010-02-08 20:23:20 +00:00
*/
if (ath_hal_hasmcastkeysearch(sc->sc_ah) &&
!ath_hal_getmcastkeysearch(sc->sc_ah)) {
ath_hal_setmcastkeysearch(sc->sc_ah, 1);
}
Misc keycache changes: o purge ath_initkeytable; it's not needed o add multicast key search support for supporting multiple group keys (disabled for now; requires updated hal) o create keycache entry for stations using open auth so they get h/w antenna management support o add keycache -> node mapping table; eliminates mac-based lookup in the net80211 layer
2005-06-06 16:39:21 +00:00
sc->sc_mcastkey = ath_hal_getmcastkeysearch(ah);
Add support for newer parts that do not require separate keycache entries for tx+rx mic keys. This requires a newer hal, but works fine with the current hal in cvs. MFC after: 2 weeks
2006-09-18 16:26:19 +00:00
/*
* Mark key cache slots associated with global keys
* as in use. If we knew TKIP was not to be used we
* could leave the +32, +64, and +32+64 slots free.
*/
for (i = 0; i < IEEE80211_WEP_NKID; i++) {
setbit(sc->sc_keymap, i);
setbit(sc->sc_keymap, i+64);
if (sc->sc_splitmic) {
setbit(sc->sc_keymap, i+32);
setbit(sc->sc_keymap, i+32+64);
}
}
Update with last year of work.
2004-12-08 17:34:36 +00:00
/*
* TPC support can be done either with a global cap or
* per-packet support. The latter is not available on
* all parts. We're a bit pedantic here as all parts
* support a global cap.
*/
o fix setup of sc_diversity; the hal does not give us reliable status after attach, only after a reset o when setting diversity via the sysctl don't update sc_diversity until we know the hal requested worked o while here eliminate sc_hasdiversity and sc_hastpc; just query the hal each time since these are the only places we need to know MFC after: 3 days
2005-07-24 05:11:39 +00:00
if (ath_hal_hastpc(ah) || ath_hal_hastxpowlimit(ah))
Update with last year of work.
2004-12-08 17:34:36 +00:00
ic->ic_caps |= IEEE80211_C_TXPMGT;
/*
* Mark WME capability only if we have sufficient
* hardware queues to do proper priority scheduling.
*/
if (sc->sc_ac2q[WME_AC_BE] != sc->sc_ac2q[WME_AC_BK])
ic->ic_caps |= IEEE80211_C_WME;
/*
Misc keycache changes: o purge ath_initkeytable; it's not needed o add multicast key search support for supporting multiple group keys (disabled for now; requires updated hal) o create keycache entry for stations using open auth so they get h/w antenna management support o add keycache -> node mapping table; eliminates mac-based lookup in the net80211 layer
2005-06-06 16:39:21 +00:00
* Check for misc other capabilities.
Update with last year of work.
2004-12-08 17:34:36 +00:00
*/
if (ath_hal_hasbursting(ah))
ic->ic_caps |= IEEE80211_C_BURST;
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
sc->sc_hasbmask = ath_hal_hasbssidmask(ah);
Implementation of the upcoming Wireless Mesh standard, 802.11s, on the net80211 wireless stack. This work is based on the March 2009 D3.0 draft standard. This standard is expected to become final next year. This includes two main net80211 modules, ieee80211_mesh.c which deals with peer link management, link metric calculation, routing table control and mesh configuration and ieee80211_hwmp.c which deals with the actually routing process on the mesh network. HWMP is the mandatory routing protocol on by the mesh standard, but others, such as RA-OLSR, can be implemented. Authentication and encryption are not implemented. There are several scripts under tools/tools/net80211/scripts that can be used to test different mesh network topologies and they also teach you how to setup a mesh vap (for the impatient: ifconfig wlan0 create wlandev ... wlanmode mesh). A new build option is available: IEEE80211_SUPPORT_MESH and it's enabled by default on GENERIC kernels for i386, amd64, sparc64 and pc98. Drivers that support mesh networks right now are: ath, ral and mwl. More information at: http://wiki.freebsd.org/WifiMesh Please note that this work is experimental. Also, please note that bridging a mesh vap with another network interface is not yet supported. Many thanks to the FreeBSD Foundation for sponsoring this project and to Sam Leffler for his support. Also, I would like to thank Gateworks Corporation for sending me a Cambria board which was used during the development of this project. Reviewed by: sam Approved by: re (kensmith) Obtained from: projects/mesh11s
2009-07-11 15:02:45 +00:00
sc->sc_hasbmatch = ath_hal_hasbssidmatch(ah);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
sc->sc_hastsfadd = ath_hal_hastsfadjust(ah);
Add a HAL capability bit for supporting self-linked RX descriptors and disable it for the 11n chipsets. From the ath9k source: == 11N: we can no longer afford to self link the last descriptor. MAC acknowledges BA status as long as it copies frames to host buffer (or rx fifo). This can incorrectly acknowledge packets to a sender if last desc is self-linked. == Since this is useful for pre-AR5416 chips that communicate PHY errors via error frames rather than by on-chip counters, leave the support in there, but disable it for AR5416 and later.
2011-04-04 14:52:31 +00:00
sc->sc_rxslink = ath_hal_self_linked_final_rxdesc(ah);
[ath_hal] retire a "long RX desc" flag, store/use the TX/RX timestamp length. * the code already stored the length of the RX desc, which I never used. So, use that and retire the new flag I introduced a while ago. * Introduce a TX timestamp length field and capability.
2016-07-08 21:34:39 +00:00
/* XXX TODO: just make this a "store tx/rx timestamp length" operation */
if (ath_hal_get_rx_tsf_prec(ah, &i)) {
if (i == 32) {
sc->sc_rxtsf32 = 1;
}
if (bootverbose)
device_printf(sc->sc_dev, "RX timestamp: %d bits\n", i);
}
if (ath_hal_get_tx_tsf_prec(ah, &i)) {
if (bootverbose)
device_printf(sc->sc_dev, "TX timestamp: %d bits\n", i);
}
Enable the use of TDMA on an 802.11n channel (with aggregation disabled, of course.) There's a few things that needed to happen: * In case someone decides to set the beacon transmission rate to be at an MCS rate, use the MCS-aware version of the duration calculation to figure out how long the received beacon frame was. * If TxOP enforcing is available on the hardware and we're doing TDMA, enable it after a reset and set the TDMA guard interval to zero. This seems to behave fine. TODO: * Although I haven't yet seen packet loss, the PHY errors that would be triggered (specifically Transmit-Override-Receive) aren't enabled by the 11n HAL. I'll have to do some work to enable these PHY errors for debugging. What broke: * My recent changes to the TX queue handling has resulted in the driver not keeping the hardware queue properly filled when doing non-aggregate traffic. I have a patch to commit soon which fixes this situation (albeit by reminding me about how my ath driver locking isn't working out, sigh.) So if you want to test this without updating to the next set of patches that I commit, just bump the sysctl dev.ath.X.hwq_limit from 2 to 32. Tested: * AR5416 <-> AR5416, with ampdu disabled, HT40, 5GHz, MCS12+Short-GI. I saw 30mbit/sec in both directions using a bidirectional UDP test.
2013-05-21 18:02:54 +00:00
sc->sc_hasenforcetxop = ath_hal_hasenforcetxop(ah);
Implement a bit of a hack to store the AR9285/AR9485 RX LNA configuration in the RX antenna field. The AR9285/AR9485 use an LNA mixer to determine how to combine the signals from the two antennas. This is encoded in the RSSI fields (ctl/ext) for chain 2. So, let's use that here. This maps RX antennas 0->3 to the RX mixer configuration used to receive a frame. There's more that can be done but this is good enough to diagnose if the hardware is doing "odd" things like trying to receive frames on LNA2 (ie, antenna 2 or "alt" antenna) when there's only one antenna connected. Tested: * AR9285, STA mode
2013-06-05 00:45:19 +00:00
sc->sc_rx_lnamixer = ath_hal_hasrxlnamixer(ah);
Migrate the LNA mixing diversity machinery from the AR9285 HAL to the driver. The AR9485 chip and AR933x SoC both implement LNA diversity. There are a few extra things that need to happen before this can be flipped on for those chips (mostly to do with setting up the different bias values and LNA1/LNA2 RSSI differences) but the first stage is putting this code into the driver layer so it can be reused. This has the added benefit of making it easier to expose configuration options and diagnostic information via the ioctl API. That's not yet being done but it sure would be nice to do so. Tested: * AR9285, with LNA diversity enabled * AR9285, with LNA diversity disabled in EEPROM
2013-06-12 14:52:57 +00:00
sc->sc_hasdivcomb = ath_hal_hasdivantcomb(ah);
[ath] fix "doing stuff before wakeup" warning; add comments for ACK/CTS handling during DFS/PASSIVE channels * Although the hardware is awake, the power state handling doesn't think so. So just explicitly wake it up early in setup so ath_hal calls don't complain. * We shouldn't be transmitting or ACKing frames during DFS CAC or on passive channels before we hear a beacon. So, start laying down comments in the places where this work has to be done. Note: * The main bit missing from finishing this particular bit of work is a state call to transition a VAP from passive to non-passive when a beacon is heard. CAC is easy, it's an interface state. So, I'll go and add a method to control that soon.
2017-01-27 01:17:00 +00:00
/*
* Some WB335 cards do not support antenna diversity. Since
* we use a hardcoded value for AR9565 instead of using the
* EEPROM/OTP data, remove the combining feature from
* the HW capabilities bitmap.
*/
/*
* XXX TODO: check reference driver and ath9k for what to do
* here for WB335. I think we have to actually disable the
* LNA div processing in the HAL and instead use the hard
* coded values; and then use BT diversity.
*
* .. but also need to setup MCI too for WB335..
*/
#if 0
if (sc->sc_pci_devinfo & (ATH9K_PCI_AR9565_1ANT | ATH9K_PCI_AR9565_2ANT)) {
device_printf(sc->sc_dev, "%s: WB335: disabling LNA mixer diversity\n",
__func__);
sc->sc_dolnadiv = 0;
}
#endif
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
if (ath_hal_hasfastframes(ah))
ic->ic_caps |= IEEE80211_C_FF;
Overhaul regulatory support: o remove HAL_CHANNEL; convert the hal to use net80211 channels; this mostly involves mechanical changes to variable names and channel attribute macros o gut HAL_CHANNEL_PRIVATE as most of the contents are now redundant with the net80211 channel available o change api for ath_hal_init_channels: no more reglass id's, no more outdoor indication (was a noop), anM contents o add ath_hal_getchannels to have the hal construct a channel list without altering runtime state; this is used to retrieve the calibration list for the device in ath_getradiocaps o add ath_hal_set_channels to take a channel list and regulatory data from above and construct internal state to match (maps frequencies for 900MHz cards, setup for CTL lookups, etc) o compact the private channel table: we keep one private channel per frequency instead of one per HAL_CHANNEL; this gives a big space savings and potentially improves ani and calibration by sharing state (to be seen; didn't see anything in testing); a new config option AH_MAXCHAN controls the table size (default to 96 which was chosen to be ~3x the largest expected size) o shrink ani state and change to mirror private channel table (one entry per frequency indexed by ic_devdata) o move ani state flags to private channel state o remove country codes; use net80211 definitions instead o remove GSM regulatory support; it's no longer needed now that we pass in channel lists from above o consolidate ADHOC_NO_11A attribute with DISALLOW_ADHOC_11A o simplify initial channel list construction based on the EEPROM contents; we preserve country code support for now but may want to just fallback to a WWR sku and dispatch the discovered country code up to user space so the channel list can be constructed using the master regdomain tables o defer to net80211 for max antenna gain o eliminate sorting of internal channel table; now that we use ic_devdata as an index, table lookups are O(1) o remove internal copy of the country code; the public one is sufficient o remove AH_SUPPORT_11D conditional compilation; we always support 11d o remove ath_hal_ispublicsafetysku; not needed any more o remove ath_hal_isgsmsku; no more GSM stuff o move Conformance Test Limit (CTL) state from private channel to a lookup using per-band pointers cached in the private state block o remove regulatory class id support; was unused and belongs in net80211 o fix channel list construction to set IEEE80211_CHAN_NOADHOC, IEEE80211_CHAN_NOHOSTAP, and IEEE80211_CHAN_4MSXMIT o remove private channel flags CHANNEL_DFS and CHANNEL_4MS_LIMIT; these are now set in the constructed net80211 channel o store CHANNEL_NFCREQUIRED (Noise Floor Required) channel attribute in one of the driver-private flag bits of the net80211 channel o move 900MHz frequency mapping into the hal; the mapped frequency is stored in the private channel and used throughout the hal (no more mapping in the driver and/or net80211) o remove ath_hal_mhz2ieee; it's no longer needed as net80211 does the calculation and available in the net80211 channel o change noise floor calibration logic to work with compacted private channel table setup; this may require revisiting as we no longer can distinguish channel attributes (e.g. 11b vs 11g vs turbo) but since the data is used only to calculate status data we can live with it for now o change ah_getChipPowerLimits internal method to operate on a single channel instead of all channels in the private channel table o add ath_hal_gethwchannel to map a net80211 channel to a h/w frequency (always the same except for 900MHz channels) o add HAL_EEBADREG and HAL_EEBADCC status codes to better identify regulatory problems o remove CTRY_DEBUG and CTRY_DEFAULT enum's; these come from net80211 now o change ath_hal_getwirelessmodes to really return wireless modes supported by the hardware (was previously applying regulatory constraints) o return channel interference status with IEEE80211_CHANSTATE_CWINT (should change to a callback so hal api's can take const pointers) o remove some #define's no longer needed with the inclusion of <net80211/_ieee80211.h> Sponsored by: Carlson Wireless
2009-01-28 18:00:22 +00:00
wmodes = ath_hal_getwirelessmodes(ah);
prepare for a new hal
2008-10-27 18:30:33 +00:00
if (wmodes & (HAL_MODE_108G|HAL_MODE_TURBO))
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
ic->ic_caps |= IEEE80211_C_TURBOP;
Remove ATH_SUPPORT_TDMA and use IEEE80211_SUPPORT_TDMA instead. It doesn't make much sense to configure driver support w/o net80211. Note this means ath now depends on opt_wlan.h.
2009-03-30 19:23:49 +00:00
#ifdef IEEE80211_SUPPORT_TDMA
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
if (ath_hal_macversion(ah) > 0x78) {
ic->ic_caps |= IEEE80211_C_TDMA; /* capable of TDMA */
ic->ic_tdma_update = ath_tdma_update;
}
#endif
Add in the (very!) optional glue to flip the 11n bits for if_ath. There's still a lot of random issues to sort out with the radio side of things and AMPDU RX handling (and completely missing AMPDU TX handling!) but if people wish to give this a go and assist in debugging the issues, they can define ATH_DO_11N to enable it. I'm just re-iterating - this is here to allow people to assist in further 11n development; it is not any indication that the 11n support is complete and functional. Important notes: * This doesn't support 1-stream cards yet - (eg AR9285) - the various bits that negotiate TX/RX MCS don't know not to try >1 stream TX or negotiate 1-stream RX; so don't enable 11n unless you've first taught the rate control module and the net80211 stack to negotiate 1-stream stuff; * The only rate control module minimally 11n aware is ath_rate_sample; * ath_rate_sample doesn't know about HT/40; so airtime will be incorrectly calculated; * The AR9160 and AR9280 radio code is unreliable at the higher MCS rates for some reason; this will definitely impact 11n performance; * AMPDU-TX isn't yet implemented; * AMPDU-RX may be a bit buggy still and will definitely suffer from the radio unreliability mentioned above (ie, don't expect 150/300mbit RX just yet.)
2011-02-09 15:43:38 +00:00
Don't flood the cabq/mcastq with frames. In a very noisy 2.4GHz environment (with HT/40 enabled, making it worse) I saw the following occur: * the air was considered "busy" a lot of the time; * the cabq time is quite short due to staggered beacons being enabled; * it just wasn't able to keep up TX'ing CABQ frames; * .. and the cabq would swallow up all the TX ath_buf's. This patch introduces a twiddle which allows the maximum cabq depth to be set, forcing further frames to be dropped. It defaults to the TX buffer count at the moment, so the default behaviour isn't changed. I've also started fleshing out a similar setup for the data path, so it doesn't swallow up all the available TX buffers and preventing management frames (such as ADDBA) out. PR: kern/165895
2012-03-10 04:14:04 +00:00
/*
* TODO: enforce that at least this many frames are available
* in the txbuf list before allowing data frames (raw or
* otherwise) to be transmitted.
*/
sc->sc_txq_data_minfree = 10;
[ath] modify cabq and per-node packet usage limits. * limit cabq to 64 - in practice if this stays at ath_txbuf then all buffers can be tied up by a very busy broadcast domain (eg ARP storm, way too much MDNS/NETBIOS). It's been like this in the freebsd-wifi-build AP project for the longest time. * Now that I figured out the hilarity inherent in aggregate forming and AR9380 EDMA work, change the per-node to 64 frames by default. I'll do some more work to shorten the queue latency introduced when doing data so TCP isn't so terrible, but it's now no longer /always/ tens of milliseconds of extra latency when doing active iperf tests. Notes: The reason for the extra latency is partly tx/rx taskqueue handling and scheduling, and partly due to a lack of airtime/QoS awareness of per-node traffic. Ideally we'd have different limits/priorities on the QoS/TID levels per node so say, voice/video data got a better share of buffer allocations over best effort/bulk data, but we currently don't implement that. It's not /hard/ to do, I just need to do it. Tested: * AR9380 (STA), AR9580 (hostap) - both with the relevant changes. TCP is now at around 180mbit with rate control and RTS protection enabled. UDP stays at 355mbit at MCS23, no HT protection.
2017-01-23 04:47:38 +00:00
Don't flood the cabq/mcastq with frames. In a very noisy 2.4GHz environment (with HT/40 enabled, making it worse) I saw the following occur: * the air was considered "busy" a lot of the time; * the cabq time is quite short due to staggered beacons being enabled; * it just wasn't able to keep up TX'ing CABQ frames; * .. and the cabq would swallow up all the TX ath_buf's. This patch introduces a twiddle which allows the maximum cabq depth to be set, forcing further frames to be dropped. It defaults to the TX buffer count at the moment, so the default behaviour isn't changed. I've also started fleshing out a similar setup for the data path, so it doesn't swallow up all the available TX buffers and preventing management frames (such as ADDBA) out. PR: kern/165895
2012-03-10 04:14:04 +00:00
/*
[ath] modify cabq and per-node packet usage limits. * limit cabq to 64 - in practice if this stays at ath_txbuf then all buffers can be tied up by a very busy broadcast domain (eg ARP storm, way too much MDNS/NETBIOS). It's been like this in the freebsd-wifi-build AP project for the longest time. * Now that I figured out the hilarity inherent in aggregate forming and AR9380 EDMA work, change the per-node to 64 frames by default. I'll do some more work to shorten the queue latency introduced when doing data so TCP isn't so terrible, but it's now no longer /always/ tens of milliseconds of extra latency when doing active iperf tests. Notes: The reason for the extra latency is partly tx/rx taskqueue handling and scheduling, and partly due to a lack of airtime/QoS awareness of per-node traffic. Ideally we'd have different limits/priorities on the QoS/TID levels per node so say, voice/video data got a better share of buffer allocations over best effort/bulk data, but we currently don't implement that. It's not /hard/ to do, I just need to do it. Tested: * AR9380 (STA), AR9580 (hostap) - both with the relevant changes. TCP is now at around 180mbit with rate control and RTS protection enabled. UDP stays at 355mbit at MCS23, no HT protection.
2017-01-23 04:47:38 +00:00
* Shorten this to 64 packets, or 1/4 ath_txbuf, whichever
* is smaller.
*
* Anything bigger can potentially see the cabq consume
* almost all buffers, starving everything else, only to
* see most fail to transmit in the given beacon interval.
Don't flood the cabq/mcastq with frames. In a very noisy 2.4GHz environment (with HT/40 enabled, making it worse) I saw the following occur: * the air was considered "busy" a lot of the time; * the cabq time is quite short due to staggered beacons being enabled; * it just wasn't able to keep up TX'ing CABQ frames; * .. and the cabq would swallow up all the TX ath_buf's. This patch introduces a twiddle which allows the maximum cabq depth to be set, forcing further frames to be dropped. It defaults to the TX buffer count at the moment, so the default behaviour isn't changed. I've also started fleshing out a similar setup for the data path, so it doesn't swallow up all the available TX buffers and preventing management frames (such as ADDBA) out. PR: kern/165895
2012-03-10 04:14:04 +00:00
*/
[ath] modify cabq and per-node packet usage limits. * limit cabq to 64 - in practice if this stays at ath_txbuf then all buffers can be tied up by a very busy broadcast domain (eg ARP storm, way too much MDNS/NETBIOS). It's been like this in the freebsd-wifi-build AP project for the longest time. * Now that I figured out the hilarity inherent in aggregate forming and AR9380 EDMA work, change the per-node to 64 frames by default. I'll do some more work to shorten the queue latency introduced when doing data so TCP isn't so terrible, but it's now no longer /always/ tens of milliseconds of extra latency when doing active iperf tests. Notes: The reason for the extra latency is partly tx/rx taskqueue handling and scheduling, and partly due to a lack of airtime/QoS awareness of per-node traffic. Ideally we'd have different limits/priorities on the QoS/TID levels per node so say, voice/video data got a better share of buffer allocations over best effort/bulk data, but we currently don't implement that. It's not /hard/ to do, I just need to do it. Tested: * AR9380 (STA), AR9580 (hostap) - both with the relevant changes. TCP is now at around 180mbit with rate control and RTS protection enabled. UDP stays at 355mbit at MCS23, no HT protection.
2017-01-23 04:47:38 +00:00
sc->sc_txq_mcastq_maxdepth = MIN(64, ath_txbuf / 4);
Don't flood the cabq/mcastq with frames. In a very noisy 2.4GHz environment (with HT/40 enabled, making it worse) I saw the following occur: * the air was considered "busy" a lot of the time; * the cabq time is quite short due to staggered beacons being enabled; * it just wasn't able to keep up TX'ing CABQ frames; * .. and the cabq would swallow up all the TX ath_buf's. This patch introduces a twiddle which allows the maximum cabq depth to be set, forcing further frames to be dropped. It defaults to the TX buffer count at the moment, so the default behaviour isn't changed. I've also started fleshing out a similar setup for the data path, so it doesn't swallow up all the available TX buffers and preventing management frames (such as ADDBA) out. PR: kern/165895
2012-03-10 04:14:04 +00:00
Implement my first cut at "correct" node power-save and PS-POLL support. This implements PS-POLL awareness i nthe * Implement frame "leaking", which allows for a software queue to be scheduled even though it's asleep * Track whether a frame has been leaked or not * Leak out a single non-AMPDU frame when transmitting aggregates * Queue BAR frames if the node is asleep * Direct-dispatch the rest of control and management frames. This allows for things like re-association to occur (which involves sending probe req/resp as well as assoc request/response) when the node is asleep and then tries reassociating. * Limit how many frames can set in the software node queue whilst the node is asleep. net80211 is already buffering frames for us so this is mostly just paranoia. * Add a PS-POLL method which leaks out a frame if there's something in the software queue, else it calls net80211's ps-poll routine. Since the ath PS-POLL routine marks the node as having a single frame to leak, either a software queued frame would leak, OR the next queued frame would leak. The next queued frame could be something from the net80211 power save queue, OR it could be a NULL frame from net80211. TODO: * Don't transmit further BAR frames (eg via a timeout) if the node is currently asleep. Otherwise we may end up exhausting management frames due to the lots of queued BAR frames. I may just undo this bit later on and direct-dispatch BAR frames even if the node is asleep. * It would be nice to burst out a single A-MPDU frame if both ends support this. I may end adding a FreeBSD IE soon to negotiate this power save behaviour. * I should make STAs timeout of power save mode if they've been in power save for more than a handful of seconds. This way cards that get "stuck" in power save mode don't stay there for the "inactivity" timeout in net80211. * Move the queue depth check into the driver layer (ath_start / ath_transmit) rather than doing it in the TX path. * There could be some naughty corner cases with ps-poll leaking. Specifically, if net80211 generates a NULL data frame whilst another transmitter sends a normal data frame out net80211 output / transmit, we need to ensure that the NULL data frame goes out first. This is one of those things that should occur inside the VAP/ic TX lock. Grr, more investigations to do.. Tested: * STA: AR5416, AR9280 * AP: AR5416, AR9280, AR9160
2013-05-15 18:33:05 +00:00
/*
* How deep can the node software TX queue get whilst it's asleep.
*/
sc->sc_txq_node_psq_maxdepth = 16;
Re-work how transmit buffer limits are enforced - partly to fix the PR, but partly to just tidy up things. The problem here - there are too many TX buffers in the queue! By the time one needs to transmit an EAPOL frame (for this PR, it's the response to the group rekey notification from the AP) there are no ath_buf entries free and the EAPOL frame doesn't go out. Now, the problem! * Enforcing the TX buffer limitation _before_ we dequeue the frame? Bad idea. Because.. * .. it means I can't check whether the mbuf has M_EAPOL set. The solution(s): * De-queue the frame first * Don't bother doing the TX buffer minimum free check until after we know whether it's an EAPOL frame or not. * If it's an EAPOL frame, allocate the buffer from the mgmt pool rather than the default pool. Whilst I'm here: * Add a tweak to limit how many buffers a single node can acquire. * Don't enforce that for EAPOL frames. * .. set that to default to 1/4 of the available buffers, or 32, whichever is more sane. This doesn't fix issues due to a sleeping node or a very poor performing node; but this doesn't make it worse. Tested: * AR5416 STA, TX'ing 100+ mbit UDP to an AP, but only 50mbit being received (thus the TX queue fills up.) * .. with CCMP / WPA2 encryption configured * .. and the group rekey time set to 10 seconds, just to elicit the behaviour very quickly. PR: kern/138379
2013-05-07 07:52:18 +00:00
/*
kernel: Fix several typos and minor errors - duplicate words - typos - references to old versions of FreeBSD Reviewed by: imp, benno
2017-12-27 03:23:21 +00:00
* Default the maximum queue to 1/4'th the TX buffers, or
[ath] modify cabq and per-node packet usage limits. * limit cabq to 64 - in practice if this stays at ath_txbuf then all buffers can be tied up by a very busy broadcast domain (eg ARP storm, way too much MDNS/NETBIOS). It's been like this in the freebsd-wifi-build AP project for the longest time. * Now that I figured out the hilarity inherent in aggregate forming and AR9380 EDMA work, change the per-node to 64 frames by default. I'll do some more work to shorten the queue latency introduced when doing data so TCP isn't so terrible, but it's now no longer /always/ tens of milliseconds of extra latency when doing active iperf tests. Notes: The reason for the extra latency is partly tx/rx taskqueue handling and scheduling, and partly due to a lack of airtime/QoS awareness of per-node traffic. Ideally we'd have different limits/priorities on the QoS/TID levels per node so say, voice/video data got a better share of buffer allocations over best effort/bulk data, but we currently don't implement that. It's not /hard/ to do, I just need to do it. Tested: * AR9380 (STA), AR9580 (hostap) - both with the relevant changes. TCP is now at around 180mbit with rate control and RTS protection enabled. UDP stays at 355mbit at MCS23, no HT protection.
2017-01-23 04:47:38 +00:00
* 64, whichever is smaller.
Re-work how transmit buffer limits are enforced - partly to fix the PR, but partly to just tidy up things. The problem here - there are too many TX buffers in the queue! By the time one needs to transmit an EAPOL frame (for this PR, it's the response to the group rekey notification from the AP) there are no ath_buf entries free and the EAPOL frame doesn't go out. Now, the problem! * Enforcing the TX buffer limitation _before_ we dequeue the frame? Bad idea. Because.. * .. it means I can't check whether the mbuf has M_EAPOL set. The solution(s): * De-queue the frame first * Don't bother doing the TX buffer minimum free check until after we know whether it's an EAPOL frame or not. * If it's an EAPOL frame, allocate the buffer from the mgmt pool rather than the default pool. Whilst I'm here: * Add a tweak to limit how many buffers a single node can acquire. * Don't enforce that for EAPOL frames. * .. set that to default to 1/4 of the available buffers, or 32, whichever is more sane. This doesn't fix issues due to a sleeping node or a very poor performing node; but this doesn't make it worse. Tested: * AR5416 STA, TX'ing 100+ mbit UDP to an AP, but only 50mbit being received (thus the TX queue fills up.) * .. with CCMP / WPA2 encryption configured * .. and the group rekey time set to 10 seconds, just to elicit the behaviour very quickly. PR: kern/138379
2013-05-07 07:52:18 +00:00
*/
[ath] modify cabq and per-node packet usage limits. * limit cabq to 64 - in practice if this stays at ath_txbuf then all buffers can be tied up by a very busy broadcast domain (eg ARP storm, way too much MDNS/NETBIOS). It's been like this in the freebsd-wifi-build AP project for the longest time. * Now that I figured out the hilarity inherent in aggregate forming and AR9380 EDMA work, change the per-node to 64 frames by default. I'll do some more work to shorten the queue latency introduced when doing data so TCP isn't so terrible, but it's now no longer /always/ tens of milliseconds of extra latency when doing active iperf tests. Notes: The reason for the extra latency is partly tx/rx taskqueue handling and scheduling, and partly due to a lack of airtime/QoS awareness of per-node traffic. Ideally we'd have different limits/priorities on the QoS/TID levels per node so say, voice/video data got a better share of buffer allocations over best effort/bulk data, but we currently don't implement that. It's not /hard/ to do, I just need to do it. Tested: * AR9380 (STA), AR9580 (hostap) - both with the relevant changes. TCP is now at around 180mbit with rate control and RTS protection enabled. UDP stays at 355mbit at MCS23, no HT protection.
2017-01-23 04:47:38 +00:00
sc->sc_txq_node_maxdepth = MIN(64, ath_txbuf / 4);
Re-work how transmit buffer limits are enforced - partly to fix the PR, but partly to just tidy up things. The problem here - there are too many TX buffers in the queue! By the time one needs to transmit an EAPOL frame (for this PR, it's the response to the group rekey notification from the AP) there are no ath_buf entries free and the EAPOL frame doesn't go out. Now, the problem! * Enforcing the TX buffer limitation _before_ we dequeue the frame? Bad idea. Because.. * .. it means I can't check whether the mbuf has M_EAPOL set. The solution(s): * De-queue the frame first * Don't bother doing the TX buffer minimum free check until after we know whether it's an EAPOL frame or not. * If it's an EAPOL frame, allocate the buffer from the mgmt pool rather than the default pool. Whilst I'm here: * Add a tweak to limit how many buffers a single node can acquire. * Don't enforce that for EAPOL frames. * .. set that to default to 1/4 of the available buffers, or 32, whichever is more sane. This doesn't fix issues due to a sleeping node or a very poor performing node; but this doesn't make it worse. Tested: * AR5416 STA, TX'ing 100+ mbit UDP to an AP, but only 50mbit being received (thus the TX queue fills up.) * .. with CCMP / WPA2 encryption configured * .. and the group rekey time set to 10 seconds, just to elicit the behaviour very quickly. PR: kern/138379
2013-05-07 07:52:18 +00:00
Overhaul the TXQ locking (again!) as part of some beacon/cabq timing related issues. Moving the TX locking under one lock made things easier to progress on but it had one important side-effect - it increased the latency when handling CABQ setup when sending beacons. This commit introduces a bunch of new changes and a few unrelated changs that are just easier to lump in here. The aim is to have the CABQ locking separate from other locking. The CABQ transmit path in the beacon process thus doesn't have to grab the general TX lock, reducing lock contention/latency and making it more likely that we'll make the beacon TX timing. The second half of this commit is the CABQ related setup changes needed for sane looking EDMA CABQ support. Right now the EDMA TX code naively assumes that only one frame (MPDU or A-MPDU) is being pushed into each FIFO slot. For the CABQ this isn't true - a whole list of frames is being pushed in - and thus CABQ handling breaks very quickly. The aim here is to setup the CABQ list and then push _that list_ to the hardware for transmission. I can then extend the EDMA TX code to stamp that list as being "one" FIFO entry (likely by tagging the last buffer in that list as "FIFO END") so the EDMA TX completion code correctly tracks things. Major: * Migrate the per-TXQ add/removal locking back to per-TXQ, rather than a single lock. * Leave the software queue side of things under the ATH_TX_LOCK lock, (continuing) to serialise things as they are. * Add a new function which is called whenever there's a beacon miss, to print out some debugging. This is primarily designed to help me figure out if the beacon miss events are due to a noisy environment, issues with the PHY/MAC, or other. * Move the CABQ setup/enable to occur _after_ all the VAPs have been looked at. This means that for multiple VAPS in bursted mode, the CABQ gets primed once all VAPs are checked, rather than being primed on the first VAP and then having frames appended after this. Minor: * Add a (disabled) twiddle to let me enable/disable cabq traffic. It's primarily there to let me easily debug what's going on with beacon and CABQ setup/traffic; there's some DMA engine hangs which I'm finally trying to trace down. * Clear bf_next when flushing frames; it should quieten some warnings that show up when a node goes away. Tested: * AR9280, STA/hostap, up to 4 vaps (staggered) * AR5416, STA/hostap, up to 4 vaps (staggered) TODO: * (Lots) more AR9380 and later testing, as I may have missed something here. * Leverage this to fix CABQ hanling for AR9380 and later chips. * Force bursted beaconing on the chips that default to staggered beacons and ensure the CABQ stuff is all sane (eg, the MORE bits that aren't being correctly set when chaining descriptors.)
2013-03-24 00:03:12 +00:00
/* Enable CABQ by default */
sc->sc_cabq_enable = 1;
Add in a new driver feature to allow the TX and RX chainmask to be overridden at attach time. Some 802.11n NICs may only have one physical antenna connected. The radios will be very upset if you try enabling radios which aren't connected to antennas. This allows hints to override the TX and RX chainmask. These hints are: hint.ath.X.rx_chainmask hint.ath.X.tx_chainmask They can be set at either boot time or in kenv before the module is loaded. This and the previous HAL commit were sponsored in late 2011 by Hobnob, Inc. Sponsored by: Hobnob, Inc.
2012-02-10 10:01:09 +00:00
/*
* Allow the TX and RX chainmasks to be overridden by
* environment variables and/or device.hints.
*
* This must be done early - before the hardware is
* calibrated or before the 802.11n stream calculation
* is done.
*/
if (resource_int_value(device_get_name(sc->sc_dev),
device_get_unit(sc->sc_dev), "rx_chainmask",
&rx_chainmask) == 0) {
device_printf(sc->sc_dev, "Setting RX chainmask to 0x%x\n",
rx_chainmask);
(void) ath_hal_setrxchainmask(sc->sc_ah, rx_chainmask);
}
if (resource_int_value(device_get_name(sc->sc_dev),
device_get_unit(sc->sc_dev), "tx_chainmask",
&tx_chainmask) == 0) {
device_printf(sc->sc_dev, "Setting TX chainmask to 0x%x\n",
tx_chainmask);
.. oops, use the right chainmask.
2012-02-10 10:09:16 +00:00
(void) ath_hal_settxchainmask(sc->sc_ah, tx_chainmask);
Add in a new driver feature to allow the TX and RX chainmask to be overridden at attach time. Some 802.11n NICs may only have one physical antenna connected. The radios will be very upset if you try enabling radios which aren't connected to antennas. This allows hints to override the TX and RX chainmask. These hints are: hint.ath.X.rx_chainmask hint.ath.X.tx_chainmask They can be set at either boot time or in kenv before the module is loaded. This and the previous HAL commit were sponsored in late 2011 by Hobnob, Inc. Sponsored by: Hobnob, Inc.
2012-02-10 10:01:09 +00:00
}
Initialise the chainmask fields regardless of whether 11n support is compiled in or not. This fixes issues with people running -HEAD but who build modules without doing a "make buildkernel KERNCONF=XXX", thus picking up opt_*.h. The resulting module wouldn't have 11n enabled and the chainmask configuration would just be plain wrong.
2013-04-19 21:49:11 +00:00
/*
* Query the TX/RX chainmask configuration.
*
* This is only relevant for 11n devices.
*/
ath_hal_getrxchainmask(ah, &sc->sc_rxchainmask);
ath_hal_gettxchainmask(ah, &sc->sc_txchainmask);
Allow 802.11n hardware to support multi-rate retry when RTS/CTS is enabled. The legacy (pre-802.11n) hardware doesn't support this - although the AR5212 era hardware supports MRR, it doesn't have all the bits needed to support MRR + RTS/CTS. The AR5416 and later support a packet duration and RTS/CTS flags per rate scenario, so we should support it. Tested: * AR9280, STA PR: kern/170302
2012-07-31 23:54:15 +00:00
/*
* Disable MRR with protected frames by default.
* Only 802.11n series NICs can handle this.
*/
sc->sc_mrrprot = 0; /* XXX should be a capability */
Add a new HAL call to extract out the HAL enterprise bits from the AR9300 HAL.
2012-11-03 22:12:35 +00:00
/*
* Query the enterprise mode information the HAL.
*/
if (ath_hal_getcapability(ah, HAL_CAP_ENTERPRISE_MODE, 0,
&sc->sc_ent_cfg) == HAL_OK)
sc->sc_use_ent = 1;
Rename AH_ENABLE_11N to ATH_ENABLE_11 - the HAL supports 11n by default but the ath driver doesn't. This is a much more consistent name.
2011-03-27 08:47:55 +00:00
#ifdef ATH_ENABLE_11N
Add in the (very!) optional glue to flip the 11n bits for if_ath. There's still a lot of random issues to sort out with the radio side of things and AMPDU RX handling (and completely missing AMPDU TX handling!) but if people wish to give this a go and assist in debugging the issues, they can define ATH_DO_11N to enable it. I'm just re-iterating - this is here to allow people to assist in further 11n development; it is not any indication that the 11n support is complete and functional. Important notes: * This doesn't support 1-stream cards yet - (eg AR9285) - the various bits that negotiate TX/RX MCS don't know not to try >1 stream TX or negotiate 1-stream RX; so don't enable 11n unless you've first taught the rate control module and the net80211 stack to negotiate 1-stream stuff; * The only rate control module minimally 11n aware is ath_rate_sample; * ath_rate_sample doesn't know about HT/40; so airtime will be incorrectly calculated; * The AR9160 and AR9280 radio code is unreliable at the higher MCS rates for some reason; this will definitely impact 11n performance; * AMPDU-TX isn't yet implemented; * AMPDU-RX may be a bit buggy still and will definitely suffer from the radio unreliability mentioned above (ie, don't expect 150/300mbit RX just yet.)
2011-02-09 15:43:38 +00:00
/*
* Query HT capabilities
*/
if (ath_hal_getcapability(ah, HAL_CAP_HT, 0, NULL) == HAL_OK &&
(wmodes & (HAL_MODE_HT20 | HAL_MODE_HT40))) {
Use uint32_t for fields that are fetched via ath_hal_getcapability().
2013-04-19 06:59:10 +00:00
uint32_t rxs, txs;
[ath] add LDPC capability support and LDPC RX support. This enables LDPC receive support for the AR9300 chips that support it. It'll announce LDPC support via net80211. Tested: * AR9380, STA mode * AR9331, (to verify the HAL didn't attach it to a chip which doesn't support LDPC.) TODO: * Add in net80211 machinery to make this configurable at runtime.
2016-04-26 01:37:03 +00:00
uint32_t ldpc;
Add in the (very!) optional glue to flip the 11n bits for if_ath. There's still a lot of random issues to sort out with the radio side of things and AMPDU RX handling (and completely missing AMPDU TX handling!) but if people wish to give this a go and assist in debugging the issues, they can define ATH_DO_11N to enable it. I'm just re-iterating - this is here to allow people to assist in further 11n development; it is not any indication that the 11n support is complete and functional. Important notes: * This doesn't support 1-stream cards yet - (eg AR9285) - the various bits that negotiate TX/RX MCS don't know not to try >1 stream TX or negotiate 1-stream RX; so don't enable 11n unless you've first taught the rate control module and the net80211 stack to negotiate 1-stream stuff; * The only rate control module minimally 11n aware is ath_rate_sample; * ath_rate_sample doesn't know about HT/40; so airtime will be incorrectly calculated; * The AR9160 and AR9280 radio code is unreliable at the higher MCS rates for some reason; this will definitely impact 11n performance; * AMPDU-TX isn't yet implemented; * AMPDU-RX may be a bit buggy still and will definitely suffer from the radio unreliability mentioned above (ie, don't expect 150/300mbit RX just yet.)
2011-02-09 15:43:38 +00:00
device_printf(sc->sc_dev, "[HT] enabling HT modes\n");
Allow 802.11n hardware to support multi-rate retry when RTS/CTS is enabled. The legacy (pre-802.11n) hardware doesn't support this - although the AR5212 era hardware supports MRR, it doesn't have all the bits needed to support MRR + RTS/CTS. The AR5416 and later support a packet duration and RTS/CTS flags per rate scenario, so we should support it. Tested: * AR9280, STA PR: kern/170302
2012-07-31 23:54:15 +00:00
sc->sc_mrrprot = 1; /* XXX should be a capability */
Do a quick style(9) pass of some of the code introduced with 802.11n support.
2011-12-26 05:26:35 +00:00
ic->ic_htcaps = IEEE80211_HTC_HT /* HT operation */
| IEEE80211_HTC_AMPDU /* A-MPDU tx/rx */
| IEEE80211_HTC_AMSDU /* A-MSDU tx/rx */
| IEEE80211_HTCAP_MAXAMSDU_3839
/* max A-MSDU length */
| IEEE80211_HTCAP_SMPS_OFF; /* SM power save off */
Add in the (very!) optional glue to flip the 11n bits for if_ath. There's still a lot of random issues to sort out with the radio side of things and AMPDU RX handling (and completely missing AMPDU TX handling!) but if people wish to give this a go and assist in debugging the issues, they can define ATH_DO_11N to enable it. I'm just re-iterating - this is here to allow people to assist in further 11n development; it is not any indication that the 11n support is complete and functional. Important notes: * This doesn't support 1-stream cards yet - (eg AR9285) - the various bits that negotiate TX/RX MCS don't know not to try >1 stream TX or negotiate 1-stream RX; so don't enable 11n unless you've first taught the rate control module and the net80211 stack to negotiate 1-stream stuff; * The only rate control module minimally 11n aware is ath_rate_sample; * ath_rate_sample doesn't know about HT/40; so airtime will be incorrectly calculated; * The AR9160 and AR9280 radio code is unreliable at the higher MCS rates for some reason; this will definitely impact 11n performance; * AMPDU-TX isn't yet implemented; * AMPDU-RX may be a bit buggy still and will definitely suffer from the radio unreliability mentioned above (ie, don't expect 150/300mbit RX just yet.)
2011-02-09 15:43:38 +00:00
Teach if_ath about devices which have short-GI in 20MHz channel modes. This has been disabled until now because there hasn't been any supported device which has this feature. Since the AR9287 is the first device to support it, and since now the HAL has functional AR9287+11n support, flip this on.
2011-05-29 00:17:13 +00:00
/*
* Enable short-GI for HT20 only if the hardware
* advertises support.
* Notably, anything earlier than the AR9287 doesn't.
*/
if ((ath_hal_getcapability(ah,
HAL_CAP_HT20_SGI, 0, NULL) == HAL_OK) &&
(wmodes & HAL_MODE_HT20)) {
device_printf(sc->sc_dev,
"[HT] enabling short-GI in 20MHz mode\n");
ic->ic_htcaps |= IEEE80211_HTCAP_SHORTGI20;
}
Add in the (very!) optional glue to flip the 11n bits for if_ath. There's still a lot of random issues to sort out with the radio side of things and AMPDU RX handling (and completely missing AMPDU TX handling!) but if people wish to give this a go and assist in debugging the issues, they can define ATH_DO_11N to enable it. I'm just re-iterating - this is here to allow people to assist in further 11n development; it is not any indication that the 11n support is complete and functional. Important notes: * This doesn't support 1-stream cards yet - (eg AR9285) - the various bits that negotiate TX/RX MCS don't know not to try >1 stream TX or negotiate 1-stream RX; so don't enable 11n unless you've first taught the rate control module and the net80211 stack to negotiate 1-stream stuff; * The only rate control module minimally 11n aware is ath_rate_sample; * ath_rate_sample doesn't know about HT/40; so airtime will be incorrectly calculated; * The AR9160 and AR9280 radio code is unreliable at the higher MCS rates for some reason; this will definitely impact 11n performance; * AMPDU-TX isn't yet implemented; * AMPDU-RX may be a bit buggy still and will definitely suffer from the radio unreliability mentioned above (ie, don't expect 150/300mbit RX just yet.)
2011-02-09 15:43:38 +00:00
if (wmodes & HAL_MODE_HT40)
ic->ic_htcaps |= IEEE80211_HTCAP_CHWIDTH40
| IEEE80211_HTCAP_SHORTGI40;
/*
Do a quick style(9) pass of some of the code introduced with 802.11n support.
2011-12-26 05:26:35 +00:00
* TX/RX streams need to be taken into account when
* negotiating which MCS rates it'll receive and
Add in the (very!) optional glue to flip the 11n bits for if_ath. There's still a lot of random issues to sort out with the radio side of things and AMPDU RX handling (and completely missing AMPDU TX handling!) but if people wish to give this a go and assist in debugging the issues, they can define ATH_DO_11N to enable it. I'm just re-iterating - this is here to allow people to assist in further 11n development; it is not any indication that the 11n support is complete and functional. Important notes: * This doesn't support 1-stream cards yet - (eg AR9285) - the various bits that negotiate TX/RX MCS don't know not to try >1 stream TX or negotiate 1-stream RX; so don't enable 11n unless you've first taught the rate control module and the net80211 stack to negotiate 1-stream stuff; * The only rate control module minimally 11n aware is ath_rate_sample; * ath_rate_sample doesn't know about HT/40; so airtime will be incorrectly calculated; * The AR9160 and AR9280 radio code is unreliable at the higher MCS rates for some reason; this will definitely impact 11n performance; * AMPDU-TX isn't yet implemented; * AMPDU-RX may be a bit buggy still and will definitely suffer from the radio unreliability mentioned above (ie, don't expect 150/300mbit RX just yet.)
2011-02-09 15:43:38 +00:00
* what MCS rates are available for TX.
*/
Correctly fetch the TX/RX stream count from the HAL. Pointy hat to: me
2012-01-31 22:27:35 +00:00
(void) ath_hal_getcapability(ah, HAL_CAP_STREAMS, 0, &txs);
(void) ath_hal_getcapability(ah, HAL_CAP_STREAMS, 1, &rxs);
Add in the (very!) optional glue to flip the 11n bits for if_ath. There's still a lot of random issues to sort out with the radio side of things and AMPDU RX handling (and completely missing AMPDU TX handling!) but if people wish to give this a go and assist in debugging the issues, they can define ATH_DO_11N to enable it. I'm just re-iterating - this is here to allow people to assist in further 11n development; it is not any indication that the 11n support is complete and functional. Important notes: * This doesn't support 1-stream cards yet - (eg AR9285) - the various bits that negotiate TX/RX MCS don't know not to try >1 stream TX or negotiate 1-stream RX; so don't enable 11n unless you've first taught the rate control module and the net80211 stack to negotiate 1-stream stuff; * The only rate control module minimally 11n aware is ath_rate_sample; * ath_rate_sample doesn't know about HT/40; so airtime will be incorrectly calculated; * The AR9160 and AR9280 radio code is unreliable at the higher MCS rates for some reason; this will definitely impact 11n performance; * AMPDU-TX isn't yet implemented; * AMPDU-RX may be a bit buggy still and will definitely suffer from the radio unreliability mentioned above (ie, don't expect 150/300mbit RX just yet.)
2011-02-09 15:43:38 +00:00
ic->ic_txstream = txs;
ic->ic_rxstream = rxs;
Add in the STBC TX/RX capability support into the HAL and driver. The HAL already included the STBC fields; it just needed to be exposed to the driver and net80211 stack. This should allow single-stream STBC TX and RX to be negotiated; however the driver and rate control code currently don't do anything with it.
2013-02-27 00:25:44 +00:00
/*
* Setup TX and RX STBC based on what the HAL allows and
* the currently configured chainmask set.
* Ie - don't enable STBC TX if only one chain is enabled.
* STBC RX is fine on a single RX chain; it just won't
* provide any real benefit.
*/
if (ath_hal_getcapability(ah, HAL_CAP_RX_STBC, 0,
NULL) == HAL_OK) {
sc->sc_rx_stbc = 1;
device_printf(sc->sc_dev,
"[HT] 1 stream STBC receive enabled\n");
ic->ic_htcaps |= IEEE80211_HTCAP_RXSTBC_1STREAM;
}
if (txs > 1 && ath_hal_getcapability(ah, HAL_CAP_TX_STBC, 0,
NULL) == HAL_OK) {
sc->sc_tx_stbc = 1;
device_printf(sc->sc_dev,
"[HT] 1 stream STBC transmit enabled\n");
ic->ic_htcaps |= IEEE80211_HTCAP_TXSTBC;
}
Store away the RTS aggregate limit from the HAL. This will be used by some upcoming code to ensure that aggregates are enforced to be a certain size. The AR5416 has a limitation on RTS protected aggregates (8KiB).
2012-04-07 02:51:53 +00:00
(void) ath_hal_getcapability(ah, HAL_CAP_RTS_AGGR_LIMIT, 1,
&sc->sc_rts_aggr_limit);
if (sc->sc_rts_aggr_limit != (64 * 1024))
device_printf(sc->sc_dev,
"[HT] RTS aggregates limited to %d KiB\n",
sc->sc_rts_aggr_limit / 1024);
[ath] add LDPC capability support and LDPC RX support. This enables LDPC receive support for the AR9300 chips that support it. It'll announce LDPC support via net80211. Tested: * AR9380, STA mode * AR9331, (to verify the HAL didn't attach it to a chip which doesn't support LDPC.) TODO: * Add in net80211 machinery to make this configurable at runtime.
2016-04-26 01:37:03 +00:00
/*
* LDPC
*/
if ((ath_hal_getcapability(ah, HAL_CAP_LDPC, 0, &ldpc))
== HAL_OK && (ldpc == 1)) {
sc->sc_has_ldpc = 1;
device_printf(sc->sc_dev,
"[HT] LDPC transmit/receive enabled\n");
ath: adapt LDPC support checks Set both IEEE80211_HTCAP_LDPC and IEEE80211_HTC_TXLDPC capability flags if LDPC is supported + set 'do_ldpc = 1' only when it is not disabled, not just supported. Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D9277
2017-01-21 21:03:26 +00:00
ic->ic_htcaps |= IEEE80211_HTCAP_LDPC |
IEEE80211_HTC_TXLDPC;
[ath] add LDPC capability support and LDPC RX support. This enables LDPC receive support for the AR9300 chips that support it. It'll announce LDPC support via net80211. Tested: * AR9380, STA mode * AR9331, (to verify the HAL didn't attach it to a chip which doesn't support LDPC.) TODO: * Add in net80211 machinery to make this configurable at runtime.
2016-04-26 01:37:03 +00:00
}
Do a quick style(9) pass of some of the code introduced with 802.11n support.
2011-12-26 05:26:35 +00:00
device_printf(sc->sc_dev,
"[HT] %d RX streams; %d TX streams\n", rxs, txs);
Add in the (very!) optional glue to flip the 11n bits for if_ath. There's still a lot of random issues to sort out with the radio side of things and AMPDU RX handling (and completely missing AMPDU TX handling!) but if people wish to give this a go and assist in debugging the issues, they can define ATH_DO_11N to enable it. I'm just re-iterating - this is here to allow people to assist in further 11n development; it is not any indication that the 11n support is complete and functional. Important notes: * This doesn't support 1-stream cards yet - (eg AR9285) - the various bits that negotiate TX/RX MCS don't know not to try >1 stream TX or negotiate 1-stream RX; so don't enable 11n unless you've first taught the rate control module and the net80211 stack to negotiate 1-stream stuff; * The only rate control module minimally 11n aware is ath_rate_sample; * ath_rate_sample doesn't know about HT/40; so airtime will be incorrectly calculated; * The AR9160 and AR9280 radio code is unreliable at the higher MCS rates for some reason; this will definitely impact 11n performance; * AMPDU-TX isn't yet implemented; * AMPDU-RX may be a bit buggy still and will definitely suffer from the radio unreliability mentioned above (ie, don't expect 150/300mbit RX just yet.)
2011-02-09 15:43:38 +00:00
}
#endif
Shuffle these initialisations to where they should be.
2012-06-24 08:28:06 +00:00
/*
* Initial aggregation settings.
*/
Implement a separate hardware queue threshold for aggregate and non-aggr traffic. When transmitting non-aggregate traffic, we need to keep the hardware busy whilst transmitting or small bursts in txdone/tx latency will kill us. This restores non-aggregate iperf performance, especially when doing TDMA. Tested: * AR5416<->AR5416, TDMA * AR5416 STA <-> AR9280 AP
2013-05-21 18:13:57 +00:00
sc->sc_hwq_limit_aggr = ATH_AGGR_MIN_QDEPTH;
sc->sc_hwq_limit_nonaggr = ATH_NONAGGR_MIN_QDEPTH;
Shuffle these initialisations to where they should be.
2012-06-24 08:28:06 +00:00
sc->sc_tid_hwq_lo = ATH_AGGR_SCHED_LOW;
sc->sc_tid_hwq_hi = ATH_AGGR_SCHED_HIGH;
Add a new option to limit the maximum size of aggregates. The default is to limit them to what the hardware is capable of. Add sysctl twiddles for both the non-RTS and RTS protected aggregate generation. Whilst here, add some comments about stuff that I've discovered during my exploration of the TX aggregate / delimiter setup path from the reference driver.
2013-02-21 06:18:40 +00:00
sc->sc_aggr_limit = ATH_AGGR_MAXSIZE;
Add an option to allow the minimum number of delimiters to be tweaked. This is primarily for debugging purposes. Tested: * AR5416, STA mode
2013-02-21 06:38:49 +00:00
sc->sc_delim_min_pad = 0;
Shuffle these initialisations to where they should be.
2012-06-24 08:28:06 +00:00
Introduce a work-around for issues with the AR5416 based MAC on SMP devices. The AR5416 MAC (which shows up in the AR5008, AR9001, AR9002 devices) has issues with PCI transactions on SMP machines. This work-around enforces that register access is serialised through a (global for now) spinlock. This should stop the hangs people have seen with the AR5416 PCI devices on SMP hosts. Obtained by: Linux, Atheros
2011-11-09 22:39:44 +00:00
/*
* Check if the hardware requires PCI register serialisation.
* Some of the Owl based MACs require this.
*/
if (mp_ncpus > 1 &&
ath_hal_getcapability(ah, HAL_CAP_SERIALISE_WAR,
0, NULL) == HAL_OK) {
sc->sc_ah->ah_config.ah_serialise_reg_war = 1;
Do a quick style(9) pass of some of the code introduced with 802.11n support.
2011-12-26 05:26:35 +00:00
device_printf(sc->sc_dev,
"Enabling register serialisation\n");
Introduce a work-around for issues with the AR5416 based MAC on SMP devices. The AR5416 MAC (which shows up in the AR5008, AR9001, AR9002 devices) has issues with PCI transactions on SMP machines. This work-around enforces that register access is serialised through a (global for now) spinlock. This should stop the hangs people have seen with the AR5416 PCI devices on SMP hosts. Obtained by: Linux, Atheros
2011-11-09 22:39:44 +00:00
}
Break out the RX completion path into "FIFO check / refill" and "complete RX frames." The 128 entry RX FIFO is really easy to fill up and miss refilling when it's done in the ath taskq - as that gets blocked up doing RX completion, TX completion and other random things. So the 128 entry RX FIFO now gets emptied and refilled in the ath_intr() task (and it grabs / releases locks, so now ath_intr() can't just be a FAST handler yet!) but the locks aren't held for very long. The completion part is done in the ath taskqueue context. Details: * Create a new completed frame list - sc->sc_rx_rxlist; * Split the EDMA RX process queue into two halves - one that processes the RX FIFO and refills it with new frames; another that completes the completed frame list; * When tearing down the driver, flush whatever is in the deferred queue as well as what's in the FIFO; * Create two new RX methods - one that processes all RX queues, one that processes the given RX queue. When MSI is implemented, we get told which RX queue the interrupt came in on so we can specifically schedule that. (And I can do that with the non-MSI path too; I'll figure that out later.) * Convert the legacy code over to use these new RX methods; * Replace all the instances of the RX taskqueue enqueue with a call to a relevant RX method to enqueue one or all RX queues. Tested: * AR9380, STA * AR9580, STA * AR5413, STA
2013-03-19 19:32:28 +00:00
/*
* Initialise the deferred completed RX buffer list.
*/
Use a per-RX-queue deferred list, rather than a single deferred list for both queues. Since ath_rx_pkt() does multi-mbuf frame recombining based on the RX queue, this needs to occur. Tested: * AR9380 (XB112), hostap mode
2013-04-16 20:21:02 +00:00
TAILQ_INIT(&sc->sc_rx_rxlist[HAL_RX_QUEUE_HP]);
TAILQ_INIT(&sc->sc_rx_rxlist[HAL_RX_QUEUE_LP]);
Break out the RX completion path into "FIFO check / refill" and "complete RX frames." The 128 entry RX FIFO is really easy to fill up and miss refilling when it's done in the ath taskq - as that gets blocked up doing RX completion, TX completion and other random things. So the 128 entry RX FIFO now gets emptied and refilled in the ath_intr() task (and it grabs / releases locks, so now ath_intr() can't just be a FAST handler yet!) but the locks aren't held for very long. The completion part is done in the ath taskqueue context. Details: * Create a new completed frame list - sc->sc_rx_rxlist; * Split the EDMA RX process queue into two halves - one that processes the RX FIFO and refills it with new frames; another that completes the completed frame list; * When tearing down the driver, flush whatever is in the deferred queue as well as what's in the FIFO; * Create two new RX methods - one that processes all RX queues, one that processes the given RX queue. When MSI is implemented, we get told which RX queue the interrupt came in on so we can specifically schedule that. (And I can do that with the non-MSI path too; I'll figure that out later.) * Convert the legacy code over to use these new RX methods; * Replace all the instances of the RX taskqueue enqueue with a call to a relevant RX method to enqueue one or all RX queues. Tested: * AR9380, STA * AR9580, STA * AR5413, STA
2013-03-19 19:32:28 +00:00
Update with last year of work.
2004-12-08 17:34:36 +00:00
/*
* Indicate we need the 802.11 header padded to a
* 32-bit boundary for 4-address and QoS frames.
*/
ic->ic_flags |= IEEE80211_F_DATAPAD;
/*
* Query the hal about antenna support.
*/
sc->sc_defant = ath_hal_getdefantenna(ah);
/*
* Not all chips have the VEOL support we want to
* use with IBSS beacons; check here for it.
*/
sc->sc_hasveol = ath_hal_hasveol(ah);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
Update if_ath(4) to check for "hint.ath.X.macaddr" for an override MAC address. This is used by the AR71xx platform code to choose a local MAC based on the "board MAC address", versus whatever potentially invalid/garbage values are stored in the Atheros calibration data.
2015-03-28 23:41:23 +00:00
/* get mac address from kenv first, then hardware */
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
if (ath_fetch_mac_kenv(sc, ic->ic_macaddr) == 0) {
Fix a long-standing bug with the early MAC address initialisation path, which showed up after I started changing addresses this early. It turns out that there's some other malarky going on behind the scenes in the HAL and merely setting the net80211/ifp mac address this early isn't enough. If the MAC is set from kenv at attach time, the HAL also needs to be programmed early. Without this, the VAP wouldn't work enough for finishing association - probe requests would be fine as they're broadcast, but association request would fail.
2015-03-29 06:05:00 +00:00
/* Tell the HAL now about the new MAC */
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
ath_hal_setmac(ah, ic->ic_macaddr);
Fix a long-standing bug with the early MAC address initialisation path, which showed up after I started changing addresses this early. It turns out that there's some other malarky going on behind the scenes in the HAL and merely setting the net80211/ifp mac address this early isn't enough. If the MAC is set from kenv at attach time, the HAL also needs to be programmed early. Without this, the VAP wouldn't work enough for finishing association - probe requests would be fine as they're broadcast, but association request would fail.
2015-03-29 06:05:00 +00:00
} else {
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
ath_hal_getmac(ah, ic->ic_macaddr);
Fix a long-standing bug with the early MAC address initialisation path, which showed up after I started changing addresses this early. It turns out that there's some other malarky going on behind the scenes in the HAL and merely setting the net80211/ifp mac address this early isn't enough. If the MAC is set from kenv at attach time, the HAL also needs to be programmed early. Without this, the VAP wouldn't work enough for finishing association - probe requests would be fine as they're broadcast, but association request would fail.
2015-03-29 06:05:00 +00:00
}
Update if_ath(4) to check for "hint.ath.X.macaddr" for an override MAC address. This is used by the AR71xx platform code to choose a local MAC based on the "board MAC address", versus whatever potentially invalid/garbage values are stored in the Atheros calibration data.
2015-03-28 23:41:23 +00:00
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
if (sc->sc_hasbmask)
ath_hal_getbssidmask(ah, sc->sc_hwbssidmask);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
/* NB: used to size node table key mapping array */
ic->ic_max_keyix = sc->sc_keymax;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
/* call MI attach routine. */
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
ieee80211_ifattach(ic);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
ic->ic_setregdomain = ath_setregdomain;
ic->ic_getradiocaps = ath_getradiocaps;
sc->sc_opmode = HAL_M_STA;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
/* override default methods */
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
ic->ic_ioctl = ath_ioctl;
ic->ic_parent = ath_parent;
ic->ic_transmit = ath_transmit;
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
ic->ic_newassoc = ath_newassoc;
ic->ic_updateslot = ath_updateslot;
ic->ic_wme.wme_update = ath_wme_update;
ic->ic_vap_create = ath_vap_create;
ic->ic_vap_delete = ath_vap_delete;
ic->ic_raw_xmit = ath_raw_xmit;
ic->ic_update_mcast = ath_update_mcast;
ic->ic_update_promisc = ath_update_promisc;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
ic->ic_node_alloc = ath_node_alloc;
do proper subclassing of node free+copy; the previous hack falls apart when the 802.11 layer does useful work Obtained from: madwifi
2004-04-03 00:06:23 +00:00
sc->sc_node_free = ic->ic_node_free;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
ic->ic_node_free = ath_node_free;
Break out the node cleanup and node free path, in preparation for doing software TX queue management. The software queued TX frames will be freed by the new cleanup function. Sponsored by: Hobnob, Inc.
2011-11-08 18:48:26 +00:00
sc->sc_node_cleanup = ic->ic_node_cleanup;
ic->ic_node_cleanup = ath_node_cleanup;
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
ic->ic_node_getsignal = ath_node_getsignal;
ic->ic_scan_start = ath_scan_start;
ic->ic_scan_end = ath_scan_end;
ic->ic_set_channel = ath_set_channel;
* Since the API changed along the -CURRENT path (december 2011), add a FreeBSD_version check. It should work fine for compiling on -HEAD, 9.x and 8.x. * Conditionally compile the 11n options only when 11n is enabled. The above changes allow the ath(4) driver to compile and run on 8.1-RELEASE (Hi old PC-BSD!) but with the 11n stuff disabled. I've done a test against the net80211 and tools in 8.1-RELEASE. The NIC used in testing is the AR2427 in an EEEPC. Just to be clear - this change is to allow the -HEAD ath/hal/rate code to run on 9.x _and_ 8.x with no source changes. However, when running on earlier kernels, it should only be used for legacy mode. (Don't define ATH_ENABLE_11N.)
2012-04-10 06:25:11 +00:00
#ifdef ATH_ENABLE_11N
Introduce TX aggregation and software TX queue management for Atheros AR5416 and later wireless devices. This is a very large commit - the complete history can be found in the user/adrian/if_ath_tx branch. Legacy (ie, pre-AR5416) devices also use the per-software TXQ support and (in theory) can support non-aggregation ADDBA sessions. However, the net80211 stack doesn't currently support this. In summary: TX path: * queued frames normally go onto a per-TID, per-node queue * some special frames (eg ADDBA control frames) are thrown directly onto the relevant hardware queue so they can go out before any software queued frames are queued. * Add methods to create, suspend, resume and tear down an aggregation session. * Add in software retransmission of both normal and aggregate frames. * Add in completion handling of aggregate frames, including parsing the block ack bitmap provided by the hardware. * Write an aggregation function which can assemble frames into an aggregate based on the selected rate control and channel configuration. * The per-TID queues are locked based on their target hardware TX queue. This matches what ath9k/atheros does, and thus simplified porting over some of the aggregation logic. * When doing TX aggregation, stick the sequence number allocation in the TX path rather than net80211 TX path, and protect it by the TXQ lock. Rate control: * Delay rate control selection until the frame is about to be queued to the hardware, so retried frames can have their rate control choices changed. Frames with a static rate control selection have that applied before each TX, just to simplify the TX path (ie, not have "static" and "dynamic" rate control special cased.) * Teach ath_rate_sample about aggregates - both completion and errors. * Add an EWMA for tracking what the current "good" MCS rate is based on failure rates. Misc: * Introduce a bunch of dirty hacks and workarounds so TID mapping and net80211 frame inspection can be kept out of the net80211 layer. Because of the way this code works (and it's from Atheros and Linux ath9k), there is a consistent, 1:1 mapping between TID and AC. So we need to ensure that frames going to a specific TID will _always_ end up on the right AC, and vice versa, or the completion/locking will simply get very confused. I plan on addressing this mess in the future. Known issues: * There is no BAR frame transmission just yet. A whole lot of tidying up needs to occur before BAR frame TX can occur in the "correct" place - ie, once the TID TX queue has been drained. * Interface reset/purge/etc results in frames in the TX and RX queues being removed. This creates holes in the sequence numbers being assigned and the TX/RX AMPDU code (on either side) just hangs. * There's no filtered frame support at the present moment, so stations going into power saving mode will simply have a number of frames dropped - likely resulting in a traffic "hang". * Raw frame TX is going to just not function with 11n aggregation. Likely this needs to be modified to always override the sequence number if the frame is going into an aggregation session. However, general raw frame injection currently doesn't work in general in net80211, so let's just ignore this for now until this is sorted out. * HT protection is just not implemented and won't be until the above is sorted out. In addition, the AR5416 has issues RTS protecting large aggregates (anything >8k), so the work around needs to be ported and tested. Thus, this will be put on hold until the above work is complete. * The rate control module 'sample' is the only currently supported module; onoe/amrr haven't been tested and have likely bit rotted a little. I'll follow up with some commits to make them work again for non-11n rates, but they won't be updated to handle 11n and aggregation. If someone wishes to do so then they're welcome to send along patches. * .. and "sample" doesn't really do a good job of 11n TX. Specifically, the metrics used (packet TX time and failure/success rates) isn't as useful for 11n. It's likely that it should be extended to take into account the aggregate throughput possible and then choose a rate which maximises that. Ie, it may be acceptable for a higher MCS rate with a higher failure to be used if it gives a more acceptable throughput/latency then a lower MCS rate @ a lower error rate. Again, patches will be gratefully accepted. Because of this, ATH_ENABLE_11N is still not enabled by default. Sponsored by: Hobnob, Inc. Obtained from: Linux, Atheros
2011-11-08 22:43:13 +00:00
/* 802.11n specific - but just override anyway */
sc->sc_addba_request = ic->ic_addba_request;
sc->sc_addba_response = ic->ic_addba_response;
sc->sc_addba_stop = ic->ic_addba_stop;
sc->sc_bar_response = ic->ic_bar_response;
sc->sc_addba_response_timeout = ic->ic_addba_response_timeout;
ic->ic_addba_request = ath_addba_request;
ic->ic_addba_response = ath_addba_response;
ic->ic_addba_response_timeout = ath_addba_response_timeout;
ic->ic_addba_stop = ath_addba_stop;
ic->ic_bar_response = ath_bar_response;
* Since the API changed along the -CURRENT path (december 2011), add a FreeBSD_version check. It should work fine for compiling on -HEAD, 9.x and 8.x. * Conditionally compile the 11n options only when 11n is enabled. The above changes allow the ath(4) driver to compile and run on 8.1-RELEASE (Hi old PC-BSD!) but with the 11n stuff disabled. I've done a test against the net80211 and tools in 8.1-RELEASE. The NIC used in testing is the AR2427 in an EEEPC. Just to be clear - this change is to allow the -HEAD ath/hal/rate code to run on 9.x _and_ 8.x with no source changes. However, when running on earlier kernels, it should only be used for legacy mode. (Don't define ATH_ENABLE_11N.)
2012-04-10 06:25:11 +00:00
ic->ic_update_chw = ath_update_chw;
#endif /* ATH_ENABLE_11N */
[ath] initial station side quiet IE support. This implements hardware assisted quiet IE support. Quiet time is an optional interval on DFS channels (but doesn't have to be DFS only channels! sigh) where the station and AP can be quiet in order to allow for channel utilisation measurements. Typically that's stuff like radar detection, spectral scan, other-BSS frame sniffing, checking how busy the air is, etc. The hardware implements it as one of the generic timers, which is supplied a period, offset from the trigger period and duration to stay quiet. The AP can announce quiet time configurations which change, and so this code also tracks that. Implementation details: * track the current quiet time IE * compare the new one against the previous one - if only the TBTT counter changes, don't update things * If tbttcount=1 then program it into the hardware - that is when it is easiest to program the correct starting offset (one TBTT + configured offset). * .. later on check to see if it can be done on any tbttcount * If the IE goes away then remove the quiet timer and clear the config * Upon reset, state change, new beacon - clear quiet time IE and just let it resync from the next beacon. History: This was work done initially by sibridgetech.com in 2011/2012/2013 as part of some FreeBSD wifi DFS contracting work they had for a third party. They implemented the net80211 quiet time IE pieces and had some test code for the station side which didn't entirely use the timers correctly. I figured out how to use the timers correctly without stopping/starting the transmit DMA engine each time. When done correctly, the timer just needs to be programmed once and left alone until the next configuration change. So, thanks to Himali Patel and Parthiv Shah for their work way back then. I finally figured it out and finished it! TODO: * Now, I'd rather net80211 did the quiet time IE tracking and parsing, pushing configurations into the driver is needed. I'll look at doing that in a subsequent update. * This doesn't handle multiple quiet time IEs, which will currently just mess things up. I'll look into supporting that in the future (at least by only obeying "one" of them, and then ignoring subsequent IEs in a beacon/probe frame.) * This also implements the STA side and not the AP side - the AP side will come later, and involves taking various other intervals into account (eg the beacon offset for multi-VAP modes, the SWBA time, etc, etc) as well as obtaining the configuration when a beacon is configured/generated rather than "hearing" an IE. * .. investigate supporting quiet IE in mesh, tdma, ibss modes * .. investigate supporting quiet IE for non-DFS channels (so this can be done for say, 2GHz channels.) * Chances are i should commit NULL methods for the ar5210, ar5211 HALs.. Tested: * AR9380, STA mode - announcing quiet, removing quiet, changing quite time config, whilst doing iperf testing; * AR9380, AP mode.
2017-02-09 23:15:11 +00:00
ic->ic_set_quiet = ath_set_quiet_ie;
* Since the API changed along the -CURRENT path (december 2011), add a FreeBSD_version check. It should work fine for compiling on -HEAD, 9.x and 8.x. * Conditionally compile the 11n options only when 11n is enabled. The above changes allow the ath(4) driver to compile and run on 8.1-RELEASE (Hi old PC-BSD!) but with the 11n stuff disabled. I've done a test against the net80211 and tools in 8.1-RELEASE. The NIC used in testing is the AR2427 in an EEEPC. Just to be clear - this change is to allow the -HEAD ath/hal/rate code to run on 9.x _and_ 8.x with no source changes. However, when running on earlier kernels, it should only be used for legacy mode. (Don't define ATH_ENABLE_11N.)
2012-04-10 06:25:11 +00:00
Introduce an optional ath(4) radiotap vendor extension. This includes a few new fields in each RXed frame: * per chain RX RSSI (ctl and ext); * current RX chainmask; * EVM information; * PHY error code; * basic RX status bits (CRC error, PHY error, etc). This is primarily to allow me to do some userland PHY error processing for radar and spectral scan data. However since EVM and per-chain RSSI is provided, others may find it useful for a variety of tasks. The default is to not compile in the radiotap vendor extensions, primarily because tcpdump doesn't seem to handle the particular vendor extension layout I'm using, and I'd rather not break existing code out there that may be (badly) parsing the radiotap data. Instead, add the option 'ATH_ENABLE_RADIOTAP_VENDOR_EXT' to your kernel configuration file to enable these options.
2012-06-24 07:01:49 +00:00
#ifdef ATH_ENABLE_RADIOTAP_VENDOR_EXT
/*
* There's one vendor bitmap entry in the RX radiotap
* header; make sure that's taken into account.
*/
ieee80211_radiotap_attachv(ic,
&sc->sc_tx_th.wt_ihdr, sizeof(sc->sc_tx_th), 0,
ATH_TX_RADIOTAP_PRESENT,
&sc->sc_rx_th.wr_ihdr, sizeof(sc->sc_rx_th), 1,
ATH_RX_RADIOTAP_PRESENT);
#else
/*
* No vendor bitmap/extensions are present.
*/
Overhaul monitor mode handling: o replace DLT_IEEE802_11 support in net80211 with DLT_IEEE802_11_RADIO and remove explicit bpf support from wireless drivers; drivers now use ieee80211_radiotap_attach to setup shared data structures that hold the radiotap header for each packet tx/rx o remove rx timestamp from the rx path; it was used only by the tdma support for debugging and was mostly useless due to it being 32-bits and mostly unavailable o track DLT_IEEE80211_RADIO bpf attachments and maintain per-vap and per-com state when there are active taps o track the number of monitor mode vaps o use bpf tap and monitor mode vap state to decide when to collect radiotap state and dispatch frames; drivers no longer explicitly directly check bpf state or use bpf calls to tap frames o handle radiotap state updates on channel change in net80211; drivers should not do this (unless they bypass net80211 which is almost always a mistake) o update various drivers to be more consistent/correct in handling radiotap o update ral to include TSF in radiotap'd frames o add promisc mode callback to wi Reviewed by: cbzimmer, rpaulo, thompsa
2009-05-20 20:00:40 +00:00
ieee80211_radiotap_attach(ic,
&sc->sc_tx_th.wt_ihdr, sizeof(sc->sc_tx_th),
ATH_TX_RADIOTAP_PRESENT,
&sc->sc_rx_th.wr_ihdr, sizeof(sc->sc_rx_th),
ATH_RX_RADIOTAP_PRESENT);
Introduce an optional ath(4) radiotap vendor extension. This includes a few new fields in each RXed frame: * per chain RX RSSI (ctl and ext); * current RX chainmask; * EVM information; * PHY error code; * basic RX status bits (CRC error, PHY error, etc). This is primarily to allow me to do some userland PHY error processing for radar and spectral scan data. However since EVM and per-chain RSSI is provided, others may find it useful for a variety of tasks. The default is to not compile in the radiotap vendor extensions, primarily because tcpdump doesn't seem to handle the particular vendor extension layout I'm using, and I'd rather not break existing code out there that may be (badly) parsing the radiotap data. Instead, add the option 'ATH_ENABLE_RADIOTAP_VENDOR_EXT' to your kernel configuration file to enable these options.
2012-06-24 07:01:49 +00:00
#endif /* ATH_ENABLE_RADIOTAP_VENDOR_EXT */
Overhaul monitor mode handling: o replace DLT_IEEE802_11 support in net80211 with DLT_IEEE802_11_RADIO and remove explicit bpf support from wireless drivers; drivers now use ieee80211_radiotap_attach to setup shared data structures that hold the radiotap header for each packet tx/rx o remove rx timestamp from the rx path; it was used only by the tdma support for debugging and was mostly useless due to it being 32-bits and mostly unavailable o track DLT_IEEE80211_RADIO bpf attachments and maintain per-vap and per-com state when there are active taps o track the number of monitor mode vaps o use bpf tap and monitor mode vap state to decide when to collect radiotap state and dispatch frames; drivers no longer explicitly directly check bpf state or use bpf calls to tap frames o handle radiotap state updates on channel change in net80211; drivers should not do this (unless they bypass net80211 which is almost always a mistake) o update various drivers to be more consistent/correct in handling radiotap o update ral to include TSF in radiotap'd frames o add promisc mode callback to wi Reviewed by: cbzimmer, rpaulo, thompsa
2009-05-20 20:00:40 +00:00
Disable my software queue TIM and PS handling for now. ps-poll is totally broken in its current form. This should unbreak things enough to let people use PS-POLL devices, but leave it in place for me to finish PS-POLL handling.
2012-11-07 06:29:45 +00:00
/*
* Setup the ALQ logging if required
*/
Don't compile in my (not yet committed) ath_alq code unless ATH_DEBUG_ALQ is defined. This will unbreak ATH_DEBUG builds.
2012-11-07 16:34:09 +00:00
#ifdef ATH_DEBUG_ALQ
Disable my software queue TIM and PS handling for now. ps-poll is totally broken in its current form. This should unbreak things enough to let people use PS-POLL devices, but leave it in place for me to finish PS-POLL handling.
2012-11-07 06:29:45 +00:00
if_ath_alq_init(&sc->sc_alq, device_get_nameunit(sc->sc_dev));
ALQ logging enhancements: * upon setup, tell the alq code what the chip information is. * add TX/RX path logging for legacy chips. * populate the tx/rx descriptor length fields with a best-estimate. It's overly big (96 bytes when AH_SUPPORT_AR5416 is enabled) but it'll do for now. Whilst I'm here, add CURVNET_RESTORE() here during probe/attach as a partial solution to fixing crashes during attach when the attach fails. There are other attach failures that I have to deal with; those'll come later.
2012-11-16 19:57:16 +00:00
if_ath_alq_setcfg(&sc->sc_alq,
sc->sc_ah->ah_macVersion,
sc->sc_ah->ah_macRev,
sc->sc_ah->ah_phyRev,
sc->sc_ah->ah_magic);
Disable my software queue TIM and PS handling for now. ps-poll is totally broken in its current form. This should unbreak things enough to let people use PS-POLL devices, but leave it in place for me to finish PS-POLL handling.
2012-11-07 06:29:45 +00:00
#endif
o move ath_sysctlattach down so variables it depends on are setup o use any fixed tx antenna for beacons transmitted in adhoc mode Submitted by: David Young MFC after: 3 days
2005-07-23 05:34:29 +00:00
/*
* Setup dynamic sysctl's now that country code and
* regdomain are available from the hal.
*/
ath_sysctlattach(sc);
Export ath stats via snmp, rather than requiring a debugging interface and "athstats".
2010-08-14 14:18:02 +00:00
ath_sysctl_stats_attach(sc);
Break out most of the HAL related tweaks into a per-HAL instance, rather than global variables. This specifically allows for debugging to be enabled per-NIC, rather than globally. Since the ath driver doesn't know about AH_DEBUG, and to keep the ABI consistent regardless of whether AH_DEBUG is enabled or not, enable the debug parameter always but only conditionally compile in the debug methods if needed. The ALQ support is currently still global pending some brainstorming. Submitted by: ssgriffonuser@gmail.com Reviewed by: adrian, bschmidt
2011-06-23 02:38:36 +00:00
ath_sysctl_hal_attach(sc);
Add support for the experimental radiotap capture format. With this we no longer need the debugging code to dump packets.
2003-09-05 22:22:49 +00:00
Update with last year of work.
2004-12-08 17:34:36 +00:00
if (bootverbose)
ieee80211_announce(ic);
ath_announce(sc);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
/*
* Put it to sleep for now.
*/
ATH_LOCK(sc);
[ath] force wake the hardware if we see a missed beacon. This adds a workaround to incorrectly behaving APs (ie, FreeBSD APs) which don't beacon out exactly when they should (at TBTT multiples of beacon intervals.) It forces the hardware awake (but leaves it in network-sleep so self generated frames still state that the hardware is asleep!) and will remain awake until the next sleep transition driven by net80211. That way if the beacons are just at the wrong interval, we get a much better chance of hearing more consecutive beacons before we go to sleep, thus not constantly disconnecting. Tested: * AR9485, STA mode, against a misbehaving FreeBSD AP.
2016-11-28 17:54:29 +00:00
ath_power_setpower(sc, HAL_PM_FULL_SLEEP, 1);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ATH_UNLOCK(sc);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
return 0;
cleanup descriptor allocation if attach fails Obtained from: madwifi
2004-04-02 23:47:39 +00:00
bad2:
Update with last year of work.
2004-12-08 17:34:36 +00:00
ath_tx_cleanup(sc);
cleanup descriptor allocation if attach fails Obtained from: madwifi
2004-04-02 23:47:39 +00:00
ath_desc_free(sc);
Begin separating out the TX DMA setup in preparation for TX EDMA support. * Introduce TX DMA setup/teardown methods, mirroring what's done in the RX path. Although the TX DMA descriptor is setup via ath_desc_alloc() / ath_desc_free(), there TX status descriptor ring will be allocated in this path. * Remove some of the TX EDMA capability probing from the RX path and push it into the new TX EDMA path.
2012-07-23 03:52:18 +00:00
ath_txdma_teardown(sc);
Further preparations for the RX EDMA support. Break out the DMA descriptor setup/teardown code into a method. The EDMA RX code doesn't allocate descriptors, just ath_buf entries.
2012-07-09 08:37:59 +00:00
ath_rxdma_teardown(sc);
[ath] fix "doing stuff before wakeup" warning; add comments for ACK/CTS handling during DFS/PASSIVE channels * Although the hardware is awake, the power state handling doesn't think so. So just explicitly wake it up early in setup so ath_hal calls don't complain. * We shouldn't be transmitting or ACKing frames during DFS CAC or on passive channels before we hear a beacon. So, start laying down comments in the places where this work has to be done. Note: * The main bit missing from finishing this particular bit of work is a state call to transition a VAP from passive to non-passive when a beacon is heard. CAC is easy, it's an interface state. So, I'll go and add a method to control that soon.
2017-01-27 01:17:00 +00:00
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
bad:
if (ah)
ath_hal_detach(ah);
sc->sc_invalid = 1;
return error;
}
int
ath_detach(struct ath_softc *sc)
{
Correct spelling of reseting (found while researching the "bb hang detected" messages that are plaguing me). While I'm here, delete trailing whitespace.
2010-02-19 18:23:45 +00:00
/*
Update with last year of work.
2004-12-08 17:34:36 +00:00
* NB: the order of these is important:
close a race on detach by reordering bpfdetach and taskqueue_free
2008-05-28 23:55:11 +00:00
* o stop the chip so no more interrupts will fire
Update with last year of work.
2004-12-08 17:34:36 +00:00
* o call the 802.11 layer before detaching the hal to
* insure callbacks into the driver to delete global
* key cache entries can be handled
close a race on detach by reordering bpfdetach and taskqueue_free
2008-05-28 23:55:11 +00:00
* o free the taskqueue which drains any pending tasks
Update with last year of work.
2004-12-08 17:34:36 +00:00
* o reclaim the tx queue data structures after calling
* the 802.11 layer as we'll get called back to reclaim
* node state and potentially want to use them
* o to cleanup the tx queues the hal is called, so detach
* it last
* Other than that, it's straightforward...
*/
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
/*
* XXX Wake the hardware up first. ath_stop() will still
* wake it up first, but I'd rather do it here just to
* ensure it's awake.
*/
ATH_LOCK(sc);
ath_power_set_power_state(sc, HAL_PM_AWAKE);
[ath] force wake the hardware if we see a missed beacon. This adds a workaround to incorrectly behaving APs (ie, FreeBSD APs) which don't beacon out exactly when they should (at TBTT multiples of beacon intervals.) It forces the hardware awake (but leaves it in network-sleep so self generated frames still state that the hardware is asleep!) and will remain awake until the next sleep transition driven by net80211. That way if the beacons are just at the wrong interval, we get a much better chance of hearing more consecutive beacons before we go to sleep, thus not constantly disconnecting. Tested: * AR9485, STA mode, against a misbehaving FreeBSD AP.
2016-11-28 17:54:29 +00:00
ath_power_setpower(sc, HAL_PM_AWAKE, 1);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
/*
* Stop things cleanly.
*/
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
ath_stop(sc);
ATH_UNLOCK(sc);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
ieee80211_ifdetach(&sc->sc_ic);
close a race on detach by reordering bpfdetach and taskqueue_free
2008-05-28 23:55:11 +00:00
taskqueue_free(sc->sc_tq);
add tx99 hooks MFC after: 2 weeks
2006-02-09 21:28:11 +00:00
#ifdef ATH_TX99_DIAG
if (sc->sc_tx99 != NULL)
sc->sc_tx99->detach(sc->sc_tx99);
#endif
Update with last year of work.
2004-12-08 17:34:36 +00:00
ath_rate_detach(sc->sc_rc);
Don't compile in my (not yet committed) ath_alq code unless ATH_DEBUG_ALQ is defined. This will unbreak ATH_DEBUG builds.
2012-11-07 16:34:09 +00:00
#ifdef ATH_DEBUG_ALQ
Disable my software queue TIM and PS handling for now. ps-poll is totally broken in its current form. This should unbreak things enough to let people use PS-POLL devices, but leave it in place for me to finish PS-POLL handling.
2012-11-07 06:29:45 +00:00
if_ath_alq_tidyup(&sc->sc_alq);
#endif
Migrate the LNA mixing diversity machinery from the AR9285 HAL to the driver. The AR9485 chip and AR933x SoC both implement LNA diversity. There are a few extra things that need to happen before this can be flipped on for those chips (mostly to do with setting up the different bias values and LNA1/LNA2 RSSI differences) but the first stage is putting this code into the driver layer so it can be reused. This has the added benefit of making it easier to expose configuration options and diagnostic information via the ioctl API. That's not yet being done but it sure would be nice to do so. Tested: * AR9285, with LNA diversity enabled * AR9285, with LNA diversity disabled in EEPROM
2013-06-12 14:52:57 +00:00
ath_lna_div_detach(sc);
Bring over the initial static bluetooth coexistence configuration for the WB195 combo NIC - an AR9285 w/ an AR3011 USB bluetooth NIC. The AR3011 is wired up using a 3-wire coexistence scheme to the AR9285. The code in if_ath_btcoex.c sets up the initial hardware mapping and coexistence configuration. There's nothing special about it - it's static; it doesn't try to configure bluetooth / MAC traffic priorities or try to figure out what's actually going on. It's enough to stop basic bluetooth traffic from causing traffic stalls and diassociation from the wireless network. To use this code, you must have the above NIC. No, it won't work for the AR9287+AR3012, nor the AR9485, AR9462 or AR955x combo cards. Then you set a kernel hint before boot or before kldload, where 'X' is the unit number of your AR9285 NIC: # kenv hint.ath.X.btcoex_profile=wb195 This will then appear in your boot messages: [100482] athX: Enabling WB195 BTCOEX This code is going to evolve pretty quickly (well, depending upon my spare time) so don't assume the btcoex API is going to stay stable. In order to use the bluetooth side, you must also load in firmware using ath3kfw and the binary firmware file (ath3k-1.fw in my case.) Tested: * AR9280, no interference * WB195 - AR9285 + AR3011 combo; STA mode; basic bluetooth inquiries were enough to cause traffic stalls and disassociations. This has stopped with the btcoex profile code. TODO: * Importantly - the AR9285 needs ASPM disabled if bluetooth coexistence is enabled. No, I don't know why. It's likely some kind of bug to do with the AR3011 sending bluetooth coexistence signals whilst the device is asleep. Since we don't actually sleep the MAC just yet, it shouldn't be a problem. That said, to be totally correct: + ASPM should be disabled - upon attach and wakeup + The PCIe powersave HAL code should never be called Look at what the ath9k driver does for inspiration. * Add WB197 (AR9287+AR3012) support * Add support for the AR9485, which is another combo like the AR9285 * The later NICs have a different signaling mechanism between the MAC and the bluetooth device; I haven't even begun to experiment with making that HAL code work. But it should be a lot more automatic. * The hardware can do much more interesting traffic weighting with bluetooth and wifi traffic. None of this is currently used. Ideally someone would code up something to watch the bluetooth traffic GPIO (via an interrupt) and then watch it go high/low; then figure out what the bluetooth traffic is and adjust things appropriately. * If I get the time I may add in some code to at least track this stuff and expose statistics. But it's up to someone else to experiment with the bluetooth coexistence support and add the interesting stuff (like "real" detection of bulk, audio, etc bluetooth traffic patterns and change wifi parameters appropriately - eg, maximum aggregate length, transmit power, using quiet time to control TX duty cycle, etc.)
2013-06-07 09:02:02 +00:00
ath_btcoex_detach(sc);
Add a new (skeleton) spectral mode manager module.
2013-01-02 03:59:02 +00:00
ath_spectral_detach(sc);
Flesh out the radar detection related operations for the ath driver. This is in no way a complete DFS/radar detection implementation! It merely creates an abstracted interface which allows for future development of the DFS radar detection code. Note: Net80211 already handles the bulk of the DFS machinery, all we need to do here is figure out that a radar event has occured and inform it as such. It then drives the DFS state engine for us. The "null" DFS radar detection module is included by default; it doesn't require a device line. This commit: * Adds a simple abstracted layer for radar detection state - sys/dev/ath/ath_dfs/; * Implements a null DFS module which doesn't do anything; (ie, implements the exact behaviour at the moment); * Adds hooks to the ath driver to process received radar events and gives the DFS module a chance to determine whether a radar has been detected. Obtained from: Atheros
2011-06-01 20:09:49 +00:00
ath_dfs_detach(sc);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
ath_desc_free(sc);
Add a missing call to ath_txdma_teardown().
2012-07-28 04:40:52 +00:00
ath_txdma_teardown(sc);
Further preparations for the RX EDMA support. Break out the DMA descriptor setup/teardown code into a method. The EDMA RX code doesn't allocate descriptors, just ath_buf entries.
2012-07-09 08:37:59 +00:00
ath_rxdma_teardown(sc);
Update with last year of work.
2004-12-08 17:34:36 +00:00
ath_tx_cleanup(sc);
close a race on detach by reordering bpfdetach and taskqueue_free
2008-05-28 23:55:11 +00:00
ath_hal_detach(sc->sc_ah); /* NB: sets chip in full sleep */
Add a temporary (for values of "temporary") work around for hotplug support with ath(4) and VIMAGE. Right now the VIMAGE code doesn't supply a default vnet context during: * hotplug attach; * any device detach. It special cases kldload/boot time probing (by setting the context to vnet0) but that doesn't occur when probing devices during a bus rescan - eg, adding a cardbus card. These will eventually go away when the VIMAGE support extends to providing default contexts to hotplug attach/detach.
2012-10-28 18:46:06 +00:00
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
return 0;
}
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
/*
* MAC address handling for multiple BSS on the same radio.
* The first vap uses the MAC address from the EEPROM. For
* subsequent vap's we set the U/L bit (bit 1) in the MAC
* address and use the next six bits as an index.
*/
static void
assign_address(struct ath_softc *sc, uint8_t mac[IEEE80211_ADDR_LEN], int clone)
{
int i;
if (clone && sc->sc_hasbmask) {
/* NB: we only do this if h/w supports multiple bssid */
for (i = 0; i < 8; i++)
if ((sc->sc_bssidmask & (1<<i)) == 0)
break;
if (i != 0)
mac[0] |= (i << 2)|0x2;
} else
i = 0;
sc->sc_bssidmask |= 1<<i;
sc->sc_hwbssidmask[0] &= ~mac[0];
if (i == 0)
sc->sc_nbssid0++;
}
static void
reclaim_address(struct ath_softc *sc, const uint8_t mac[IEEE80211_ADDR_LEN])
{
int i = mac[0] >> 2;
uint8_t mask;
if (i != 0 || --sc->sc_nbssid0 == 0) {
sc->sc_bssidmask &= ~(1<<i);
/* recalculate bssid mask from remaining addresses */
mask = 0xff;
for (i = 1; i < 8; i++)
if (sc->sc_bssidmask & (1<<i))
mask &= ~((i<<2)|0x2);
sc->sc_hwbssidmask[0] |= mask;
}
}
/*
* Assign a beacon xmit slot. We try to space out
* assignments so when beacons are staggered the
* traffic coming out of the cab q has maximal time
* to go out before the next beacon is scheduled.
*/
static int
assign_bslot(struct ath_softc *sc)
{
u_int slot, free;
free = 0;
for (slot = 0; slot < ATH_BCBUF; slot++)
if (sc->sc_bslot[slot] == NULL) {
if (sc->sc_bslot[(slot+1)%ATH_BCBUF] == NULL &&
sc->sc_bslot[(slot-1)%ATH_BCBUF] == NULL)
return slot;
free = slot;
/* NB: keep looking for a double slot */
}
return free;
}
static struct ieee80211vap *
Fix some net80211 enum nits: - ic_vap_create() uses an ieee80211_opmode argument - ieee80211_rate2media() takes an ieee80211_phymode argument - ieee80211_plcp2rate() takes an ieee80211_phytype argument - cast to enum ieee80211_protmode and ieee80211_roamingmode to silence compiler warnings Submitted by: arundel@
2011-12-17 10:23:17 +00:00
ath_vap_create(struct ieee80211com *ic, const char name[IFNAMSIZ], int unit,
enum ieee80211_opmode opmode, int flags,
const uint8_t bssid[IEEE80211_ADDR_LEN],
const uint8_t mac0[IEEE80211_ADDR_LEN])
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
{
Remove most of the references of ifp->if_softc and replace with references to ic->ic_softc. This is in preparation for gleb's ifnet work. Tested: * ath(4), STA mode * ath(4), hostap mode * make universe
2015-08-17 02:04:11 +00:00
struct ath_softc *sc = ic->ic_softc;
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
struct ath_vap *avp;
struct ieee80211vap *vap;
uint8_t mac[IEEE80211_ADDR_LEN];
Fix some net80211 enum nits: - ic_vap_create() uses an ieee80211_opmode argument - ieee80211_rate2media() takes an ieee80211_phymode argument - ieee80211_plcp2rate() takes an ieee80211_phytype argument - cast to enum ieee80211_protmode and ieee80211_roamingmode to silence compiler warnings Submitted by: arundel@
2011-12-17 10:23:17 +00:00
int needbeacon, error;
enum ieee80211_opmode ic_opmode;
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
Remove the unnecessary cast.
2015-10-05 05:24:16 +00:00
avp = malloc(sizeof(struct ath_vap), M_80211_VAP, M_WAITOK | M_ZERO);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
needbeacon = 0;
IEEE80211_ADDR_COPY(mac, mac0);
ATH_LOCK(sc);
o cleanup checks for which vap combinations are permitted and what to use for ic_opmode o fixes the case where creating ahdemo+wds vaps caused ic_opmode to be set to hostap
2009-05-06 23:49:55 +00:00
ic_opmode = opmode; /* default to opmode of new vap */
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
switch (opmode) {
case IEEE80211_M_STA:
o cleanup checks for which vap combinations are permitted and what to use for ic_opmode o fixes the case where creating ahdemo+wds vaps caused ic_opmode to be set to hostap
2009-05-06 23:49:55 +00:00
if (sc->sc_nstavaps != 0) { /* XXX only 1 for now */
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
device_printf(sc->sc_dev, "only 1 sta vap supported\n");
goto bad;
}
if (sc->sc_nvaps) {
/*
o cleanup checks for which vap combinations are permitted and what to use for ic_opmode o fixes the case where creating ahdemo+wds vaps caused ic_opmode to be set to hostap
2009-05-06 23:49:55 +00:00
* With multiple vaps we must fall back
* to s/w beacon miss handling.
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
*/
flags |= IEEE80211_CLONE_NOBEACONS;
}
o cleanup checks for which vap combinations are permitted and what to use for ic_opmode o fixes the case where creating ahdemo+wds vaps caused ic_opmode to be set to hostap
2009-05-06 23:49:55 +00:00
if (flags & IEEE80211_CLONE_NOBEACONS) {
/*
* Station mode w/o beacons are implemented w/ AP mode.
*/
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
ic_opmode = IEEE80211_M_HOSTAP;
o cleanup checks for which vap combinations are permitted and what to use for ic_opmode o fixes the case where creating ahdemo+wds vaps caused ic_opmode to be set to hostap
2009-05-06 23:49:55 +00:00
}
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
break;
case IEEE80211_M_IBSS:
if (sc->sc_nvaps != 0) { /* XXX only 1 for now */
device_printf(sc->sc_dev,
"only 1 ibss vap supported\n");
goto bad;
}
needbeacon = 1;
break;
case IEEE80211_M_AHDEMO:
Remove ATH_SUPPORT_TDMA and use IEEE80211_SUPPORT_TDMA instead. It doesn't make much sense to configure driver support w/o net80211. Note this means ath now depends on opt_wlan.h.
2009-03-30 19:23:49 +00:00
#ifdef IEEE80211_SUPPORT_TDMA
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
if (flags & IEEE80211_CLONE_TDMA) {
o cleanup checks for which vap combinations are permitted and what to use for ic_opmode o fixes the case where creating ahdemo+wds vaps caused ic_opmode to be set to hostap
2009-05-06 23:49:55 +00:00
if (sc->sc_nvaps != 0) {
device_printf(sc->sc_dev,
"only 1 tdma vap supported\n");
goto bad;
}
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
needbeacon = 1;
flags |= IEEE80211_CLONE_NOBEACONS;
}
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
/* fall thru... */
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
#endif
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
case IEEE80211_M_MONITOR:
if (sc->sc_nvaps != 0 && ic->ic_opmode != opmode) {
o cleanup checks for which vap combinations are permitted and what to use for ic_opmode o fixes the case where creating ahdemo+wds vaps caused ic_opmode to be set to hostap
2009-05-06 23:49:55 +00:00
/*
* Adopt existing mode. Adding a monitor or ahdemo
* vap to an existing configuration is of dubious
* value but should be ok.
*/
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
/* XXX not right for monitor mode */
ic_opmode = ic->ic_opmode;
o cleanup checks for which vap combinations are permitted and what to use for ic_opmode o fixes the case where creating ahdemo+wds vaps caused ic_opmode to be set to hostap
2009-05-06 23:49:55 +00:00
}
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
break;
case IEEE80211_M_HOSTAP:
Implementation of the upcoming Wireless Mesh standard, 802.11s, on the net80211 wireless stack. This work is based on the March 2009 D3.0 draft standard. This standard is expected to become final next year. This includes two main net80211 modules, ieee80211_mesh.c which deals with peer link management, link metric calculation, routing table control and mesh configuration and ieee80211_hwmp.c which deals with the actually routing process on the mesh network. HWMP is the mandatory routing protocol on by the mesh standard, but others, such as RA-OLSR, can be implemented. Authentication and encryption are not implemented. There are several scripts under tools/tools/net80211/scripts that can be used to test different mesh network topologies and they also teach you how to setup a mesh vap (for the impatient: ifconfig wlan0 create wlandev ... wlanmode mesh). A new build option is available: IEEE80211_SUPPORT_MESH and it's enabled by default on GENERIC kernels for i386, amd64, sparc64 and pc98. Drivers that support mesh networks right now are: ath, ral and mwl. More information at: http://wiki.freebsd.org/WifiMesh Please note that this work is experimental. Also, please note that bridging a mesh vap with another network interface is not yet supported. Many thanks to the FreeBSD Foundation for sponsoring this project and to Sam Leffler for his support. Also, I would like to thank Gateworks Corporation for sending me a Cambria board which was used during the development of this project. Reviewed by: sam Approved by: re (kensmith) Obtained from: projects/mesh11s
2009-07-11 15:02:45 +00:00
case IEEE80211_M_MBSS:
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
needbeacon = 1;
o cleanup checks for which vap combinations are permitted and what to use for ic_opmode o fixes the case where creating ahdemo+wds vaps caused ic_opmode to be set to hostap
2009-05-06 23:49:55 +00:00
break;
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
case IEEE80211_M_WDS:
o cleanup checks for which vap combinations are permitted and what to use for ic_opmode o fixes the case where creating ahdemo+wds vaps caused ic_opmode to be set to hostap
2009-05-06 23:49:55 +00:00
if (sc->sc_nvaps != 0 && ic->ic_opmode == IEEE80211_M_STA) {
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
device_printf(sc->sc_dev,
"wds not supported in sta mode\n");
goto bad;
}
o cleanup checks for which vap combinations are permitted and what to use for ic_opmode o fixes the case where creating ahdemo+wds vaps caused ic_opmode to be set to hostap
2009-05-06 23:49:55 +00:00
/*
* Silently remove any request for a unique
* bssid; WDS vap's always share the local
* mac address.
*/
flags &= ~IEEE80211_CLONE_BSSID;
if (sc->sc_nvaps == 0)
ic_opmode = IEEE80211_M_HOSTAP;
else
ic_opmode = ic->ic_opmode;
Fix something bogus deletion that got it during mesh commit. Approved by: re (implicit)
2009-07-11 16:02:06 +00:00
break;
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
default:
device_printf(sc->sc_dev, "unknown opmode %d\n", opmode);
goto bad;
}
/*
* Check that a beacon buffer is available; the code below assumes it.
*/
Migrate the STAILQ lists to TAILQs. A bunch of the 11n TX aggregation logic wants to traverse lists of buffers in various ways. In order to provide O(1) behaviour in this instance, use TAILQs. This does blow out the memory footprint and CPU cycles slightly for some of these operations. I may convert some of these back to STAILQs once the rest of the software transmit queue handling has been stabilised. Sponsored by: Hobnob, Inc.
2011-11-08 17:08:12 +00:00
if (needbeacon & TAILQ_EMPTY(&sc->sc_bbuf)) {
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
device_printf(sc->sc_dev, "no beacon buffer available\n");
goto bad;
}
/* STA, AHDEMO? */
[ath] Use the BSSID address logic for STA VAPs too. For DWDS VAPs on ath(4) we need to ensure that the STA vap and hostap VAP have different MAC addresses. If the STA code path doesn't utilise the address assign / reclaim path then it doesn't update the bitmap with which address was allocated. This should fix a bunch of corner issues I've been seeing with DWDS STA + AP VAPs that I was working around with manual MAC address assignment.
2018-02-07 09:37:22 +00:00
if (opmode == IEEE80211_M_HOSTAP || opmode == IEEE80211_M_MBSS || opmode == IEEE80211_M_STA) {
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
assign_address(sc, mac, flags & IEEE80211_CLONE_BSSID);
ath_hal_setbssidmask(sc->sc_ah, sc->sc_hwbssidmask);
}
vap = &avp->av_vap;
/* XXX can't hold mutex across if_alloc */
ATH_UNLOCK(sc);
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
error = ieee80211_vap_setup(ic, vap, name, unit, opmode, flags, bssid);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
ATH_LOCK(sc);
if (error != 0) {
device_printf(sc->sc_dev, "%s: error %d creating vap\n",
__func__, error);
goto bad2;
}
/* h/w crypto support */
vap->iv_key_alloc = ath_key_alloc;
vap->iv_key_delete = ath_key_delete;
vap->iv_key_set = ath_key_set;
vap->iv_key_update_begin = ath_key_update_begin;
vap->iv_key_update_end = ath_key_update_end;
/* override various methods */
avp->av_recv_mgmt = vap->iv_recv_mgmt;
vap->iv_recv_mgmt = ath_recv_mgmt;
vap->iv_reset = ath_reset_vap;
vap->iv_update_beacon = ath_beacon_update;
avp->av_newstate = vap->iv_newstate;
vap->iv_newstate = ath_newstate;
avp->av_bmiss = vap->iv_bmiss;
vap->iv_bmiss = ath_bmiss_vap;
Pause and unpause the software queues for a given node based on the net80211 node power save state. * Add an ATH_NODE_UNLOCK_ASSERT() check * Add a new node field - an_is_powersave * Pause/unpause the queue based on the node state * Attempt to handle net80211 concurrency issues so the queue doesn't get paused/unpaused more than once at a time from the net80211 power save code. Whilst here (and breaking my usual rule), set CLRDMASK when a queue is unpaused, regardless of whether the queue has some pending traffic. This means the first frame from that TID (now or later) will hvae CLRDMASK set. Also whilst here, bump the swretrymax counters whenever the filtered frames code expires a frame. Again, breaking my rule, but this is just a statistics thing rather than a functional change. This doesn't fix ps-poll (but it doesn't break it too much worse than it is at the present) or correcting the TID updates. That's next on the list. Tested: * AR9220 AP (Atheros AP96 reference design) * Macbook Pro and LG Optimus 1 Android phone, both setting and clearing power save state (but not using PS-POLL.)
2012-10-03 23:23:45 +00:00
avp->av_node_ps = vap->iv_node_ps;
vap->iv_node_ps = ath_node_powersave;
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
avp->av_set_tim = vap->iv_set_tim;
vap->iv_set_tim = ath_node_set_tim;
Implement my first cut at "correct" node power-save and PS-POLL support. This implements PS-POLL awareness i nthe * Implement frame "leaking", which allows for a software queue to be scheduled even though it's asleep * Track whether a frame has been leaked or not * Leak out a single non-AMPDU frame when transmitting aggregates * Queue BAR frames if the node is asleep * Direct-dispatch the rest of control and management frames. This allows for things like re-association to occur (which involves sending probe req/resp as well as assoc request/response) when the node is asleep and then tries reassociating. * Limit how many frames can set in the software node queue whilst the node is asleep. net80211 is already buffering frames for us so this is mostly just paranoia. * Add a PS-POLL method which leaks out a frame if there's something in the software queue, else it calls net80211's ps-poll routine. Since the ath PS-POLL routine marks the node as having a single frame to leak, either a software queued frame would leak, OR the next queued frame would leak. The next queued frame could be something from the net80211 power save queue, OR it could be a NULL frame from net80211. TODO: * Don't transmit further BAR frames (eg via a timeout) if the node is currently asleep. Otherwise we may end up exhausting management frames due to the lots of queued BAR frames. I may just undo this bit later on and direct-dispatch BAR frames even if the node is asleep. * It would be nice to burst out a single A-MPDU frame if both ends support this. I may end adding a FreeBSD IE soon to negotiate this power save behaviour. * I should make STAs timeout of power save mode if they've been in power save for more than a handful of seconds. This way cards that get "stuck" in power save mode don't stay there for the "inactivity" timeout in net80211. * Move the queue depth check into the driver layer (ath_start / ath_transmit) rather than doing it in the TX path. * There could be some naughty corner cases with ps-poll leaking. Specifically, if net80211 generates a NULL data frame whilst another transmitter sends a normal data frame out net80211 output / transmit, we need to ensure that the NULL data frame goes out first. This is one of those things that should occur inside the VAP/ic TX lock. Grr, more investigations to do.. Tested: * STA: AR5416, AR9280 * AP: AR5416, AR9280, AR9160
2013-05-15 18:33:05 +00:00
avp->av_recv_pspoll = vap->iv_recv_pspoll;
vap->iv_recv_pspoll = ath_node_recv_pspoll;
Set default A-MPDU density/size.
2011-05-30 14:57:00 +00:00
/* Set default parameters */
/*
* Anything earlier than some AR9300 series MACs don't
* support a smaller MPDU density.
*/
vap->iv_ampdu_density = IEEE80211_HTCAP_MPDUDENSITY_8;
/*
* All NICs can handle the maximum size, however
* AR5416 based MACs can only TX aggregates w/ RTS
* protection when the total aggregate size is <= 8k.
* However, for now that's enforced by the TX path.
*/
vap->iv_ampdu_rxmax = IEEE80211_HTCAP_MAXRXAMPDU_64K;
[ath] ensure both iv_ampdu_limit and iv_ampdu_rxmax is set. A recent change enforced the VAP limit as well as the peer limit. I now need to actually set iv_ampdu_limit or we don't transmit more than 8K sized aggregates. This restores the expected (suboptimal, but still much faster) behaviour. Tested: * AR9380, STA mode
2017-01-21 06:53:30 +00:00
vap->iv_ampdu_limit = IEEE80211_HTCAP_MAXRXAMPDU_64K;
Set default A-MPDU density/size.
2011-05-30 14:57:00 +00:00
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
avp->av_bslot = -1;
if (needbeacon) {
/*
* Allocate beacon state and setup the q for buffered
* multicast frames. We know a beacon buffer is
* available because we checked above.
*/
Migrate the STAILQ lists to TAILQs. A bunch of the 11n TX aggregation logic wants to traverse lists of buffers in various ways. In order to provide O(1) behaviour in this instance, use TAILQs. This does blow out the memory footprint and CPU cycles slightly for some of these operations. I may convert some of these back to STAILQs once the rest of the software transmit queue handling has been stabilised. Sponsored by: Hobnob, Inc.
2011-11-08 17:08:12 +00:00
avp->av_bcbuf = TAILQ_FIRST(&sc->sc_bbuf);
TAILQ_REMOVE(&sc->sc_bbuf, avp->av_bcbuf, bf_list);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
if (opmode != IEEE80211_M_IBSS || !sc->sc_hasveol) {
/*
* Assign the vap to a beacon xmit slot. As above
* this cannot fail to find a free one.
*/
avp->av_bslot = assign_bslot(sc);
KASSERT(sc->sc_bslot[avp->av_bslot] == NULL,
("beacon slot %u not empty", avp->av_bslot));
sc->sc_bslot[avp->av_bslot] = vap;
sc->sc_nbcnvaps++;
}
if (sc->sc_hastsfadd && sc->sc_nbcnvaps > 0) {
/*
* Multple vaps are to transmit beacons and we
* have h/w support for TSF adjusting; enable
* use of staggered beacons.
*/
sc->sc_stagbeacons = 1;
}
ath_txq_init(sc, &avp->av_mcastq, ATH_TXQ_SWQ);
}
ic->ic_opmode = ic_opmode;
if (opmode != IEEE80211_M_WDS) {
sc->sc_nvaps++;
if (opmode == IEEE80211_M_STA)
sc->sc_nstavaps++;
track whether any mesh vaps are present to correctly setup the rx filter when, for example, an ap vap is created first Reviewed by: rpaulo Approved by: re (kib)
2009-07-21 19:01:04 +00:00
if (opmode == IEEE80211_M_MBSS)
sc->sc_nmeshvaps++;
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
}
switch (ic_opmode) {
case IEEE80211_M_IBSS:
sc->sc_opmode = HAL_M_IBSS;
break;
case IEEE80211_M_STA:
sc->sc_opmode = HAL_M_STA;
break;
case IEEE80211_M_AHDEMO:
Remove ATH_SUPPORT_TDMA and use IEEE80211_SUPPORT_TDMA instead. It doesn't make much sense to configure driver support w/o net80211. Note this means ath now depends on opt_wlan.h.
2009-03-30 19:23:49 +00:00
#ifdef IEEE80211_SUPPORT_TDMA
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
if (vap->iv_caps & IEEE80211_C_TDMA) {
sc->sc_tdma = 1;
/* NB: disable tsf adjust */
sc->sc_stagbeacons = 0;
}
/*
* NB: adhoc demo mode is a pseudo mode; to the hal it's
* just ap mode.
*/
/* fall thru... */
#endif
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
case IEEE80211_M_HOSTAP:
Implementation of the upcoming Wireless Mesh standard, 802.11s, on the net80211 wireless stack. This work is based on the March 2009 D3.0 draft standard. This standard is expected to become final next year. This includes two main net80211 modules, ieee80211_mesh.c which deals with peer link management, link metric calculation, routing table control and mesh configuration and ieee80211_hwmp.c which deals with the actually routing process on the mesh network. HWMP is the mandatory routing protocol on by the mesh standard, but others, such as RA-OLSR, can be implemented. Authentication and encryption are not implemented. There are several scripts under tools/tools/net80211/scripts that can be used to test different mesh network topologies and they also teach you how to setup a mesh vap (for the impatient: ifconfig wlan0 create wlandev ... wlanmode mesh). A new build option is available: IEEE80211_SUPPORT_MESH and it's enabled by default on GENERIC kernels for i386, amd64, sparc64 and pc98. Drivers that support mesh networks right now are: ath, ral and mwl. More information at: http://wiki.freebsd.org/WifiMesh Please note that this work is experimental. Also, please note that bridging a mesh vap with another network interface is not yet supported. Many thanks to the FreeBSD Foundation for sponsoring this project and to Sam Leffler for his support. Also, I would like to thank Gateworks Corporation for sending me a Cambria board which was used during the development of this project. Reviewed by: sam Approved by: re (kensmith) Obtained from: projects/mesh11s
2009-07-11 15:02:45 +00:00
case IEEE80211_M_MBSS:
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
sc->sc_opmode = HAL_M_HOSTAP;
break;
case IEEE80211_M_MONITOR:
sc->sc_opmode = HAL_M_MONITOR;
break;
default:
/* XXX should not happen */
break;
}
if (sc->sc_hastsfadd) {
/*
* Configure whether or not TSF adjust should be done.
*/
ath_hal_settsfadjust(sc->sc_ah, sc->sc_stagbeacons);
}
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
if (flags & IEEE80211_CLONE_NOBEACONS) {
/*
* Enable s/w beacon miss handling.
*/
sc->sc_swbmiss = 1;
}
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
ATH_UNLOCK(sc);
/* complete setup */
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
ieee80211_vap_attach(vap, ath_media_change, ieee80211_media_status,
mac);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
return vap;
bad2:
reclaim_address(sc, mac);
ath_hal_setbssidmask(sc->sc_ah, sc->sc_hwbssidmask);
bad:
free(avp, M_80211_VAP);
ATH_UNLOCK(sc);
return NULL;
}
static void
ath_vap_delete(struct ieee80211vap *vap)
{
struct ieee80211com *ic = vap->iv_ic;
Remove most of the references of ifp->if_softc and replace with references to ic->ic_softc. This is in preparation for gleb's ifnet work. Tested: * ath(4), STA mode * ath(4), hostap mode * make universe
2015-08-17 02:04:11 +00:00
struct ath_softc *sc = ic->ic_softc;
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
struct ath_hal *ah = sc->sc_ah;
struct ath_vap *avp = ATH_VAP(vap);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ATH_LOCK(sc);
ath_power_set_power_state(sc, HAL_PM_AWAKE);
ATH_UNLOCK(sc);
Add KTR tracepoints to the ath driver, in order to debug TX, RX and interrupt handling. Sponsored by: Hobnob, Inc.
2011-11-08 19:02:59 +00:00
DPRINTF(sc, ATH_DEBUG_RESET, "%s: called\n", __func__);
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
if (sc->sc_running) {
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
/*
* Quiesce the hardware while we remove the vap. In
* particular we need to reclaim all references to
* the vap state by any frames pending on the tx queues.
*/
ath_hal_intrset(ah, 0); /* disable interrupts */
In preparation for supporting 11n TX/RX properly, allow for TX queue draining and interface resets to be marked as ATH_RESET_DEFAULT, ATH_RESET_FULL, ATH_RESET_NOLOSS. Currently a reset is still a reset - ie, all tx/rx frames in the hardware queues are purged. This means that those frames will be lost to the 11n TX and RX aggregation state tracking, breaking AMPDU sessions. The (eventual) new semantics: * ATH_RESET_DEFAULT: full reset, this is the default for reset situations which I haven't yet figured out what they should be. * ATH_RESET_FULL: A full reset - for things such as channel changes. * ATH_RESET_NOLOSS: Don't flush TX/RX queues - handle pending RX frames and leave TX frames where they are; restart TX DMA from where it was.
2011-11-08 18:56:52 +00:00
/* XXX Do all frames from all vaps/nodes need draining here? */
Begin breaking apart the receive setup/stop path in preparation for more "correct" handling of frames in the RX pending queue during interface transitions. * ath_stoprecv() doesn't blank out the descriptor list - that's what ath_startrecv() does. So, change a comment to reflect that. * ath_stoprecv() does include a large (3ms) delay to let pending DMA complete. However, I'm under the impression that the stopdma hal method does check for a bit in the PCU to indicate DMA has stopped. So, to help with fast abort and restart, modify ath_stoprecv() to take a flag which indicates whether this is needed. * Modify the uses of ath_stoprecv() to pass in a flag to support the existing behaviour (ie, do the delay.) * Remove some duplicate PCU teardown code (which wasn't shutting down DMA, so it wasn't entirely correct..) and replace it with a call to ath_stoprecv(sc, 0) - which disables the DELAY call. The upshoot of this is now channel change doesn't simply drop completed frames on the floor, but instead it cleanly handles those frames. It still discards pending TX frames in the software and hardware queues as there's no (current) logic which forcibly recalculates the rate control information (or whether they're appropriate to be on the TX queue after a channel change), that'll come later. This still doesn't stop all the sources of queue stalls but it does tidy up some of the code duplication. To be complete, queue stalls now occur during normal behaviour - they only occur after some kind of broken behaviour causes an interface or node flush, upsetting the TX/RX BAW. Subsequent commits will incrementally fix these and other related issues. Sponsored by: Hobnob, Inc.
2011-11-19 21:05:31 +00:00
ath_stoprecv(sc, 1); /* stop recv side */
Shut down RX before TX - in theory, this should make the chip less likely to get upset. The Qualcomm Atheros reference design code goes through significant hacks to shut down RX before TX. It doesn't even try do do it in the driver - it actually makes the DMA stop routines in the HAL shut down RX before shutting down TX. So, to make this work for chips that aren't the AR9380 and later, do it in the driver. Shuffle the TX stop/drain HAL calls to be called *after* the RX stop HAL call. Tested: * AR5413 (STA) * AR5212 (STA) * AR5416 (STA) * AR9380 (STA) * AR9331 (AP) * AR9341 (AP) TODO: * test ar92xx series NIC and the AR5210/AR5211, in case there's something even odder about those.
2014-08-23 18:55:51 +00:00
ath_draintxq(sc, ATH_RESET_DEFAULT); /* stop hw xmit side */
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
}
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
/* .. leave the hardware awake for now. */
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
ieee80211_vap_detach(vap);
Some more various fixes, etc from my 11n branch. * When doing software TX queue handling and flush, it's possible that the deletion of a VAP (eg a STA shutdown) will queue a "STA Disassociate" frame whilst the interface is being deleted. The VAP is then deleted, and the frame ends up being queued to a node that is freed before it can be TX'ed. Things go awry at this point. There's no way at the present to avoid freeing the underlying node when the vap is being deleted. It's too late in the game. I suspect the real fix is to make sure the frame is software queued with no completion information somehow, so it doesn't link back to a node whose underlying VAP has been freed. For now, we'll just have to do this. * Add some comments showing what's going on. * Move an instance of the ATH_LOCK() around to protect the interrupt set. I'll worry about changing that to a PCU lock later on once the 11n code is in the tree. Sponsored by: Hobnob, Inc.
2011-11-08 19:18:34 +00:00
/*
* XXX Danger Will Robinson! Danger!
*
* Because ieee80211_vap_detach() can queue a frame (the station
* diassociate message?) after we've drained the TXQ and
* flushed the software TXQ, we will end up with a frame queued
* to a node whose vap is about to be freed.
*
* To work around this, flush the hardware/software again.
* This may be racy - the ath task may be running and the packet
* may be being scheduled between sw->hw txq. Tsk.
*
* TODO: figure out why a new node gets allocated somewhere around
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
* here (after the ath_tx_swq() call; and after an ath_stop()
Some more various fixes, etc from my 11n branch. * When doing software TX queue handling and flush, it's possible that the deletion of a VAP (eg a STA shutdown) will queue a "STA Disassociate" frame whilst the interface is being deleted. The VAP is then deleted, and the frame ends up being queued to a node that is freed before it can be TX'ed. Things go awry at this point. There's no way at the present to avoid freeing the underlying node when the vap is being deleted. It's too late in the game. I suspect the real fix is to make sure the frame is software queued with no completion information somehow, so it doesn't link back to a node whose underlying VAP has been freed. For now, we'll just have to do this. * Add some comments showing what's going on. * Move an instance of the ATH_LOCK() around to protect the interrupt set. I'll worry about changing that to a PCU lock later on once the 11n code is in the tree. Sponsored by: Hobnob, Inc.
2011-11-08 19:18:34 +00:00
* call!)
*/
ath_draintxq(sc, ATH_RESET_DEFAULT);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
ATH_LOCK(sc);
/*
* Reclaim beacon state. Note this must be done before
* the vap instance is reclaimed as we may have a reference
* to it in the buffer for the beacon frame.
*/
if (avp->av_bcbuf != NULL) {
if (avp->av_bslot != -1) {
sc->sc_bslot[avp->av_bslot] = NULL;
sc->sc_nbcnvaps--;
}
ath_beacon_return(sc, avp->av_bcbuf);
avp->av_bcbuf = NULL;
if (sc->sc_nbcnvaps == 0) {
sc->sc_stagbeacons = 0;
if (sc->sc_hastsfadd)
ath_hal_settsfadjust(sc->sc_ah, 0);
}
/*
* Reclaim any pending mcast frames for the vap.
*/
ath_tx_draintxq(sc, &avp->av_mcastq);
}
/*
* Update bookkeeping.
*/
if (vap->iv_opmode == IEEE80211_M_STA) {
sc->sc_nstavaps--;
if (sc->sc_nstavaps == 0 && sc->sc_swbmiss)
sc->sc_swbmiss = 0;
Implementation of the upcoming Wireless Mesh standard, 802.11s, on the net80211 wireless stack. This work is based on the March 2009 D3.0 draft standard. This standard is expected to become final next year. This includes two main net80211 modules, ieee80211_mesh.c which deals with peer link management, link metric calculation, routing table control and mesh configuration and ieee80211_hwmp.c which deals with the actually routing process on the mesh network. HWMP is the mandatory routing protocol on by the mesh standard, but others, such as RA-OLSR, can be implemented. Authentication and encryption are not implemented. There are several scripts under tools/tools/net80211/scripts that can be used to test different mesh network topologies and they also teach you how to setup a mesh vap (for the impatient: ifconfig wlan0 create wlandev ... wlanmode mesh). A new build option is available: IEEE80211_SUPPORT_MESH and it's enabled by default on GENERIC kernels for i386, amd64, sparc64 and pc98. Drivers that support mesh networks right now are: ath, ral and mwl. More information at: http://wiki.freebsd.org/WifiMesh Please note that this work is experimental. Also, please note that bridging a mesh vap with another network interface is not yet supported. Many thanks to the FreeBSD Foundation for sponsoring this project and to Sam Leffler for his support. Also, I would like to thank Gateworks Corporation for sending me a Cambria board which was used during the development of this project. Reviewed by: sam Approved by: re (kensmith) Obtained from: projects/mesh11s
2009-07-11 15:02:45 +00:00
} else if (vap->iv_opmode == IEEE80211_M_HOSTAP ||
[ath] Use the BSSID address logic for STA VAPs too. For DWDS VAPs on ath(4) we need to ensure that the STA vap and hostap VAP have different MAC addresses. If the STA code path doesn't utilise the address assign / reclaim path then it doesn't update the bitmap with which address was allocated. This should fix a bunch of corner issues I've been seeing with DWDS STA + AP VAPs that I was working around with manual MAC address assignment.
2018-02-07 09:37:22 +00:00
vap->iv_opmode == IEEE80211_M_STA ||
Implementation of the upcoming Wireless Mesh standard, 802.11s, on the net80211 wireless stack. This work is based on the March 2009 D3.0 draft standard. This standard is expected to become final next year. This includes two main net80211 modules, ieee80211_mesh.c which deals with peer link management, link metric calculation, routing table control and mesh configuration and ieee80211_hwmp.c which deals with the actually routing process on the mesh network. HWMP is the mandatory routing protocol on by the mesh standard, but others, such as RA-OLSR, can be implemented. Authentication and encryption are not implemented. There are several scripts under tools/tools/net80211/scripts that can be used to test different mesh network topologies and they also teach you how to setup a mesh vap (for the impatient: ifconfig wlan0 create wlandev ... wlanmode mesh). A new build option is available: IEEE80211_SUPPORT_MESH and it's enabled by default on GENERIC kernels for i386, amd64, sparc64 and pc98. Drivers that support mesh networks right now are: ath, ral and mwl. More information at: http://wiki.freebsd.org/WifiMesh Please note that this work is experimental. Also, please note that bridging a mesh vap with another network interface is not yet supported. Many thanks to the FreeBSD Foundation for sponsoring this project and to Sam Leffler for his support. Also, I would like to thank Gateworks Corporation for sending me a Cambria board which was used during the development of this project. Reviewed by: sam Approved by: re (kensmith) Obtained from: projects/mesh11s
2009-07-11 15:02:45 +00:00
vap->iv_opmode == IEEE80211_M_MBSS) {
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
reclaim_address(sc, vap->iv_myaddr);
ath_hal_setbssidmask(ah, sc->sc_hwbssidmask);
track whether any mesh vaps are present to correctly setup the rx filter when, for example, an ap vap is created first Reviewed by: rpaulo Approved by: re (kib)
2009-07-21 19:01:04 +00:00
if (vap->iv_opmode == IEEE80211_M_MBSS)
sc->sc_nmeshvaps--;
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
}
if (vap->iv_opmode != IEEE80211_M_WDS)
sc->sc_nvaps--;
Remove ATH_SUPPORT_TDMA and use IEEE80211_SUPPORT_TDMA instead. It doesn't make much sense to configure driver support w/o net80211. Note this means ath now depends on opt_wlan.h.
2009-03-30 19:23:49 +00:00
#ifdef IEEE80211_SUPPORT_TDMA
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
/* TDMA operation ceases when the last vap is destroyed */
if (sc->sc_tdma && sc->sc_nvaps == 0) {
sc->sc_tdma = 0;
sc->sc_swbmiss = 0;
}
#endif
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
free(avp, M_80211_VAP);
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
if (sc->sc_running) {
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
/*
* Restart rx+tx machines if still running (RUNNING will
* be reset if we just destroyed the last vap).
*/
if (ath_startrecv(sc) != 0)
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
device_printf(sc->sc_dev,
"%s: unable to restart recv logic\n", __func__);
restart tdma beacons after vap destroy
2009-06-02 21:11:26 +00:00
if (sc->sc_beacons) { /* restart beacons */
#ifdef IEEE80211_SUPPORT_TDMA
if (sc->sc_tdma)
ath_tdma_config(sc, NULL);
else
#endif
ath_beacon_config(sc, NULL);
}
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
ath_hal_intrset(ah, sc->sc_imask);
}
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
/* Ok, let the hardware asleep. */
ath_power_restore_power_state(sc);
Some more various fixes, etc from my 11n branch. * When doing software TX queue handling and flush, it's possible that the deletion of a VAP (eg a STA shutdown) will queue a "STA Disassociate" frame whilst the interface is being deleted. The VAP is then deleted, and the frame ends up being queued to a node that is freed before it can be TX'ed. Things go awry at this point. There's no way at the present to avoid freeing the underlying node when the vap is being deleted. It's too late in the game. I suspect the real fix is to make sure the frame is software queued with no completion information somehow, so it doesn't link back to a node whose underlying VAP has been freed. For now, we'll just have to do this. * Add some comments showing what's going on. * Move an instance of the ATH_LOCK() around to protect the interrupt set. I'll worry about changing that to a PCU lock later on once the 11n code is in the tree. Sponsored by: Hobnob, Inc.
2011-11-08 19:18:34 +00:00
ATH_UNLOCK(sc);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
}
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
void
ath_suspend(struct ath_softc *sc)
{
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
struct ieee80211com *ic = &sc->sc_ic;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
sc->sc_resume_up = ic->ic_nrunning != 0;
After some discussion with bschmidt@, it's likely better to just go through ieee80211_suspend_all() and ieee80211_resume_all(). All the other wireless drivers are doing that particular dance. PR: kern/169084
2012-06-17 03:08:33 +00:00
ieee80211_suspend_all(ic);
Cleanup power handling and fix suspend/resume: o do not put the chip into full sleep in ath_stop as it gains nothing and causes many parts to hang in ath_detach because we may touch the chip during vap teardown; this may also fix issues with unloading the module o add a note in ath_detach to explain ath_hal_detach puts the chip in low power mode; this is useful to know as it means unloading the module will place a pci device in the lowest possible power state o leave an #ifdef notyet marker for powering down the chip when a device is marked down; we can't do that until we handle all the ways the driver may be entered and touch the chip o fix resume by reloading the h/w key cache as it's been clobbered (for pci) by the socket being powered off; for station mode we directly stop+init the chip and then simulate a beacon miss to get the upper layers sync'd up; for other configs we must brute force stop+start the vaps so they go through the state machine
2008-05-29 00:10:48 +00:00
/*
* NB: don't worry about putting the chip in low power
* mode; pci will power off our socket on suspend and
cardbus -> CardBus
2010-01-03 23:31:58 +00:00
* CardBus detaches the device.
Fix up the EDMA RX setup path to correctly initialise and reset the RX FIFO. The original code was .. well, slightly more than incorrect. It showed up as stalled RX queues if the NIC needed to be frequently reinitialised (eg during scans.) This is inspired by work done by Matt Dillon over at the DragonflyBSD project. So: * track when EDMA RX has been stopped and when the MAC has been reset; * re-initialise the ring only after a reset; * track whether RX has been stopped/started - just for debugging now; * don't bother with the RX EOL stuff for EDMA - we don't need the interrupt at all. We also don't need to disable/enable the interrupt or start DMA - once new frames are pushed into the ring via the normal RX path, it'll just restart RX DMA on its own. Tested: * AR9380, STA mode * AR9380, AP mode * AR9485, STA mode * AR9462, STA mode
2014-09-20 01:22:17 +00:00
*
* XXX TODO: well, that's great, except for non-cardbus
* devices!
Cleanup power handling and fix suspend/resume: o do not put the chip into full sleep in ath_stop as it gains nothing and causes many parts to hang in ath_detach because we may touch the chip during vap teardown; this may also fix issues with unloading the module o add a note in ath_detach to explain ath_hal_detach puts the chip in low power mode; this is useful to know as it means unloading the module will place a pci device in the lowest possible power state o leave an #ifdef notyet marker for powering down the chip when a device is marked down; we can't do that until we handle all the ways the driver may be entered and touch the chip o fix resume by reloading the h/w key cache as it's been clobbered (for pci) by the socket being powered off; for station mode we directly stop+init the chip and then simulate a beacon miss to get the upper layers sync'd up; for other configs we must brute force stop+start the vaps so they go through the state machine
2008-05-29 00:10:48 +00:00
*/
Prepare for improved (read: pcie) suspend/resume support. * Flesh out the pcie disable method for 11n chips, as they were defaulting to the AR5212 (empty) PCIe disable method. * Add accessor macros for the HAL PCIe enable/disable calls. * Call disable on ath_suspend() * Call enable on ath_resume() NOTE: * This has nothing to do with the NIC sleep/run state - the NIC still will stay in network-run state rather than supporting network-sleep state. This is preparation work for supporting correct suspend/resume WARs for the 11n PCIe NICs. TODO: * It may be feasible at this point to keep the chip powered down during initial probe/attach and only power it up upon the first configure/reset pass. This however would require correct (for values of "correct") tracking of the NIC power configuration state from the driver and that just isn't attempted at the moment. Tested: * AR9280 on my Lenovo T60, but with no suspend/resume pass (yet).
2012-05-25 02:07:59 +00:00
oops - ath_hal_disablepcie is actually destined for another purpose, not to disable the PCIe PHY in prepration for reset. Extend the enablepci method to have a "poweroff" flag, which if equal to true means the hardware is about to go to sleep.
2012-05-25 05:01:27 +00:00
/*
Fix up the EDMA RX setup path to correctly initialise and reset the RX FIFO. The original code was .. well, slightly more than incorrect. It showed up as stalled RX queues if the NIC needed to be frequently reinitialised (eg during scans.) This is inspired by work done by Matt Dillon over at the DragonflyBSD project. So: * track when EDMA RX has been stopped and when the MAC has been reset; * re-initialise the ring only after a reset; * track whether RX has been stopped/started - just for debugging now; * don't bother with the RX EOL stuff for EDMA - we don't need the interrupt at all. We also don't need to disable/enable the interrupt or start DMA - once new frames are pushed into the ring via the normal RX path, it'll just restart RX DMA on its own. Tested: * AR9380, STA mode * AR9380, AP mode * AR9485, STA mode * AR9462, STA mode
2014-09-20 01:22:17 +00:00
* XXX This doesn't wait until all pending taskqueue
* items and parallel transmit/receive/other threads
* are running!
*/
ath_hal_intrset(sc->sc_ah, 0);
taskqueue_block(sc->sc_tq);
Migrate the callouts from using mutex locks to being mpsafe with the locks being held by the callers. Kill callout_drain() and use callout_stop().
2014-11-14 04:26:26 +00:00
ATH_LOCK(sc);
callout_stop(&sc->sc_cal_ch);
ATH_UNLOCK(sc);
Fix up the EDMA RX setup path to correctly initialise and reset the RX FIFO. The original code was .. well, slightly more than incorrect. It showed up as stalled RX queues if the NIC needed to be frequently reinitialised (eg during scans.) This is inspired by work done by Matt Dillon over at the DragonflyBSD project. So: * track when EDMA RX has been stopped and when the MAC has been reset; * re-initialise the ring only after a reset; * track whether RX has been stopped/started - just for debugging now; * don't bother with the RX EOL stuff for EDMA - we don't need the interrupt at all. We also don't need to disable/enable the interrupt or start DMA - once new frames are pushed into the ring via the normal RX path, it'll just restart RX DMA on its own. Tested: * AR9380, STA mode * AR9380, AP mode * AR9485, STA mode * AR9462, STA mode
2014-09-20 01:22:17 +00:00
/*
oops - ath_hal_disablepcie is actually destined for another purpose, not to disable the PCIe PHY in prepration for reset. Extend the enablepci method to have a "poweroff" flag, which if equal to true means the hardware is about to go to sleep.
2012-05-25 05:01:27 +00:00
* XXX ensure sc_invalid is 1
*/
/* Disable the PCIe PHY, complete with workarounds */
ath_hal_enablepcie(sc->sc_ah, 1, 1);
Cleanup power handling and fix suspend/resume: o do not put the chip into full sleep in ath_stop as it gains nothing and causes many parts to hang in ath_detach because we may touch the chip during vap teardown; this may also fix issues with unloading the module o add a note in ath_detach to explain ath_hal_detach puts the chip in low power mode; this is useful to know as it means unloading the module will place a pci device in the lowest possible power state o leave an #ifdef notyet marker for powering down the chip when a device is marked down; we can't do that until we handle all the ways the driver may be entered and touch the chip o fix resume by reloading the h/w key cache as it's been clobbered (for pci) by the socket being powered off; for station mode we directly stop+init the chip and then simulate a beacon miss to get the upper layers sync'd up; for other configs we must brute force stop+start the vaps so they go through the state machine
2008-05-29 00:10:48 +00:00
}
/*
* Reset the key cache since some parts do not reset the
* contents on resume. First we clear all entries, then
* re-load keys that the 802.11 layer assumes are setup
* in h/w.
*/
static void
ath_reset_keycache(struct ath_softc *sc)
{
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
struct ieee80211com *ic = &sc->sc_ic;
Cleanup power handling and fix suspend/resume: o do not put the chip into full sleep in ath_stop as it gains nothing and causes many parts to hang in ath_detach because we may touch the chip during vap teardown; this may also fix issues with unloading the module o add a note in ath_detach to explain ath_hal_detach puts the chip in low power mode; this is useful to know as it means unloading the module will place a pci device in the lowest possible power state o leave an #ifdef notyet marker for powering down the chip when a device is marked down; we can't do that until we handle all the ways the driver may be entered and touch the chip o fix resume by reloading the h/w key cache as it's been clobbered (for pci) by the socket being powered off; for station mode we directly stop+init the chip and then simulate a beacon miss to get the upper layers sync'd up; for other configs we must brute force stop+start the vaps so they go through the state machine
2008-05-29 00:10:48 +00:00
struct ath_hal *ah = sc->sc_ah;
int i;
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ATH_LOCK(sc);
ath_power_set_power_state(sc, HAL_PM_AWAKE);
Cleanup power handling and fix suspend/resume: o do not put the chip into full sleep in ath_stop as it gains nothing and causes many parts to hang in ath_detach because we may touch the chip during vap teardown; this may also fix issues with unloading the module o add a note in ath_detach to explain ath_hal_detach puts the chip in low power mode; this is useful to know as it means unloading the module will place a pci device in the lowest possible power state o leave an #ifdef notyet marker for powering down the chip when a device is marked down; we can't do that until we handle all the ways the driver may be entered and touch the chip o fix resume by reloading the h/w key cache as it's been clobbered (for pci) by the socket being powered off; for station mode we directly stop+init the chip and then simulate a beacon miss to get the upper layers sync'd up; for other configs we must brute force stop+start the vaps so they go through the state machine
2008-05-29 00:10:48 +00:00
for (i = 0; i < sc->sc_keymax; i++)
ath_hal_keyreset(ah, i);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ath_power_restore_power_state(sc);
ATH_UNLOCK(sc);
Cleanup power handling and fix suspend/resume: o do not put the chip into full sleep in ath_stop as it gains nothing and causes many parts to hang in ath_detach because we may touch the chip during vap teardown; this may also fix issues with unloading the module o add a note in ath_detach to explain ath_hal_detach puts the chip in low power mode; this is useful to know as it means unloading the module will place a pci device in the lowest possible power state o leave an #ifdef notyet marker for powering down the chip when a device is marked down; we can't do that until we handle all the ways the driver may be entered and touch the chip o fix resume by reloading the h/w key cache as it's been clobbered (for pci) by the socket being powered off; for station mode we directly stop+init the chip and then simulate a beacon miss to get the upper layers sync'd up; for other configs we must brute force stop+start the vaps so they go through the state machine
2008-05-29 00:10:48 +00:00
ieee80211_crypto_reload_keys(ic);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
Part #2 of the TX chainmask changes: * Remove ar5416UpdateChainmasks(); * Remove the TX chainmask override code from the ar5416 TX descriptor setup routines; * Write a driver method to calculate the current chainmask based on the operating mode and update the driver state; * Call the HAL chainmask method before calling ath_hal_reset(); * Use the currently configured chainmask in the TX descriptors rather than the hardware TX chainmasks. Tested: * AR5416, STA/AP mode - legacy and 11n modes
2013-02-25 22:45:02 +00:00
/*
* Fetch the current chainmask configuration based on the current
* operating channel and options.
*/
static void
ath_update_chainmasks(struct ath_softc *sc, struct ieee80211_channel *chan)
{
/*
* Set TX chainmask to the currently configured chainmask;
* the TX chainmask depends upon the current operating mode.
*/
sc->sc_cur_rxchainmask = sc->sc_rxchainmask;
if (IEEE80211_IS_CHAN_HT(chan)) {
sc->sc_cur_txchainmask = sc->sc_txchainmask;
} else {
sc->sc_cur_txchainmask = 1;
}
Add a debug statement to log the currently chosen chainmask configuration.
2013-04-19 08:06:45 +00:00
DPRINTF(sc, ATH_DEBUG_RESET,
"%s: TX chainmask is now 0x%x, RX is now 0x%x\n",
__func__,
sc->sc_cur_txchainmask,
sc->sc_cur_rxchainmask);
Part #2 of the TX chainmask changes: * Remove ar5416UpdateChainmasks(); * Remove the TX chainmask override code from the ar5416 TX descriptor setup routines; * Write a driver method to calculate the current chainmask based on the operating mode and update the driver state; * Call the HAL chainmask method before calling ath_hal_reset(); * Use the currently configured chainmask in the TX descriptors rather than the hardware TX chainmasks. Tested: * AR5416, STA/AP mode - legacy and 11n modes
2013-02-25 22:45:02 +00:00
}
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
void
ath_resume(struct ath_softc *sc)
{
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
struct ieee80211com *ic = &sc->sc_ic;
Cleanup power handling and fix suspend/resume: o do not put the chip into full sleep in ath_stop as it gains nothing and causes many parts to hang in ath_detach because we may touch the chip during vap teardown; this may also fix issues with unloading the module o add a note in ath_detach to explain ath_hal_detach puts the chip in low power mode; this is useful to know as it means unloading the module will place a pci device in the lowest possible power state o leave an #ifdef notyet marker for powering down the chip when a device is marked down; we can't do that until we handle all the ways the driver may be entered and touch the chip o fix resume by reloading the h/w key cache as it's been clobbered (for pci) by the socket being powered off; for station mode we directly stop+init the chip and then simulate a beacon miss to get the upper layers sync'd up; for other configs we must brute force stop+start the vaps so they go through the state machine
2008-05-29 00:10:48 +00:00
struct ath_hal *ah = sc->sc_ah;
HAL_STATUS status;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
oops - ath_hal_disablepcie is actually destined for another purpose, not to disable the PCIe PHY in prepration for reset. Extend the enablepci method to have a "poweroff" flag, which if equal to true means the hardware is about to go to sleep.
2012-05-25 05:01:27 +00:00
ath_hal_enablepcie(ah, 0, 0);
Prepare for improved (read: pcie) suspend/resume support. * Flesh out the pcie disable method for 11n chips, as they were defaulting to the AR5212 (empty) PCIe disable method. * Add accessor macros for the HAL PCIe enable/disable calls. * Call disable on ath_suspend() * Call enable on ath_resume() NOTE: * This has nothing to do with the NIC sleep/run state - the NIC still will stay in network-run state rather than supporting network-sleep state. This is preparation work for supporting correct suspend/resume WARs for the 11n PCIe NICs. TODO: * It may be feasible at this point to keep the chip powered down during initial probe/attach and only power it up upon the first configure/reset pass. This however would require correct (for values of "correct") tracking of the NIC power configuration state from the driver and that just isn't attempted at the moment. Tested: * AR9280 on my Lenovo T60, but with no suspend/resume pass (yet).
2012-05-25 02:07:59 +00:00
Cleanup power handling and fix suspend/resume: o do not put the chip into full sleep in ath_stop as it gains nothing and causes many parts to hang in ath_detach because we may touch the chip during vap teardown; this may also fix issues with unloading the module o add a note in ath_detach to explain ath_hal_detach puts the chip in low power mode; this is useful to know as it means unloading the module will place a pci device in the lowest possible power state o leave an #ifdef notyet marker for powering down the chip when a device is marked down; we can't do that until we handle all the ways the driver may be entered and touch the chip o fix resume by reloading the h/w key cache as it's been clobbered (for pci) by the socket being powered off; for station mode we directly stop+init the chip and then simulate a beacon miss to get the upper layers sync'd up; for other configs we must brute force stop+start the vaps so they go through the state machine
2008-05-29 00:10:48 +00:00
/*
* Must reset the chip before we reload the
* keycache as we were powered down on suspend.
*/
Part #2 of the TX chainmask changes: * Remove ar5416UpdateChainmasks(); * Remove the TX chainmask override code from the ar5416 TX descriptor setup routines; * Write a driver method to calculate the current chainmask based on the operating mode and update the driver state; * Call the HAL chainmask method before calling ath_hal_reset(); * Use the currently configured chainmask in the TX descriptors rather than the hardware TX chainmasks. Tested: * AR5416, STA/AP mode - legacy and 11n modes
2013-02-25 22:45:02 +00:00
ath_update_chainmasks(sc,
sc->sc_curchan != NULL ? sc->sc_curchan : ic->ic_curchan);
ath_hal_setchainmasks(sc->sc_ah, sc->sc_cur_txchainmask,
sc->sc_cur_rxchainmask);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
/* Ensure we set the current power state to on */
ATH_LOCK(sc);
Add tracking for self-generated frames when the VAP is in sleep state. The hardware can generate its own frames (eg RTS/CTS exchanges, other kinds of 802.11 management stuff, especially when it comes to 802.11n) and these also have PWRMGT flags. So if the VAP is asleep but the NIC is in force-awake for some reason, ensure that the self-generated frames have PWRMGT set to 1. Now, this (like basically everything to do with powersave) is still racy - the only way to guarantee that it's all actually consistent is to pause transmit and let it finish before transitioning the VAP to sleep, but this at least gets the basic method of tracking and updating the state debugged. Tested: * AR5416, STA mode * AR9380, STA mode
2014-05-02 00:48:09 +00:00
ath_power_setselfgen(sc, HAL_PM_AWAKE);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ath_power_set_power_state(sc, HAL_PM_AWAKE);
[ath] force wake the hardware if we see a missed beacon. This adds a workaround to incorrectly behaving APs (ie, FreeBSD APs) which don't beacon out exactly when they should (at TBTT multiples of beacon intervals.) It forces the hardware awake (but leaves it in network-sleep so self generated frames still state that the hardware is asleep!) and will remain awake until the next sleep transition driven by net80211. That way if the beacons are just at the wrong interval, we get a much better chance of hearing more consecutive beacons before we go to sleep, thus not constantly disconnecting. Tested: * AR9485, STA mode, against a misbehaving FreeBSD AP.
2016-11-28 17:54:29 +00:00
ath_power_setpower(sc, HAL_PM_AWAKE, 1);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ATH_UNLOCK(sc);
on resume ah_curchan may be NULL if no channel change has been done; workaround this by passing net80211's channel as we know it'll never be null Submitted by: trasz
2009-02-10 19:25:11 +00:00
ath_hal_reset(ah, sc->sc_opmode,
sc->sc_curchan != NULL ? sc->sc_curchan : ic->ic_curchan,
ath(4): begin fleshing out a "reset type" extension to force cold/warn resets. Right now the only way to force a cold reset is: * The HAL itself detects it's needed, or * The sysctl, setting all resets to be cold. Trouble is, cold resets take quite a bit longer than warm resets. However, there are situations where a cold reset would be nice. Specifically, after a stuck beacon, BB/MAC hang, stuck calibration results, etc. The vendor HAL has a separate method to set the reset reason (which is how HAL_RESET_BBPANIC gets set) which informs the HAL during the reset path why it occured. This is almost but not quite the same; I may eventually unify both approaches in the future. This commit just extends HAL_RESET_TYPE to include both status (eg BBPANIC) and type (eg do COLD.) None of the HAL code uses it yet though; that'll come later. It also is a big no-op in each HAL - I need to go teach each of the HALs about cold/warm reset through this path.
2015-11-09 15:59:42 +00:00
AH_FALSE, HAL_RESET_NORMAL, &status);
Cleanup power handling and fix suspend/resume: o do not put the chip into full sleep in ath_stop as it gains nothing and causes many parts to hang in ath_detach because we may touch the chip during vap teardown; this may also fix issues with unloading the module o add a note in ath_detach to explain ath_hal_detach puts the chip in low power mode; this is useful to know as it means unloading the module will place a pci device in the lowest possible power state o leave an #ifdef notyet marker for powering down the chip when a device is marked down; we can't do that until we handle all the ways the driver may be entered and touch the chip o fix resume by reloading the h/w key cache as it's been clobbered (for pci) by the socket being powered off; for station mode we directly stop+init the chip and then simulate a beacon miss to get the upper layers sync'd up; for other configs we must brute force stop+start the vaps so they go through the state machine
2008-05-29 00:10:48 +00:00
ath_reset_keycache(sc);
A few changes to make radar detection implementable in a hal_dfs/ module. * If sc->sc_dodfs is set to 1 by the ath_dfs_radar_enable(), set the relevant rx filter bit to begin receiving radar PHY errors. The HAL code already knows how to set the relevant error mask register to enable radar events. * Add a missing call to ath_dfs_radar_enable() after ath_hal_reset() * change ath_dfs_process_phyerr() to take a const char *buf for now, rather than a descriptor. This way it can get access to the packet buffer contents.
2011-06-04 04:14:59 +00:00
Fix up the EDMA RX setup path to correctly initialise and reset the RX FIFO. The original code was .. well, slightly more than incorrect. It showed up as stalled RX queues if the NIC needed to be frequently reinitialised (eg during scans.) This is inspired by work done by Matt Dillon over at the DragonflyBSD project. So: * track when EDMA RX has been stopped and when the MAC has been reset; * re-initialise the ring only after a reset; * track whether RX has been stopped/started - just for debugging now; * don't bother with the RX EOL stuff for EDMA - we don't need the interrupt at all. We also don't need to disable/enable the interrupt or start DMA - once new frames are pushed into the ring via the normal RX path, it'll just restart RX DMA on its own. Tested: * AR9380, STA mode * AR9380, AP mode * AR9485, STA mode * AR9462, STA mode
2014-09-20 01:22:17 +00:00
ATH_RX_LOCK(sc);
sc->sc_rx_stopped = 1;
sc->sc_rx_resetted = 1;
ATH_RX_UNLOCK(sc);
A few changes to make radar detection implementable in a hal_dfs/ module. * If sc->sc_dodfs is set to 1 by the ath_dfs_radar_enable(), set the relevant rx filter bit to begin receiving radar PHY errors. The HAL code already knows how to set the relevant error mask register to enable radar events. * Add a missing call to ath_dfs_radar_enable() after ath_hal_reset() * change ath_dfs_process_phyerr() to take a const char *buf for now, rather than a descriptor. This way it can get access to the packet buffer contents.
2011-06-04 04:14:59 +00:00
/* Let DFS at it in case it's a DFS channel */
ath_dfs_radar_enable(sc, ic->ic_curchan);
Add a new (skeleton) spectral mode manager module.
2013-01-02 03:59:02 +00:00
/* Let spectral at in case spectral is enabled */
ath_spectral_enable(sc, ic->ic_curchan);
Bring over the initial static bluetooth coexistence configuration for the WB195 combo NIC - an AR9285 w/ an AR3011 USB bluetooth NIC. The AR3011 is wired up using a 3-wire coexistence scheme to the AR9285. The code in if_ath_btcoex.c sets up the initial hardware mapping and coexistence configuration. There's nothing special about it - it's static; it doesn't try to configure bluetooth / MAC traffic priorities or try to figure out what's actually going on. It's enough to stop basic bluetooth traffic from causing traffic stalls and diassociation from the wireless network. To use this code, you must have the above NIC. No, it won't work for the AR9287+AR3012, nor the AR9485, AR9462 or AR955x combo cards. Then you set a kernel hint before boot or before kldload, where 'X' is the unit number of your AR9285 NIC: # kenv hint.ath.X.btcoex_profile=wb195 This will then appear in your boot messages: [100482] athX: Enabling WB195 BTCOEX This code is going to evolve pretty quickly (well, depending upon my spare time) so don't assume the btcoex API is going to stay stable. In order to use the bluetooth side, you must also load in firmware using ath3kfw and the binary firmware file (ath3k-1.fw in my case.) Tested: * AR9280, no interference * WB195 - AR9285 + AR3011 combo; STA mode; basic bluetooth inquiries were enough to cause traffic stalls and disassociations. This has stopped with the btcoex profile code. TODO: * Importantly - the AR9285 needs ASPM disabled if bluetooth coexistence is enabled. No, I don't know why. It's likely some kind of bug to do with the AR3011 sending bluetooth coexistence signals whilst the device is asleep. Since we don't actually sleep the MAC just yet, it shouldn't be a problem. That said, to be totally correct: + ASPM should be disabled - upon attach and wakeup + The PCIe powersave HAL code should never be called Look at what the ath9k driver does for inspiration. * Add WB197 (AR9287+AR3012) support * Add support for the AR9485, which is another combo like the AR9285 * The later NICs have a different signaling mechanism between the MAC and the bluetooth device; I haven't even begun to experiment with making that HAL code work. But it should be a lot more automatic. * The hardware can do much more interesting traffic weighting with bluetooth and wifi traffic. None of this is currently used. Ideally someone would code up something to watch the bluetooth traffic GPIO (via an interrupt) and then watch it go high/low; then figure out what the bluetooth traffic is and adjust things appropriately. * If I get the time I may add in some code to at least track this stuff and expose statistics. But it's up to someone else to experiment with the bluetooth coexistence support and add the interesting stuff (like "real" detection of bulk, audio, etc bluetooth traffic patterns and change wifi parameters appropriately - eg, maximum aggregate length, transmit power, using quiet time to control TX duty cycle, etc.)
2013-06-07 09:02:02 +00:00
/*
* Let bluetooth coexistence at in case it's needed for this channel
*/
ath_btcoex_enable(sc, ic->ic_curchan);
Enable the use of TDMA on an 802.11n channel (with aggregation disabled, of course.) There's a few things that needed to happen: * In case someone decides to set the beacon transmission rate to be at an MCS rate, use the MCS-aware version of the duration calculation to figure out how long the received beacon frame was. * If TxOP enforcing is available on the hardware and we're doing TDMA, enable it after a reset and set the TDMA guard interval to zero. This seems to behave fine. TODO: * Although I haven't yet seen packet loss, the PHY errors that would be triggered (specifically Transmit-Override-Receive) aren't enabled by the 11n HAL. I'll have to do some work to enable these PHY errors for debugging. What broke: * My recent changes to the TX queue handling has resulted in the driver not keeping the hardware queue properly filled when doing non-aggregate traffic. I have a patch to commit soon which fixes this situation (albeit by reminding me about how my ath driver locking isn't working out, sigh.) So if you want to test this without updating to the next set of patches that I commit, just bump the sysctl dev.ath.X.hwq_limit from 2 to 32. Tested: * AR5416 <-> AR5416, with ampdu disabled, HT40, 5GHz, MCS12+Short-GI. I saw 30mbit/sec in both directions using a bidirectional UDP test.
2013-05-21 18:02:54 +00:00
/*
* If we're doing TDMA, enforce the TXOP limitation for chips that
* support it.
*/
if (sc->sc_hasenforcetxop && sc->sc_tdma)
ath_hal_setenforcetxop(sc->sc_ah, 1);
else
ath_hal_setenforcetxop(sc->sc_ah, 0);
Setup the initial LED state on attach and resume. Some of the NICs I have here power up with the LEDs blinking, which is incorrect. The blinking should only occur when the NIC is attempting to associate. * On powerup, set the state to HAL_LED_INIT, which turns on the "Power" MAC LED but leaves the "Network" MAC LED the way it is. * On resume, also init it to HAL_LED_INIT unless in station mode, where it's forced to HAL_LED_RUN. Hopefully the net80211 state machine will call newstate() at some point, which will refiddle the LEDs. I've tested this on a handful of 11n and pre-11n NICs. The blinking behaviour is slightly more sensible now.
2011-12-26 06:25:12 +00:00
/* Restore the LED configuration */
ath_led_config(sc);
ath_hal_setledstate(ah, HAL_LED_INIT);
After some discussion with bschmidt@, it's likely better to just go through ieee80211_suspend_all() and ieee80211_resume_all(). All the other wireless drivers are doing that particular dance. PR: kern/169084
2012-06-17 03:08:33 +00:00
if (sc->sc_resume_up)
ieee80211_resume_all(ic);
Fix beacon transmission after a channel set. The DFS code was tickling the channel set directly whilst going through the state RUN -> CSA -> RUN. This only changed the channel; it didn't go via ath_reset(). However in this driver, a channel change always causes a chip reset, which resets the beacon timer configuration and interrupt setup. This meant that data would go out but as the beacon timers never fired, beacons would never be queued. The confusing part is that sometimes the state transition was RUN -> SCAN -> CAC -> RUN (with CSA being in there sometimes); going via SCAN would clear sc_beacons and thus the transition to RUN would reprogram beacon transmission. In case someone tries debugging why suspending a device currently beaconing (versus just RX'ing beacons which is what occurs in STA mode), add a silly comment which should hopefully land them at this commit message. The call to ath_hal_reset() will be clearing the beacon config and it may not be always reset.
2011-06-26 13:53:24 +00:00
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ATH_LOCK(sc);
ath_power_restore_power_state(sc);
ATH_UNLOCK(sc);
Fix beacon transmission after a channel set. The DFS code was tickling the channel set directly whilst going through the state RUN -> CSA -> RUN. This only changed the channel; it didn't go via ath_reset(). However in this driver, a channel change always causes a chip reset, which resets the beacon timer configuration and interrupt setup. This meant that data would go out but as the beacon timers never fired, beacons would never be queued. The confusing part is that sometimes the state transition was RUN -> SCAN -> CAC -> RUN (with CSA being in there sometimes); going via SCAN would clear sc_beacons and thus the transition to RUN would reprogram beacon transmission. In case someone tries debugging why suspending a device currently beaconing (versus just RX'ing beacons which is what occurs in STA mode), add a silly comment which should hopefully land them at this commit message. The call to ath_hal_reset() will be clearing the beacon config and it may not be always reset.
2011-06-26 13:53:24 +00:00
/* XXX beacons ? */
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
void
ath_shutdown(struct ath_softc *sc)
{
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
ATH_LOCK(sc);
ath_stop(sc);
ATH_UNLOCK(sc);
Cleanup power handling and fix suspend/resume: o do not put the chip into full sleep in ath_stop as it gains nothing and causes many parts to hang in ath_detach because we may touch the chip during vap teardown; this may also fix issues with unloading the module o add a note in ath_detach to explain ath_hal_detach puts the chip in low power mode; this is useful to know as it means unloading the module will place a pci device in the lowest possible power state o leave an #ifdef notyet marker for powering down the chip when a device is marked down; we can't do that until we handle all the ways the driver may be entered and touch the chip o fix resume by reloading the h/w key cache as it's been clobbered (for pci) by the socket being powered off; for station mode we directly stop+init the chip and then simulate a beacon miss to get the upper layers sync'd up; for other configs we must brute force stop+start the vaps so they go through the state machine
2008-05-29 00:10:48 +00:00
/* NB: no point powering down chip as we're about to reboot */
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
Update with last year of work.
2004-12-08 17:34:36 +00:00
/*
* Interrupt handler. Most of the actual processing is deferred.
*/
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
void
ath_intr(void *arg)
{
struct ath_softc *sc = arg;
struct ath_hal *ah = sc->sc_ah;
Fix a corner-case of interrupt handling which resulted in potentially spurious (and fatal) interrupt errors. One user reported seeing this: Apr 22 18:04:24 ceres kernel: ar5416GetPendingInterrupts: fatal error, ISR_RAC 0x0 SYNC_CAUSE 0x2000 SYNC_CAUSE of 0x2000 is AR_INTR_SYNC_LOCAL_TIMEOUT which is a bus timeout; this shouldn't cause HAL_INT_FATAL to be set. After checking out ath9k, ath9k_ar9002_hw_get_isr() clears (*masked) before continuing, regardless of whether any bits in the ISR registers are set. So if AR_INTR_SYNC_CAUSE is set to something that isn't treated as fatal, and AR_ISR isn't read or is read and is 0, then (*masked) wouldn't be cleared. Thus any of the existing bits set that were passed in would be preserved in the output. The caller in if_ath - ath_intr() - wasn't setting the masked value to 0 before calling ath_hal_getisr(), so anything that was present in that uninitialised variable would be preserved in the case above of AR_ISR=0, AR_INTR_SYNC_CAUSE != 0; and if the HAL_INT_FATAL bit was set, a fatal condition would be interpreted and the chip was reset. This patch does the following: * ath_intr() - set masked to 0 before calling ath_hal_getisr(); * ar5416GetPendingInterrupts() - clear (*masked) before processing continues; so if the interrupt source is AR_INTR_SYNC_CAUSE and it isn't fatal, the hardware isn't reset via returning HAL_INT_FATAL. This doesn't fix any underlying errors which trigger AR_INTR_SYNC_LOCAL_TIMEOUT - which is a bus timeout of some sort - so that likely should be further investigated.
2011-04-23 06:37:09 +00:00
HAL_INT status = 0;
Merge in some fixes from the if_ath_tx branch. * Close down some of the kickpcu races, where the interrupt handler can and will run concurrently with the taskqueue. * Close down the TXQ active/completed race between the interrupt handler and the concurrently running tx completion taskqueue function. * Add some tx and rx interrupt count tracking, for debugging. * Fix the kickpcu logic in ath_rx_proc() to not simply drain and restart the TX queue - instead, assume the hardware isn't (too) confused and just restart RX DMA. This may break on previous chipsets, so if it does I'll add a HAL flag and conditionally handle this (ie, for broken chipsets, I'll just restore the "stop PCU / flush things / restart PCU" logic.) * Misc stuff Sponsored by: Hobnob, Inc.
2011-11-08 18:10:04 +00:00
uint32_t txqs;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
/*
* If we're inside a reset path, just print a warning and
* clear the ISR. The reset routine will finish it for us.
*/
ATH_PCU_LOCK(sc);
if (sc->sc_inreset_cnt) {
HAL_INT status;
ath_hal_getisr(ah, &status); /* clear ISR */
ath_hal_intrset(ah, 0); /* disable further intr's */
DPRINTF(sc, ATH_DEBUG_ANY,
"%s: in reset, ignoring: status=0x%x\n",
__func__, status);
ATH_PCU_UNLOCK(sc);
return;
}
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
if (sc->sc_invalid) {
/*
Close a race where ath_intr is installed and may be called before the HAL is setup: use sc_invalid to discard such entries into ath_intr. This can easily happen if the device is assigned a shared IRQ.
2003-08-13 21:29:35 +00:00
* The hardware is not ready/present, don't touch anything.
* Note this can happen early on if the IRQ is shared.
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
*/
Update with last year of work.
2004-12-08 17:34:36 +00:00
DPRINTF(sc, ATH_DEBUG_ANY, "%s: invalid; ignored\n", __func__);
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
ATH_PCU_UNLOCK(sc);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
return;
}
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
if (!ath_hal_intrpend(ah)) { /* shared irq, not for us */
ATH_PCU_UNLOCK(sc);
check more quickly (and directly) if an interrupt is pending; this reduces work done in ath_intr when the irq is shared Obtained from: madwifi
2004-04-02 23:49:15 +00:00
return;
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
}
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ATH_LOCK(sc);
ath_power_set_power_state(sc, HAL_PM_AWAKE);
ATH_UNLOCK(sc);
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
if (sc->sc_ic.ic_nrunning == 0 && sc->sc_running == 0) {
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
HAL_INT status;
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
DPRINTF(sc, ATH_DEBUG_ANY, "%s: ic_nrunning %d sc_running %d\n",
__func__, sc->sc_ic.ic_nrunning, sc->sc_running);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
ath_hal_getisr(ah, &status); /* clear ISR */
ath_hal_intrset(ah, 0); /* disable further intr's */
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
ATH_PCU_UNLOCK(sc);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ATH_LOCK(sc);
ath_power_restore_power_state(sc);
ATH_UNLOCK(sc);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
return;
}
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
Update with last year of work.
2004-12-08 17:34:36 +00:00
/*
* Figure out the reason(s) for the interrupt. Note
* that the hal returns a pseudo-ISR that may include
* bits we haven't explicitly enabled so we mask the
* value to insure we only process bits we requested.
*/
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
ath_hal_getisr(ah, &status); /* NB: clears ISR too */
Update with last year of work.
2004-12-08 17:34:36 +00:00
DPRINTF(sc, ATH_DEBUG_INTR, "%s: status 0x%x\n", __func__, status);
Migrate the ath(4) KTR logging to use an ATH_KTR() macro. This should eventually be unified with ATH_DEBUG() so I can get both from one macro; that may take some time. Add some new probes for TX and TX completion.
2012-09-24 20:35:56 +00:00
ATH_KTR(sc, ATH_KTR_INTERRUPTS, 1, "ath_intr: mask=0x%.8x", status);
Post interrupts in the ath alq trace.
2013-02-20 11:17:03 +00:00
#ifdef ATH_DEBUG_ALQ
if_ath_alq_post_intr(&sc->sc_alq, status, ah->ah_intrstate,
ah->ah_syncstate);
oops, tab!
2013-02-20 11:17:29 +00:00
#endif /* ATH_DEBUG_ALQ */
Fix the KTR option to compile by default - it was referencing some unmerged interrupt status debugging code from my branch. * Add ah_intrstate[8] which will have the record of the last call to ath_hal_getintr(). * Wrap the KTR code behind ATH_KTR_INTR_DEBUG. * Add the HAL interrupt debugging behind AH_INTERRUPT_DEBUGGING. This is only done for the AR5416 and later NICs but it will be trivial to add to the earlier NICs if required. Neither are enabled by default, although to minimise HAL binary API differences, the ah_intrstate[] array is always compiled into the ath_hal struct.
2011-11-08 22:50:28 +00:00
#ifdef ATH_KTR_INTR_DEBUG
Migrate the ath(4) KTR logging to use an ATH_KTR() macro. This should eventually be unified with ATH_DEBUG() so I can get both from one macro; that may take some time. Add some new probes for TX and TX completion.
2012-09-24 20:35:56 +00:00
ATH_KTR(sc, ATH_KTR_INTERRUPTS, 5,
Add KTR tracepoints to the ath driver, in order to debug TX, RX and interrupt handling. Sponsored by: Hobnob, Inc.
2011-11-08 19:02:59 +00:00
"ath_intr: ISR=0x%.8x, ISR_S0=0x%.8x, ISR_S1=0x%.8x, ISR_S2=0x%.8x, ISR_S5=0x%.8x",
ah->ah_intrstate[0],
ah->ah_intrstate[1],
ah->ah_intrstate[2],
ah->ah_intrstate[3],
ah->ah_intrstate[6]);
Fix the KTR option to compile by default - it was referencing some unmerged interrupt status debugging code from my branch. * Add ah_intrstate[8] which will have the record of the last call to ath_hal_getintr(). * Wrap the KTR code behind ATH_KTR_INTR_DEBUG. * Add the HAL interrupt debugging behind AH_INTERRUPT_DEBUGGING. This is only done for the AR5416 and later NICs but it will be trivial to add to the earlier NICs if required. Neither are enabled by default, although to minimise HAL binary API differences, the ah_intrstate[] array is always compiled into the ath_hal struct.
2011-11-08 22:50:28 +00:00
#endif
Squirrel away SYNC interrupt debugging if it's enabled in the HAL. Bus errors will show up as various SYNC interrupts which will be passed back up to ath_intr().
2012-04-10 07:23:37 +00:00
/* Squirrel away SYNC interrupt debugging */
if (ah->ah_syncstate != 0) {
int i;
for (i = 0; i < 32; i++)
ath(4): Fix typo in debugging code PR: 229548 Submitted by: David Binderman <dcb314 AT hotmail.com>
2018-07-05 21:38:54 +00:00
if (ah->ah_syncstate & (1 << i))
Squirrel away SYNC interrupt debugging if it's enabled in the HAL. Bus errors will show up as various SYNC interrupts which will be passed back up to ath_intr().
2012-04-10 07:23:37 +00:00
sc->sc_intr_stats.sync_intr[i]++;
}
o do not filter received frames based on type or length; pass 'em all up to the 802.11 layer if they are at least IEEE80211_MIN_LEN o mask off interrupt status bits that we don't care about so we don't do the wrong thing; this fixes a problem where the beacon miss interrupt status bit is delivered together with other status bits when operating in monitor mode (we would post a beacon miss swi and then do the wrong thing)
2003-09-15 19:41:54 +00:00
status &= sc->sc_imask; /* discard unasked for bits */
Fix a corner-case of interrupt handling which resulted in potentially spurious (and fatal) interrupt errors. One user reported seeing this: Apr 22 18:04:24 ceres kernel: ar5416GetPendingInterrupts: fatal error, ISR_RAC 0x0 SYNC_CAUSE 0x2000 SYNC_CAUSE of 0x2000 is AR_INTR_SYNC_LOCAL_TIMEOUT which is a bus timeout; this shouldn't cause HAL_INT_FATAL to be set. After checking out ath9k, ath9k_ar9002_hw_get_isr() clears (*masked) before continuing, regardless of whether any bits in the ISR registers are set. So if AR_INTR_SYNC_CAUSE is set to something that isn't treated as fatal, and AR_ISR isn't read or is read and is 0, then (*masked) wouldn't be cleared. Thus any of the existing bits set that were passed in would be preserved in the output. The caller in if_ath - ath_intr() - wasn't setting the masked value to 0 before calling ath_hal_getisr(), so anything that was present in that uninitialised variable would be preserved in the case above of AR_ISR=0, AR_INTR_SYNC_CAUSE != 0; and if the HAL_INT_FATAL bit was set, a fatal condition would be interpreted and the chip was reset. This patch does the following: * ath_intr() - set masked to 0 before calling ath_hal_getisr(); * ar5416GetPendingInterrupts() - clear (*masked) before processing continues; so if the interrupt source is AR_INTR_SYNC_CAUSE and it isn't fatal, the hardware isn't reset via returning HAL_INT_FATAL. This doesn't fix any underlying errors which trigger AR_INTR_SYNC_LOCAL_TIMEOUT - which is a bus timeout of some sort - so that likely should be further investigated.
2011-04-23 06:37:09 +00:00
/* Short-circuit un-handled interrupts */
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
if (status == 0x0) {
ATH_PCU_UNLOCK(sc);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ATH_LOCK(sc);
ath_power_restore_power_state(sc);
ATH_UNLOCK(sc);
Fix a corner-case of interrupt handling which resulted in potentially spurious (and fatal) interrupt errors. One user reported seeing this: Apr 22 18:04:24 ceres kernel: ar5416GetPendingInterrupts: fatal error, ISR_RAC 0x0 SYNC_CAUSE 0x2000 SYNC_CAUSE of 0x2000 is AR_INTR_SYNC_LOCAL_TIMEOUT which is a bus timeout; this shouldn't cause HAL_INT_FATAL to be set. After checking out ath9k, ath9k_ar9002_hw_get_isr() clears (*masked) before continuing, regardless of whether any bits in the ISR registers are set. So if AR_INTR_SYNC_CAUSE is set to something that isn't treated as fatal, and AR_ISR isn't read or is read and is 0, then (*masked) wouldn't be cleared. Thus any of the existing bits set that were passed in would be preserved in the output. The caller in if_ath - ath_intr() - wasn't setting the masked value to 0 before calling ath_hal_getisr(), so anything that was present in that uninitialised variable would be preserved in the case above of AR_ISR=0, AR_INTR_SYNC_CAUSE != 0; and if the HAL_INT_FATAL bit was set, a fatal condition would be interpreted and the chip was reset. This patch does the following: * ath_intr() - set masked to 0 before calling ath_hal_getisr(); * ar5416GetPendingInterrupts() - clear (*masked) before processing continues; so if the interrupt source is AR_INTR_SYNC_CAUSE and it isn't fatal, the hardware isn't reset via returning HAL_INT_FATAL. This doesn't fix any underlying errors which trigger AR_INTR_SYNC_LOCAL_TIMEOUT - which is a bus timeout of some sort - so that likely should be further investigated.
2011-04-23 06:37:09 +00:00
return;
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
}
Fix a corner-case of interrupt handling which resulted in potentially spurious (and fatal) interrupt errors. One user reported seeing this: Apr 22 18:04:24 ceres kernel: ar5416GetPendingInterrupts: fatal error, ISR_RAC 0x0 SYNC_CAUSE 0x2000 SYNC_CAUSE of 0x2000 is AR_INTR_SYNC_LOCAL_TIMEOUT which is a bus timeout; this shouldn't cause HAL_INT_FATAL to be set. After checking out ath9k, ath9k_ar9002_hw_get_isr() clears (*masked) before continuing, regardless of whether any bits in the ISR registers are set. So if AR_INTR_SYNC_CAUSE is set to something that isn't treated as fatal, and AR_ISR isn't read or is read and is 0, then (*masked) wouldn't be cleared. Thus any of the existing bits set that were passed in would be preserved in the output. The caller in if_ath - ath_intr() - wasn't setting the masked value to 0 before calling ath_hal_getisr(), so anything that was present in that uninitialised variable would be preserved in the case above of AR_ISR=0, AR_INTR_SYNC_CAUSE != 0; and if the HAL_INT_FATAL bit was set, a fatal condition would be interpreted and the chip was reset. This patch does the following: * ath_intr() - set masked to 0 before calling ath_hal_getisr(); * ar5416GetPendingInterrupts() - clear (*masked) before processing continues; so if the interrupt source is AR_INTR_SYNC_CAUSE and it isn't fatal, the hardware isn't reset via returning HAL_INT_FATAL. This doesn't fix any underlying errors which trigger AR_INTR_SYNC_LOCAL_TIMEOUT - which is a bus timeout of some sort - so that likely should be further investigated.
2011-04-23 06:37:09 +00:00
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
/*
* Take a note that we're inside the interrupt handler, so
* the reset routines know to wait.
*/
sc->sc_intr_cnt++;
ATH_PCU_UNLOCK(sc);
/*
* Handle the interrupt. We won't run concurrent with the reset
* or channel change routines as they'll wait for sc_intr_cnt
* to be 0 before continuing.
*/
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
if (status & HAL_INT_FATAL) {
sc->sc_stats.ast_hardware++;
ath_hal_intrset(ah, 0); /* disable intr's until reset */
Run the fatal proc as a proc, rather than where it currently is. Otherwise the reset path will sleep, which it can't do in this context.
2012-04-17 06:02:41 +00:00
taskqueue_enqueue(sc->sc_tq, &sc->sc_fataltask);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
} else {
Update with last year of work.
2004-12-08 17:34:36 +00:00
if (status & HAL_INT_SWBA) {
/*
* Software beacon alert--time to send a beacon.
* Handle beacon transmission directly; deferring
* this is too slow to meet timing constraints
* under load.
*/
Remove ATH_SUPPORT_TDMA and use IEEE80211_SUPPORT_TDMA instead. It doesn't make much sense to configure driver support w/o net80211. Note this means ath now depends on opt_wlan.h.
2009-03-30 19:23:49 +00:00
#ifdef IEEE80211_SUPPORT_TDMA
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
if (sc->sc_tdma) {
if (sc->sc_tdmaswba == 0) {
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
struct ieee80211com *ic = &sc->sc_ic;
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
struct ieee80211vap *vap =
TAILQ_FIRST(&ic->ic_vaps);
ath_tdma_beacon_send(sc, vap);
sc->sc_tdmaswba =
vap->iv_tdma->tdma_bintval;
} else
sc->sc_tdmaswba--;
} else
#endif
Hoist 802.11 encapsulation up into net80211: o call ieee80211_encap in ieee80211_start so frames passed down to drivers are already encapsulated o remove ieee80211_encap calls in drivers o fixup wi so it recreates the 802.3 head it requires from the 802.11 header contents o move fast-frame aggregation from ath to net80211 (conditional on IEEE80211_SUPPORT_SUPERG): - aggregation is now done in ieee80211_start; it is enabled when the packets/sec exceeds ieee80211_ffppsmin (net.wlan.ffppsmin) and frames are held on a staging queue according to ieee80211_ffagemax (net.wlan.ffagemax) to wait for a frame to combine with - drivers must call back to age/flush the staging queue (ath does this on tx done, at swba, and on rx according to the state of the tx queues and/or the contents of the staging queue) - remove fast-frame-related data structures from ath - add ieee80211_ff_node_init and ieee80211_ff_node_cleanup to handle per-node fast-frames state (we reuse 11n tx ampdu state) o change ieee80211_encap calling convention to include an explicit vap so frames coming through a WDS vap are recognized w/o setting M_WDS With these changes any device able to tx/rx 3Kbyte+ frames can use fast-frames. Reviewed by: thompsa, rpaulo, avatar, imp, sephe
2009-03-30 21:53:27 +00:00
{
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
ath_beacon_proc(sc, 0);
Hoist 802.11 encapsulation up into net80211: o call ieee80211_encap in ieee80211_start so frames passed down to drivers are already encapsulated o remove ieee80211_encap calls in drivers o fixup wi so it recreates the 802.3 head it requires from the 802.11 header contents o move fast-frame aggregation from ath to net80211 (conditional on IEEE80211_SUPPORT_SUPERG): - aggregation is now done in ieee80211_start; it is enabled when the packets/sec exceeds ieee80211_ffppsmin (net.wlan.ffppsmin) and frames are held on a staging queue according to ieee80211_ffagemax (net.wlan.ffagemax) to wait for a frame to combine with - drivers must call back to age/flush the staging queue (ath does this on tx done, at swba, and on rx according to the state of the tx queues and/or the contents of the staging queue) - remove fast-frame-related data structures from ath - add ieee80211_ff_node_init and ieee80211_ff_node_cleanup to handle per-node fast-frames state (we reuse 11n tx ampdu state) o change ieee80211_encap calling convention to include an explicit vap so frames coming through a WDS vap are recognized w/o setting M_WDS With these changes any device able to tx/rx 3Kbyte+ frames can use fast-frames. Reviewed by: thompsa, rpaulo, avatar, imp, sephe
2009-03-30 21:53:27 +00:00
#ifdef IEEE80211_SUPPORT_SUPERG
/*
* Schedule the rx taskq in case there's no
* traffic so any frames held on the staging
* queue are aged and potentially flushed.
*/
Break out the RX completion path into "FIFO check / refill" and "complete RX frames." The 128 entry RX FIFO is really easy to fill up and miss refilling when it's done in the ath taskq - as that gets blocked up doing RX completion, TX completion and other random things. So the 128 entry RX FIFO now gets emptied and refilled in the ath_intr() task (and it grabs / releases locks, so now ath_intr() can't just be a FAST handler yet!) but the locks aren't held for very long. The completion part is done in the ath taskqueue context. Details: * Create a new completed frame list - sc->sc_rx_rxlist; * Split the EDMA RX process queue into two halves - one that processes the RX FIFO and refills it with new frames; another that completes the completed frame list; * When tearing down the driver, flush whatever is in the deferred queue as well as what's in the FIFO; * Create two new RX methods - one that processes all RX queues, one that processes the given RX queue. When MSI is implemented, we get told which RX queue the interrupt came in on so we can specifically schedule that. (And I can do that with the non-MSI path too; I'll figure that out later.) * Convert the legacy code over to use these new RX methods; * Replace all the instances of the RX taskqueue enqueue with a call to a relevant RX method to enqueue one or all RX queues. Tested: * AR9380, STA * AR9580, STA * AR5413, STA
2013-03-19 19:32:28 +00:00
sc->sc_rx.recv_sched(sc, 1);
Hoist 802.11 encapsulation up into net80211: o call ieee80211_encap in ieee80211_start so frames passed down to drivers are already encapsulated o remove ieee80211_encap calls in drivers o fixup wi so it recreates the 802.3 head it requires from the 802.11 header contents o move fast-frame aggregation from ath to net80211 (conditional on IEEE80211_SUPPORT_SUPERG): - aggregation is now done in ieee80211_start; it is enabled when the packets/sec exceeds ieee80211_ffppsmin (net.wlan.ffppsmin) and frames are held on a staging queue according to ieee80211_ffagemax (net.wlan.ffagemax) to wait for a frame to combine with - drivers must call back to age/flush the staging queue (ath does this on tx done, at swba, and on rx according to the state of the tx queues and/or the contents of the staging queue) - remove fast-frame-related data structures from ath - add ieee80211_ff_node_init and ieee80211_ff_node_cleanup to handle per-node fast-frames state (we reuse 11n tx ampdu state) o change ieee80211_encap calling convention to include an explicit vap so frames coming through a WDS vap are recognized w/o setting M_WDS With these changes any device able to tx/rx 3Kbyte+ frames can use fast-frames. Reviewed by: thompsa, rpaulo, avatar, imp, sephe
2009-03-30 21:53:27 +00:00
#endif
}
Update with last year of work.
2004-12-08 17:34:36 +00:00
}
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
if (status & HAL_INT_RXEOL) {
Merge in some fixes from the if_ath_tx branch. * Close down some of the kickpcu races, where the interrupt handler can and will run concurrently with the taskqueue. * Close down the TXQ active/completed race between the interrupt handler and the concurrently running tx completion taskqueue function. * Add some tx and rx interrupt count tracking, for debugging. * Fix the kickpcu logic in ath_rx_proc() to not simply drain and restart the TX queue - instead, assume the hardware isn't (too) confused and just restart RX DMA. This may break on previous chipsets, so if it does I'll add a HAL flag and conditionally handle this (ie, for broken chipsets, I'll just restore the "stop PCU / flush things / restart PCU" logic.) * Misc stuff Sponsored by: Hobnob, Inc.
2011-11-08 18:10:04 +00:00
int imask;
Migrate the ath(4) KTR logging to use an ATH_KTR() macro. This should eventually be unified with ATH_DEBUG() so I can get both from one macro; that may take some time. Add some new probes for TX and TX completion.
2012-09-24 20:35:56 +00:00
ATH_KTR(sc, ATH_KTR_ERROR, 0, "ath_intr: RXEOL");
Fix up the EDMA RX setup path to correctly initialise and reset the RX FIFO. The original code was .. well, slightly more than incorrect. It showed up as stalled RX queues if the NIC needed to be frequently reinitialised (eg during scans.) This is inspired by work done by Matt Dillon over at the DragonflyBSD project. So: * track when EDMA RX has been stopped and when the MAC has been reset; * re-initialise the ring only after a reset; * track whether RX has been stopped/started - just for debugging now; * don't bother with the RX EOL stuff for EDMA - we don't need the interrupt at all. We also don't need to disable/enable the interrupt or start DMA - once new frames are pushed into the ring via the normal RX path, it'll just restart RX DMA on its own. Tested: * AR9380, STA mode * AR9380, AP mode * AR9485, STA mode * AR9462, STA mode
2014-09-20 01:22:17 +00:00
if (! sc->sc_isedma) {
ATH_PCU_LOCK(sc);
/*
* NB: the hardware should re-read the link when
* RXE bit is written, but it doesn't work at
* least on older hardware revs.
*/
sc->sc_stats.ast_rxeol++;
/*
* Disable RXEOL/RXORN - prevent an interrupt
* storm until the PCU logic can be reset.
* In case the interface is reset some other
* way before "sc_kickpcu" is called, don't
* modify sc_imask - that way if it is reset
* by a call to ath_reset() somehow, the
* interrupt mask will be correctly reprogrammed.
*/
imask = sc->sc_imask;
imask &= ~(HAL_INT_RXEOL | HAL_INT_RXORN);
ath_hal_intrset(ah, imask);
/*
* Only blank sc_rxlink if we've not yet kicked
* the PCU.
*
* This isn't entirely correct - the correct solution
* would be to have a PCU lock and engage that for
* the duration of the PCU fiddling; which would include
* running the RX process. Otherwise we could end up
* messing up the RX descriptor chain and making the
* RX desc list much shorter.
*/
if (! sc->sc_kickpcu)
sc->sc_rxlink = NULL;
sc->sc_kickpcu = 1;
ATH_PCU_UNLOCK(sc);
}
Fix a corner case in RXEOL handling which was likely introduced by yours truly. Before 802.11n, the RX descriptor list would employ the "self-linked tail descriptor" trick which linked the last descriptor back to itself. This way, the RX engine would never hit the "end" of the list and stop processing RX (and assert RXEOL) as it never hit a descriptor whose next pointer was 0. It would just keep overwriting the last descriptor until the software freed up some more RX descriptors and chained them onto the end. For 802.11n, this needs to stop as a self-linked RX descriptor tickles the block-ack logic into ACK'ing whatever frames are received into that self-linked descriptor - so in very busy periods, you could end up with A-MPDU traffic that is ACKed but never received by the 802.11 stack. This would cause some confusion as the ADDBA windows would suddenly be out of sync. So when that occured here, the last descriptor would be hit and the PCU logic would stop. It would only start again when the RX descriptor list was updated and the PCU RX engine was re-tickled. That wasn't being done, so RXEOL would be continuously asserted and no RX would continue. This patch introduces a new flag - sc->sc_kickpcu - which when set, signals the RX task to kick the PCU after its processed whatever packets it can. This way completed packets aren't discarded. In case some other task gets called which resets the hardware, don't update sc->sc_imask - instead, just update the hardware interrupt mask directly and let either ath_rx_proc() or ath_reset() restore the imask to its former setting. Note: this bug was only triggered when doing a whole lot of frame snooping with serial console IO in the RX task. This would defer interrupt processing enough to cause an RX descriptor overflow. It doesn't happen in normal conditions. Approved by: re (kib, blanket)
2011-08-02 02:46:03 +00:00
/*
Fix up the EDMA RX setup path to correctly initialise and reset the RX FIFO. The original code was .. well, slightly more than incorrect. It showed up as stalled RX queues if the NIC needed to be frequently reinitialised (eg during scans.) This is inspired by work done by Matt Dillon over at the DragonflyBSD project. So: * track when EDMA RX has been stopped and when the MAC has been reset; * re-initialise the ring only after a reset; * track whether RX has been stopped/started - just for debugging now; * don't bother with the RX EOL stuff for EDMA - we don't need the interrupt at all. We also don't need to disable/enable the interrupt or start DMA - once new frames are pushed into the ring via the normal RX path, it'll just restart RX DMA on its own. Tested: * AR9380, STA mode * AR9380, AP mode * AR9485, STA mode * AR9462, STA mode
2014-09-20 01:22:17 +00:00
* Enqueue an RX proc to handle whatever
Fix a corner case in RXEOL handling which was likely introduced by yours truly. Before 802.11n, the RX descriptor list would employ the "self-linked tail descriptor" trick which linked the last descriptor back to itself. This way, the RX engine would never hit the "end" of the list and stop processing RX (and assert RXEOL) as it never hit a descriptor whose next pointer was 0. It would just keep overwriting the last descriptor until the software freed up some more RX descriptors and chained them onto the end. For 802.11n, this needs to stop as a self-linked RX descriptor tickles the block-ack logic into ACK'ing whatever frames are received into that self-linked descriptor - so in very busy periods, you could end up with A-MPDU traffic that is ACKed but never received by the 802.11 stack. This would cause some confusion as the ADDBA windows would suddenly be out of sync. So when that occured here, the last descriptor would be hit and the PCU logic would stop. It would only start again when the RX descriptor list was updated and the PCU RX engine was re-tickled. That wasn't being done, so RXEOL would be continuously asserted and no RX would continue. This patch introduces a new flag - sc->sc_kickpcu - which when set, signals the RX task to kick the PCU after its processed whatever packets it can. This way completed packets aren't discarded. In case some other task gets called which resets the hardware, don't update sc->sc_imask - instead, just update the hardware interrupt mask directly and let either ath_rx_proc() or ath_reset() restore the imask to its former setting. Note: this bug was only triggered when doing a whole lot of frame snooping with serial console IO in the RX task. This would defer interrupt processing enough to cause an RX descriptor overflow. It doesn't happen in normal conditions. Approved by: re (kib, blanket)
2011-08-02 02:46:03 +00:00
* is in the RX queue.
Fix up the EDMA RX setup path to correctly initialise and reset the RX FIFO. The original code was .. well, slightly more than incorrect. It showed up as stalled RX queues if the NIC needed to be frequently reinitialised (eg during scans.) This is inspired by work done by Matt Dillon over at the DragonflyBSD project. So: * track when EDMA RX has been stopped and when the MAC has been reset; * re-initialise the ring only after a reset; * track whether RX has been stopped/started - just for debugging now; * don't bother with the RX EOL stuff for EDMA - we don't need the interrupt at all. We also don't need to disable/enable the interrupt or start DMA - once new frames are pushed into the ring via the normal RX path, it'll just restart RX DMA on its own. Tested: * AR9380, STA mode * AR9380, AP mode * AR9485, STA mode * AR9462, STA mode
2014-09-20 01:22:17 +00:00
* This will then kick the PCU if required.
Fix a corner case in RXEOL handling which was likely introduced by yours truly. Before 802.11n, the RX descriptor list would employ the "self-linked tail descriptor" trick which linked the last descriptor back to itself. This way, the RX engine would never hit the "end" of the list and stop processing RX (and assert RXEOL) as it never hit a descriptor whose next pointer was 0. It would just keep overwriting the last descriptor until the software freed up some more RX descriptors and chained them onto the end. For 802.11n, this needs to stop as a self-linked RX descriptor tickles the block-ack logic into ACK'ing whatever frames are received into that self-linked descriptor - so in very busy periods, you could end up with A-MPDU traffic that is ACKed but never received by the 802.11 stack. This would cause some confusion as the ADDBA windows would suddenly be out of sync. So when that occured here, the last descriptor would be hit and the PCU logic would stop. It would only start again when the RX descriptor list was updated and the PCU RX engine was re-tickled. That wasn't being done, so RXEOL would be continuously asserted and no RX would continue. This patch introduces a new flag - sc->sc_kickpcu - which when set, signals the RX task to kick the PCU after its processed whatever packets it can. This way completed packets aren't discarded. In case some other task gets called which resets the hardware, don't update sc->sc_imask - instead, just update the hardware interrupt mask directly and let either ath_rx_proc() or ath_reset() restore the imask to its former setting. Note: this bug was only triggered when doing a whole lot of frame snooping with serial console IO in the RX task. This would defer interrupt processing enough to cause an RX descriptor overflow. It doesn't happen in normal conditions. Approved by: re (kib, blanket)
2011-08-02 02:46:03 +00:00
*/
Break out the RX completion path into "FIFO check / refill" and "complete RX frames." The 128 entry RX FIFO is really easy to fill up and miss refilling when it's done in the ath taskq - as that gets blocked up doing RX completion, TX completion and other random things. So the 128 entry RX FIFO now gets emptied and refilled in the ath_intr() task (and it grabs / releases locks, so now ath_intr() can't just be a FAST handler yet!) but the locks aren't held for very long. The completion part is done in the ath taskqueue context. Details: * Create a new completed frame list - sc->sc_rx_rxlist; * Split the EDMA RX process queue into two halves - one that processes the RX FIFO and refills it with new frames; another that completes the completed frame list; * When tearing down the driver, flush whatever is in the deferred queue as well as what's in the FIFO; * Create two new RX methods - one that processes all RX queues, one that processes the given RX queue. When MSI is implemented, we get told which RX queue the interrupt came in on so we can specifically schedule that. (And I can do that with the non-MSI path too; I'll figure that out later.) * Convert the legacy code over to use these new RX methods; * Replace all the instances of the RX taskqueue enqueue with a call to a relevant RX method to enqueue one or all RX queues. Tested: * AR9380, STA * AR9580, STA * AR5413, STA
2013-03-19 19:32:28 +00:00
sc->sc_rx.recv_sched(sc, 1);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
if (status & HAL_INT_TXURN) {
sc->sc_stats.ast_txurn++;
/* bump tx trigger level */
ath_hal_updatetxtriglevel(ah, AH_TRUE);
}
Flip on EDMA RX of both HP and LP queue frames. Yes, this is in the legacy interrupt path. The NIC does support MSI but I haven't yet sat down and written that code.
2012-07-10 07:43:31 +00:00
/*
* Handle both the legacy and RX EDMA interrupt bits.
* Note that HAL_INT_RXLP is also HAL_INT_RXDESC.
*/
if (status & (HAL_INT_RX | HAL_INT_RXHP | HAL_INT_RXLP)) {
Merge in some fixes from the if_ath_tx branch. * Close down some of the kickpcu races, where the interrupt handler can and will run concurrently with the taskqueue. * Close down the TXQ active/completed race between the interrupt handler and the concurrently running tx completion taskqueue function. * Add some tx and rx interrupt count tracking, for debugging. * Fix the kickpcu logic in ath_rx_proc() to not simply drain and restart the TX queue - instead, assume the hardware isn't (too) confused and just restart RX DMA. This may break on previous chipsets, so if it does I'll add a HAL flag and conditionally handle this (ie, for broken chipsets, I'll just restore the "stop PCU / flush things / restart PCU" logic.) * Misc stuff Sponsored by: Hobnob, Inc.
2011-11-08 18:10:04 +00:00
sc->sc_stats.ast_rx_intr++;
Break out the RX completion path into "FIFO check / refill" and "complete RX frames." The 128 entry RX FIFO is really easy to fill up and miss refilling when it's done in the ath taskq - as that gets blocked up doing RX completion, TX completion and other random things. So the 128 entry RX FIFO now gets emptied and refilled in the ath_intr() task (and it grabs / releases locks, so now ath_intr() can't just be a FAST handler yet!) but the locks aren't held for very long. The completion part is done in the ath taskqueue context. Details: * Create a new completed frame list - sc->sc_rx_rxlist; * Split the EDMA RX process queue into two halves - one that processes the RX FIFO and refills it with new frames; another that completes the completed frame list; * When tearing down the driver, flush whatever is in the deferred queue as well as what's in the FIFO; * Create two new RX methods - one that processes all RX queues, one that processes the given RX queue. When MSI is implemented, we get told which RX queue the interrupt came in on so we can specifically schedule that. (And I can do that with the non-MSI path too; I'll figure that out later.) * Convert the legacy code over to use these new RX methods; * Replace all the instances of the RX taskqueue enqueue with a call to a relevant RX method to enqueue one or all RX queues. Tested: * AR9380, STA * AR9580, STA * AR5413, STA
2013-03-19 19:32:28 +00:00
sc->sc_rx.recv_sched(sc, 1);
Merge in some fixes from the if_ath_tx branch. * Close down some of the kickpcu races, where the interrupt handler can and will run concurrently with the taskqueue. * Close down the TXQ active/completed race between the interrupt handler and the concurrently running tx completion taskqueue function. * Add some tx and rx interrupt count tracking, for debugging. * Fix the kickpcu logic in ath_rx_proc() to not simply drain and restart the TX queue - instead, assume the hardware isn't (too) confused and just restart RX DMA. This may break on previous chipsets, so if it does I'll add a HAL flag and conditionally handle this (ie, for broken chipsets, I'll just restore the "stop PCU / flush things / restart PCU" logic.) * Misc stuff Sponsored by: Hobnob, Inc.
2011-11-08 18:10:04 +00:00
}
if (status & HAL_INT_TX) {
sc->sc_stats.ast_tx_intr++;
/*
* Grab all the currently set bits in the HAL txq bitmap
* and blank them. This is the only place we should be
* doing this.
*/
Break out the TX completion code into a separate function, so it can be re-used by the upcoming EDMA TX completion code. Make ath_stoptxdma() public, again so the EDMA TX code can use it. Don't check for the TXQ bitmap in the ISR when doing EDMA work as it doesn't apply for EDMA.
2012-08-14 22:32:20 +00:00
if (! sc->sc_isedma) {
ATH_PCU_LOCK(sc);
txqs = 0xffffffff;
ath_hal_gettxintrtxqs(sc->sc_ah, &txqs);
Migrate the ath(4) KTR logging to use an ATH_KTR() macro. This should eventually be unified with ATH_DEBUG() so I can get both from one macro; that may take some time. Add some new probes for TX and TX completion.
2012-09-24 20:35:56 +00:00
ATH_KTR(sc, ATH_KTR_INTERRUPTS, 3,
"ath_intr: TX; txqs=0x%08x, txq_active was 0x%08x, now 0x%08x",
txqs,
sc->sc_txq_active,
sc->sc_txq_active | txqs);
Break out the TX completion code into a separate function, so it can be re-used by the upcoming EDMA TX completion code. Make ath_stoptxdma() public, again so the EDMA TX code can use it. Don't check for the TXQ bitmap in the ISR when doing EDMA work as it doesn't apply for EDMA.
2012-08-14 22:32:20 +00:00
sc->sc_txq_active |= txqs;
ATH_PCU_UNLOCK(sc);
}
use a private task queue thread MFC after: 2 weeks
2006-02-09 21:48:51 +00:00
taskqueue_enqueue(sc->sc_tq, &sc->sc_txtask);
Merge in some fixes from the if_ath_tx branch. * Close down some of the kickpcu races, where the interrupt handler can and will run concurrently with the taskqueue. * Close down the TXQ active/completed race between the interrupt handler and the concurrently running tx completion taskqueue function. * Add some tx and rx interrupt count tracking, for debugging. * Fix the kickpcu logic in ath_rx_proc() to not simply drain and restart the TX queue - instead, assume the hardware isn't (too) confused and just restart RX DMA. This may break on previous chipsets, so if it does I'll add a HAL flag and conditionally handle this (ie, for broken chipsets, I'll just restore the "stop PCU / flush things / restart PCU" logic.) * Misc stuff Sponsored by: Hobnob, Inc.
2011-11-08 18:10:04 +00:00
}
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
if (status & HAL_INT_BMISS) {
sc->sc_stats.ast_bmiss++;
use a private task queue thread MFC after: 2 weeks
2006-02-09 21:48:51 +00:00
taskqueue_enqueue(sc->sc_tq, &sc->sc_bmisstask);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
Add global TX timeout handling. The global TX timeout counter increments whenever a frame is ready to be transmitted and the medium is busy.
2011-04-18 12:15:43 +00:00
if (status & HAL_INT_GTT)
sc->sc_stats.ast_tx_timeout++;
Add TX carrier sense timeout statistics.
2011-04-18 14:06:18 +00:00
if (status & HAL_INT_CST)
sc->sc_stats.ast_tx_cst++;
Update with last year of work.
2004-12-08 17:34:36 +00:00
if (status & HAL_INT_MIB) {
sc->sc_stats.ast_mib++;
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
ATH_PCU_LOCK(sc);
Update with last year of work.
2004-12-08 17:34:36 +00:00
/*
* Disable interrupts until we service the MIB
* interrupt; otherwise it will continue to fire.
*/
ath_hal_intrset(ah, 0);
/*
* Let the hal handle the event. We assume it will
* clear whatever condition caused the interrupt.
*/
move hal statistics to softc; the per-node stats are overkill, they're only used when operating in station mode MFC after: 2 weeks
2006-02-09 21:23:44 +00:00
ath_hal_mibevent(ah, &sc->sc_halstats);
Merge in some fixes from the if_ath_tx branch. * Close down some of the kickpcu races, where the interrupt handler can and will run concurrently with the taskqueue. * Close down the TXQ active/completed race between the interrupt handler and the concurrently running tx completion taskqueue function. * Add some tx and rx interrupt count tracking, for debugging. * Fix the kickpcu logic in ath_rx_proc() to not simply drain and restart the TX queue - instead, assume the hardware isn't (too) confused and just restart RX DMA. This may break on previous chipsets, so if it does I'll add a HAL flag and conditionally handle this (ie, for broken chipsets, I'll just restore the "stop PCU / flush things / restart PCU" logic.) * Misc stuff Sponsored by: Hobnob, Inc.
2011-11-08 18:10:04 +00:00
/*
* Don't reset the interrupt if we've just
* kicked the PCU, or we may get a nested
* RXEOL before the rxproc has had a chance
* to run.
*/
if (sc->sc_kickpcu == 0)
ath_hal_intrset(ah, sc->sc_imask);
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
ATH_PCU_UNLOCK(sc);
Update with last year of work.
2004-12-08 17:34:36 +00:00
}
nuke special handling of RXORN interrupt; the hal marks the FATAL bit in the interrupt status when RXORN is hit and the chip requires a reset so our special handling was causing useless resets
2008-11-24 01:31:10 +00:00
if (status & HAL_INT_RXORN) {
/* NB: hal marks HAL_INT_FATAL when RXORN is fatal */
Migrate the ath(4) KTR logging to use an ATH_KTR() macro. This should eventually be unified with ATH_DEBUG() so I can get both from one macro; that may take some time. Add some new probes for TX and TX completion.
2012-09-24 20:35:56 +00:00
ATH_KTR(sc, ATH_KTR_ERROR, 0, "ath_intr: RXORN");
nuke special handling of RXORN interrupt; the hal marks the FATAL bit in the interrupt status when RXORN is hit and the chip requires a reset so our special handling was causing useless resets
2008-11-24 01:31:10 +00:00
sc->sc_stats.ast_rxorn++;
}
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
if (status & HAL_INT_TSFOOR) {
[ath] force wake the hardware if we see a missed beacon. This adds a workaround to incorrectly behaving APs (ie, FreeBSD APs) which don't beacon out exactly when they should (at TBTT multiples of beacon intervals.) It forces the hardware awake (but leaves it in network-sleep so self generated frames still state that the hardware is asleep!) and will remain awake until the next sleep transition driven by net80211. That way if the beacons are just at the wrong interval, we get a much better chance of hearing more consecutive beacons before we go to sleep, thus not constantly disconnecting. Tested: * AR9485, STA mode, against a misbehaving FreeBSD AP.
2016-11-28 17:54:29 +00:00
/* out of range beacon - wake the chip up,
* but don't modify self-gen frame config */
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
device_printf(sc->sc_dev, "%s: TSFOOR\n", __func__);
sc->sc_syncbeacon = 1;
[ath] force wake the hardware if we see a missed beacon. This adds a workaround to incorrectly behaving APs (ie, FreeBSD APs) which don't beacon out exactly when they should (at TBTT multiples of beacon intervals.) It forces the hardware awake (but leaves it in network-sleep so self generated frames still state that the hardware is asleep!) and will remain awake until the next sleep transition driven by net80211. That way if the beacons are just at the wrong interval, we get a much better chance of hearing more consecutive beacons before we go to sleep, thus not constantly disconnecting. Tested: * AR9485, STA mode, against a misbehaving FreeBSD AP.
2016-11-28 17:54:29 +00:00
ATH_LOCK(sc);
ath_power_setpower(sc, HAL_PM_AWAKE, 0);
ATH_UNLOCK(sc);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
}
[ath] commit initial bluetooth coexistence support for the MCI NICs. This is the initial framework to call into the MCI HAL routines and drive the basic state engine. The MCI bluetooth coex model uses a command channel between wlan and bluetooth, rather than a 2-wire or 3-wire signaling protocol to control things. This means the wlan and bluetooth chip exchange a lot more information and signaling, even at the per-packet level. The NICs in question can share the input LNA and output PA on the die, so they absolutely can't stomp on each other in a silly fashion. It also allows for the bluetooth side to signal when profiles come and go, so the driver can take appropriate control. There's also the possibility of dynamic bluetooth/wlan duty cycle control which I haven't yet really played with. It configures things up with a static "wlan wins everything" coexistence, configures up the available 2GHz channel map for bluetooth, sets a static duty cycle for bluetooth/wifi traffic priority and drives the basics needed to keep the MCI HAL code happy. It doesn't do any actual coexistence except to default to "wlan wins everything", which at least demonstrates that things do indeed work. Bluetooth inquiry frames still trump wifi (including beacons), so that demonstrates things really do indeed seem to work. Tested: * AR9462 (WB222), STA mode + bt * QCA9565 (WB335), STA mode + bt TODO: * .. the rest of coexistence. yes, bluetooth, not people. That stuff's hard. * It doesn't do the initial BT side calibration, which requires a WLAN chip reset. I'll fix up the reset path a bit more first before I enable that. * The 1-ant and 2-ant configuration bits aren't being set correctly in if_ath_btcoex.c - I'll dig into that and fix it in a subsequent commit. * It's not enabled by default for WB222/WB225 even though I believe it now can be - I'll chase that up in a subsequent commit. Obtained from: Qualcomm Atheros, Linux ath9k
2016-06-02 00:51:36 +00:00
if (status & HAL_INT_MCI) {
ath_btcoex_mci_intr(sc);
}
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
ATH_PCU_LOCK(sc);
sc->sc_intr_cnt--;
ATH_PCU_UNLOCK(sc);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ATH_LOCK(sc);
ath_power_restore_power_state(sc);
ATH_UNLOCK(sc);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
static void
ath_fatal_proc(void *arg, int pending)
{
struct ath_softc *sc = arg;
o handle fatal errors directly instead of via the task queue o temporarily dump some h/w state for diagnosis; this will be removed once some issues are resolved MFC after: 2 weeks
2006-02-15 18:23:03 +00:00
u_int32_t *state;
u_int32_t len;
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
void *sp;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
Add a hack-around to this fatal taskqueue running whilst the NIC is detaching. This mostly fixes a panic - the reset path shouldn't run whilst the NIC is being torn down. It's not locked, so it's "mostly" ok, but most of the rest of the driver doesn't read sc->invalid with sensible locking. Grr. The real solution is to cleanly tear down taskqueues in the detach/suspend phase, but ..
2015-08-05 21:22:25 +00:00
if (sc->sc_invalid)
return;
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
device_printf(sc->sc_dev, "hardware error; resetting\n");
o handle fatal errors directly instead of via the task queue o temporarily dump some h/w state for diagnosis; this will be removed once some issues are resolved MFC after: 2 weeks
2006-02-15 18:23:03 +00:00
/*
* Fatal errors are unrecoverable. Typically these
* are caused by DMA errors. Collect h/w state from
* the hal so we can diagnose what's going on.
*/
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
if (ath_hal_getfatalstate(sc->sc_ah, &sp, &len)) {
o handle fatal errors directly instead of via the task queue o temporarily dump some h/w state for diagnosis; this will be removed once some issues are resolved MFC after: 2 weeks
2006-02-15 18:23:03 +00:00
KASSERT(len >= 6*sizeof(u_int32_t), ("len %u bytes", len));
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
state = sp;
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
device_printf(sc->sc_dev,
"0x%08x 0x%08x 0x%08x, 0x%08x 0x%08x 0x%08x\n", state[0],
state[1] , state[2], state[3], state[4], state[5]);
o handle fatal errors directly instead of via the task queue o temporarily dump some h/w state for diagnosis; this will be removed once some issues are resolved MFC after: 2 weeks
2006-02-15 18:23:03 +00:00
}
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
ath_reset(sc, ATH_RESET_NOLOSS);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
static void
ath_bmiss_vap(struct ieee80211vap *vap)
{
Remove most of the references of ifp->if_softc and replace with references to ic->ic_softc. This is in preparation for gleb's ifnet work. Tested: * ath(4), STA mode * ath(4), hostap mode * make universe
2015-08-17 02:04:11 +00:00
struct ath_softc *sc = vap->iv_ic->ic_softc;
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
/*
* Workaround phantom bmiss interrupts by sanity-checking
* the time of our last rx'd frame. If it is within the
* beacon miss interval then ignore the interrupt. If it's
* truly a bmiss we'll get another interrupt soon and that'll
don't do phantom beacon miss checking for s/w beacon miss handling, this can mistakenly drop events that cause the s/w bmiss timer to never get re-armed
2009-02-10 23:48:29 +00:00
* be dispatched up for processing. Note this applies only
* for h/w beacon miss events.
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
*/
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
/*
* XXX TODO: Just read the TSF during the interrupt path;
* that way we don't have to wake up again just to read it
* again.
*/
ATH_LOCK(sc);
ath_power_set_power_state(sc, HAL_PM_AWAKE);
ATH_UNLOCK(sc);
don't do phantom beacon miss checking for s/w beacon miss handling, this can mistakenly drop events that cause the s/w bmiss timer to never get re-armed
2009-02-10 23:48:29 +00:00
if ((vap->iv_flags_ext & IEEE80211_FEXT_SWBMISS) == 0) {
u_int64_t lastrx = sc->sc_lastrx;
u_int64_t tsf = ath_hal_gettsf64(sc->sc_ah);
Attempt to address some potential vap->iv_bss race conditions. There are unfortunately a number of situations where vap->iv_bss is changed or freed by some code in net80211. Because multiple threads can concurrently be doing work (and the vap->iv_bss access isn't at all done behind any kind of lock), it's quite possible that: * a change will occur in one thread - eg, by a call through ieee80211_sta_join1(); * a state change occurs in another thread - eg an RX is scheduled in the ath tasklet and it calls ieee80211_input_mimo_all(), which does dereference vap->iv_bss; * these two executing concurrently, causing things to explode. Another instance is ath_beacon_alloc() which takes an ieee80211_node *. It's called with the vap->iv_bss node from ath_newstate(). If the node has changed in the meantime (say it's been freed elsewhere) the reference that it grabbed _before_ refcounting it may be stale. I would _prefer_ that these sorts of things were serialised somewhere but that may be a bit much to ask. Instead, the best we can (currently) hope is that the underlying bss node is still (somewhat) valid. There is a related PR (kern/164382) described by the first case above. That should be fixed by properly serialising the RX path and reset path so an RX can't occur at the same time as the vap free/shutdown path. This is inspired by some related fixes in r212127. PR: kern/165060
2012-02-13 00:28:41 +00:00
/* XXX should take a locked ref to iv_bss */
don't do phantom beacon miss checking for s/w beacon miss handling, this can mistakenly drop events that cause the s/w bmiss timer to never get re-armed
2009-02-10 23:48:29 +00:00
u_int bmisstimeout =
vap->iv_bmissthreshold * vap->iv_bss->ni_intval * 1024;
DPRINTF(sc, ATH_DEBUG_BEACON,
"%s: tsf %llu lastrx %lld (%llu) bmiss %u\n",
__func__, (unsigned long long) tsf,
(unsigned long long)(tsf - lastrx),
(unsigned long long) lastrx, bmisstimeout);
if (tsf - lastrx <= bmisstimeout) {
sc->sc_stats.ast_bmiss_phantom++;
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ATH_LOCK(sc);
ath_power_restore_power_state(sc);
ATH_UNLOCK(sc);
don't do phantom beacon miss checking for s/w beacon miss handling, this can mistakenly drop events that cause the s/w bmiss timer to never get re-armed
2009-02-10 23:48:29 +00:00
return;
}
}
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
/*
[ath] force wake the hardware if we see a missed beacon. This adds a workaround to incorrectly behaving APs (ie, FreeBSD APs) which don't beacon out exactly when they should (at TBTT multiples of beacon intervals.) It forces the hardware awake (but leaves it in network-sleep so self generated frames still state that the hardware is asleep!) and will remain awake until the next sleep transition driven by net80211. That way if the beacons are just at the wrong interval, we get a much better chance of hearing more consecutive beacons before we go to sleep, thus not constantly disconnecting. Tested: * AR9485, STA mode, against a misbehaving FreeBSD AP.
2016-11-28 17:54:29 +00:00
* Keep the hardware awake if it's asleep (and leave self-gen
* frame config alone) until the next beacon, so we can resync
* against the next beacon.
*
* This handles three common beacon miss cases in STA powersave mode -
* (a) the beacon TBTT isnt a multiple of bintval;
* (b) the beacon was missed; and
* (c) the beacons are being delayed because the AP is busy and
* isn't reliably able to meet its TBTT.
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
*/
ATH_LOCK(sc);
[ath] force wake the hardware if we see a missed beacon. This adds a workaround to incorrectly behaving APs (ie, FreeBSD APs) which don't beacon out exactly when they should (at TBTT multiples of beacon intervals.) It forces the hardware awake (but leaves it in network-sleep so self generated frames still state that the hardware is asleep!) and will remain awake until the next sleep transition driven by net80211. That way if the beacons are just at the wrong interval, we get a much better chance of hearing more consecutive beacons before we go to sleep, thus not constantly disconnecting. Tested: * AR9485, STA mode, against a misbehaving FreeBSD AP.
2016-11-28 17:54:29 +00:00
ath_power_setpower(sc, HAL_PM_AWAKE, 0);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ath_power_restore_power_state(sc);
ATH_UNLOCK(sc);
[ath] force wake the hardware if we see a missed beacon. This adds a workaround to incorrectly behaving APs (ie, FreeBSD APs) which don't beacon out exactly when they should (at TBTT multiples of beacon intervals.) It forces the hardware awake (but leaves it in network-sleep so self generated frames still state that the hardware is asleep!) and will remain awake until the next sleep transition driven by net80211. That way if the beacons are just at the wrong interval, we get a much better chance of hearing more consecutive beacons before we go to sleep, thus not constantly disconnecting. Tested: * AR9485, STA mode, against a misbehaving FreeBSD AP.
2016-11-28 17:54:29 +00:00
DPRINTF(sc, ATH_DEBUG_BEACON,
"%s: forced awake; force syncbeacon=1\n", __func__);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
/*
* Attempt to force a beacon resync.
*/
sc->sc_syncbeacon = 1;
don't do phantom beacon miss checking for s/w beacon miss handling, this can mistakenly drop events that cause the s/w bmiss timer to never get re-armed
2009-02-10 23:48:29 +00:00
ATH_VAP(vap)->av_bmiss(vap);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
}
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
/* XXX this needs a force wakeup! */
Overhaul the TXQ locking (again!) as part of some beacon/cabq timing related issues. Moving the TX locking under one lock made things easier to progress on but it had one important side-effect - it increased the latency when handling CABQ setup when sending beacons. This commit introduces a bunch of new changes and a few unrelated changs that are just easier to lump in here. The aim is to have the CABQ locking separate from other locking. The CABQ transmit path in the beacon process thus doesn't have to grab the general TX lock, reducing lock contention/latency and making it more likely that we'll make the beacon TX timing. The second half of this commit is the CABQ related setup changes needed for sane looking EDMA CABQ support. Right now the EDMA TX code naively assumes that only one frame (MPDU or A-MPDU) is being pushed into each FIFO slot. For the CABQ this isn't true - a whole list of frames is being pushed in - and thus CABQ handling breaks very quickly. The aim here is to setup the CABQ list and then push _that list_ to the hardware for transmission. I can then extend the EDMA TX code to stamp that list as being "one" FIFO entry (likely by tagging the last buffer in that list as "FIFO END") so the EDMA TX completion code correctly tracks things. Major: * Migrate the per-TXQ add/removal locking back to per-TXQ, rather than a single lock. * Leave the software queue side of things under the ATH_TX_LOCK lock, (continuing) to serialise things as they are. * Add a new function which is called whenever there's a beacon miss, to print out some debugging. This is primarily designed to help me figure out if the beacon miss events are due to a noisy environment, issues with the PHY/MAC, or other. * Move the CABQ setup/enable to occur _after_ all the VAPs have been looked at. This means that for multiple VAPS in bursted mode, the CABQ gets primed once all VAPs are checked, rather than being primed on the first VAP and then having frames appended after this. Minor: * Add a (disabled) twiddle to let me enable/disable cabq traffic. It's primarily there to let me easily debug what's going on with beacon and CABQ setup/traffic; there's some DMA engine hangs which I'm finally trying to trace down. * Clear bf_next when flushing frames; it should quieten some warnings that show up when a node goes away. Tested: * AR9280, STA/hostap, up to 4 vaps (staggered) * AR5416, STA/hostap, up to 4 vaps (staggered) TODO: * (Lots) more AR9380 and later testing, as I may have missed something here. * Leverage this to fix CABQ hanling for AR9380 and later chips. * Force bursted beaconing on the chips that default to staggered beacons and ensure the CABQ stuff is all sane (eg, the MORE bits that aren't being correctly set when chaining descriptors.)
2013-03-24 00:03:12 +00:00
int
some of the 11n parts can hang under certain conditions without necessary workarounds, add code to detect these hangs and distinguish them from other events; note this code is only invoked for anomalous conditions and (at the moment) is a noop because the hang detection code is in a new hal that's coming shortly
2008-11-30 18:34:27 +00:00
ath_hal_gethangstate(struct ath_hal *ah, uint32_t mask, uint32_t *hangs)
{
uint32_t rsize;
void *sp;
Use the now-exposed diag code, rather than a hard-coded magic number.
2011-01-20 04:59:11 +00:00
if (!ath_hal_getdiagstate(ah, HAL_DIAG_CHECK_HANGS, &mask, sizeof(mask), &sp, &rsize))
some of the 11n parts can hang under certain conditions without necessary workarounds, add code to detect these hangs and distinguish them from other events; note this code is only invoked for anomalous conditions and (at the moment) is a noop because the hang detection code is in a new hal that's coming shortly
2008-11-30 18:34:27 +00:00
return 0;
KASSERT(rsize == sizeof(uint32_t), ("resultsize %u", rsize));
*hangs = *(uint32_t *)sp;
return 1;
}
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
static void
ath_bmiss_proc(void *arg, int pending)
{
struct ath_softc *sc = arg;
some of the 11n parts can hang under certain conditions without necessary workarounds, add code to detect these hangs and distinguish them from other events; note this code is only invoked for anomalous conditions and (at the moment) is a noop because the hang detection code is in a new hal that's coming shortly
2008-11-30 18:34:27 +00:00
uint32_t hangs;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
Update with last year of work.
2004-12-08 17:34:36 +00:00
DPRINTF(sc, ATH_DEBUG_ANY, "%s: pending %u\n", __func__, pending);
some of the 11n parts can hang under certain conditions without necessary workarounds, add code to detect these hangs and distinguish them from other events; note this code is only invoked for anomalous conditions and (at the moment) is a noop because the hang detection code is in a new hal that's coming shortly
2008-11-30 18:34:27 +00:00
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ATH_LOCK(sc);
ath_power_set_power_state(sc, HAL_PM_AWAKE);
ATH_UNLOCK(sc);
ath_beacon_miss(sc);
Fix hangs (exposed by spectral scan activity) in STA mode when the chip hangs. * Always do a reset in ath_bmiss_proc(), regardless of whether the hardware is "hung" or not. Specifically, for spectral scan, there's likely a whole bunch of potential hangs that we don't (yet) recognise in the HAL. So to avoid staying RX deaf persisting until the station disassociates, just do a no-loss reset. * Set sc_beacons=1 in STA mode. During a reset, the beacon programming isn't done. (It's likely I need to set sc_syncbeacons during a hang reset, but I digress.) Thus after a reset, there's no beacon timer programming to send a BMISS interrupt if beacons aren't heard .. thus if the AP disappears, you won't get notified and you'll have to reset your interface. This hasn't yet fixed all of the hangs that I've seen when debugging spectral scan, but it's certainly reduced the hang frequency and it should improve general STA stability in very noisy environments. Tested: * AR9280, STA mode, spectral scan off/on PR: kern/175227
2013-01-17 16:43:59 +00:00
/*
* Do a reset upon any becaon miss event.
*
* It may be a non-recognised RX clear hang which needs a reset
* to clear.
*/
some of the 11n parts can hang under certain conditions without necessary workarounds, add code to detect these hangs and distinguish them from other events; note this code is only invoked for anomalous conditions and (at the moment) is a noop because the hang detection code is in a new hal that's coming shortly
2008-11-30 18:34:27 +00:00
if (ath_hal_gethangstate(sc->sc_ah, 0xff, &hangs) && hangs != 0) {
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
ath_reset(sc, ATH_RESET_NOLOSS);
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
device_printf(sc->sc_dev,
"bb hang detected (0x%x), resetting\n", hangs);
Fix hangs (exposed by spectral scan activity) in STA mode when the chip hangs. * Always do a reset in ath_bmiss_proc(), regardless of whether the hardware is "hung" or not. Specifically, for spectral scan, there's likely a whole bunch of potential hangs that we don't (yet) recognise in the HAL. So to avoid staying RX deaf persisting until the station disassociates, just do a no-loss reset. * Set sc_beacons=1 in STA mode. During a reset, the beacon programming isn't done. (It's likely I need to set sc_syncbeacons during a hang reset, but I digress.) Thus after a reset, there's no beacon timer programming to send a BMISS interrupt if beacons aren't heard .. thus if the AP disappears, you won't get notified and you'll have to reset your interface. This hasn't yet fixed all of the hangs that I've seen when debugging spectral scan, but it's certainly reduced the hang frequency and it should improve general STA stability in very noisy environments. Tested: * AR9280, STA mode, spectral scan off/on PR: kern/175227
2013-01-17 16:43:59 +00:00
} else {
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
ath_reset(sc, ATH_RESET_NOLOSS);
ieee80211_beacon_miss(&sc->sc_ic);
Fix hangs (exposed by spectral scan activity) in STA mode when the chip hangs. * Always do a reset in ath_bmiss_proc(), regardless of whether the hardware is "hung" or not. Specifically, for spectral scan, there's likely a whole bunch of potential hangs that we don't (yet) recognise in the HAL. So to avoid staying RX deaf persisting until the station disassociates, just do a no-loss reset. * Set sc_beacons=1 in STA mode. During a reset, the beacon programming isn't done. (It's likely I need to set sc_syncbeacons during a hang reset, but I digress.) Thus after a reset, there's no beacon timer programming to send a BMISS interrupt if beacons aren't heard .. thus if the AP disappears, you won't get notified and you'll have to reset your interface. This hasn't yet fixed all of the hangs that I've seen when debugging spectral scan, but it's certainly reduced the hang frequency and it should improve general STA stability in very noisy environments. Tested: * AR9280, STA mode, spectral scan off/on PR: kern/175227
2013-01-17 16:43:59 +00:00
}
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
/* Force a beacon resync, in case they've drifted */
sc->sc_syncbeacon = 1;
ATH_LOCK(sc);
ath_power_restore_power_state(sc);
ATH_UNLOCK(sc);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
/*
* Handle TKIP MIC setup to deal hardware that doesn't do MIC
* calcs together with WME. If necessary disable the crypto
* hardware and mark the 802.11 state so keys will be setup
* with the MIC work done in software.
*/
static void
ath_settkipmic(struct ath_softc *sc)
{
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
struct ieee80211com *ic = &sc->sc_ic;
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
if ((ic->ic_cryptocaps & IEEE80211_CRYPTO_TKIP) && !sc->sc_wmetkipmic) {
if (ic->ic_flags & IEEE80211_F_WME) {
ath_hal_settkipmic(sc->sc_ah, AH_FALSE);
ic->ic_cryptocaps &= ~IEEE80211_CRYPTO_TKIPMIC;
} else {
ath_hal_settkipmic(sc->sc_ah, AH_TRUE);
ic->ic_cryptocaps |= IEEE80211_CRYPTO_TKIPMIC;
}
}
}
[ath] initial station side quiet IE support. This implements hardware assisted quiet IE support. Quiet time is an optional interval on DFS channels (but doesn't have to be DFS only channels! sigh) where the station and AP can be quiet in order to allow for channel utilisation measurements. Typically that's stuff like radar detection, spectral scan, other-BSS frame sniffing, checking how busy the air is, etc. The hardware implements it as one of the generic timers, which is supplied a period, offset from the trigger period and duration to stay quiet. The AP can announce quiet time configurations which change, and so this code also tracks that. Implementation details: * track the current quiet time IE * compare the new one against the previous one - if only the TBTT counter changes, don't update things * If tbttcount=1 then program it into the hardware - that is when it is easiest to program the correct starting offset (one TBTT + configured offset). * .. later on check to see if it can be done on any tbttcount * If the IE goes away then remove the quiet timer and clear the config * Upon reset, state change, new beacon - clear quiet time IE and just let it resync from the next beacon. History: This was work done initially by sibridgetech.com in 2011/2012/2013 as part of some FreeBSD wifi DFS contracting work they had for a third party. They implemented the net80211 quiet time IE pieces and had some test code for the station side which didn't entirely use the timers correctly. I figured out how to use the timers correctly without stopping/starting the transmit DMA engine each time. When done correctly, the timer just needs to be programmed once and left alone until the next configuration change. So, thanks to Himali Patel and Parthiv Shah for their work way back then. I finally figured it out and finished it! TODO: * Now, I'd rather net80211 did the quiet time IE tracking and parsing, pushing configurations into the driver is needed. I'll look at doing that in a subsequent update. * This doesn't handle multiple quiet time IEs, which will currently just mess things up. I'll look into supporting that in the future (at least by only obeying "one" of them, and then ignoring subsequent IEs in a beacon/probe frame.) * This also implements the STA side and not the AP side - the AP side will come later, and involves taking various other intervals into account (eg the beacon offset for multi-VAP modes, the SWBA time, etc, etc) as well as obtaining the configuration when a beacon is configured/generated rather than "hearing" an IE. * .. investigate supporting quiet IE in mesh, tdma, ibss modes * .. investigate supporting quiet IE for non-DFS channels (so this can be done for say, 2GHz channels.) * Chances are i should commit NULL methods for the ar5210, ar5211 HALs.. Tested: * AR9380, STA mode - announcing quiet, removing quiet, changing quite time config, whilst doing iperf testing; * AR9380, AP mode.
2017-02-09 23:15:11 +00:00
static void
ath_vap_clear_quiet_ie(struct ath_softc *sc)
{
struct ieee80211com *ic = &sc->sc_ic;
struct ieee80211vap *vap;
struct ath_vap *avp;
TAILQ_FOREACH(vap, &ic->ic_vaps, iv_next) {
avp = ATH_VAP(vap);
/* Quiet time handling - ensure we resync */
memset(&avp->quiet_ie, 0, sizeof(avp->quiet_ie));
}
}
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
static int
ath_init(struct ath_softc *sc)
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
{
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
struct ieee80211com *ic = &sc->sc_ic;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
struct ath_hal *ah = sc->sc_ah;
HAL_STATUS status;
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
ATH_LOCK_ASSERT(sc);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
/*
* Force the sleep state awake.
*/
Add tracking for self-generated frames when the VAP is in sleep state. The hardware can generate its own frames (eg RTS/CTS exchanges, other kinds of 802.11 management stuff, especially when it comes to 802.11n) and these also have PWRMGT flags. So if the VAP is asleep but the NIC is in force-awake for some reason, ensure that the self-generated frames have PWRMGT set to 1. Now, this (like basically everything to do with powersave) is still racy - the only way to guarantee that it's all actually consistent is to pause transmit and let it finish before transitioning the VAP to sleep, but this at least gets the basic method of tracking and updating the state debugged. Tested: * AR5416, STA mode * AR9380, STA mode
2014-05-02 00:48:09 +00:00
ath_power_setselfgen(sc, HAL_PM_AWAKE);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ath_power_set_power_state(sc, HAL_PM_AWAKE);
[ath] force wake the hardware if we see a missed beacon. This adds a workaround to incorrectly behaving APs (ie, FreeBSD APs) which don't beacon out exactly when they should (at TBTT multiples of beacon intervals.) It forces the hardware awake (but leaves it in network-sleep so self generated frames still state that the hardware is asleep!) and will remain awake until the next sleep transition driven by net80211. That way if the beacons are just at the wrong interval, we get a much better chance of hearing more consecutive beacons before we go to sleep, thus not constantly disconnecting. Tested: * AR9485, STA mode, against a misbehaving FreeBSD AP.
2016-11-28 17:54:29 +00:00
ath_power_setpower(sc, HAL_PM_AWAKE, 1);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
/*
* Stop anything previously setup. This is safe
* whether this is the first time through or not.
*/
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
ath_stop(sc);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
/*
* The basic interface to setting the hardware in a good
* state is ``reset''. On return the hardware is known to
* be powered up and with interrupts disabled. This must
* be followed by initialization of the appropriate bits
* and then setup of the interrupt mask.
*/
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
ath_settkipmic(sc);
Part #2 of the TX chainmask changes: * Remove ar5416UpdateChainmasks(); * Remove the TX chainmask override code from the ar5416 TX descriptor setup routines; * Write a driver method to calculate the current chainmask based on the operating mode and update the driver state; * Call the HAL chainmask method before calling ath_hal_reset(); * Use the currently configured chainmask in the TX descriptors rather than the hardware TX chainmasks. Tested: * AR5416, STA/AP mode - legacy and 11n modes
2013-02-25 22:45:02 +00:00
ath_update_chainmasks(sc, ic->ic_curchan);
ath_hal_setchainmasks(sc->sc_ah, sc->sc_cur_txchainmask,
sc->sc_cur_rxchainmask);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
if (!ath_hal_reset(ah, sc->sc_opmode, ic->ic_curchan, AH_FALSE,
ath(4): begin fleshing out a "reset type" extension to force cold/warn resets. Right now the only way to force a cold reset is: * The HAL itself detects it's needed, or * The sysctl, setting all resets to be cold. Trouble is, cold resets take quite a bit longer than warm resets. However, there are situations where a cold reset would be nice. Specifically, after a stuck beacon, BB/MAC hang, stuck calibration results, etc. The vendor HAL has a separate method to set the reset reason (which is how HAL_RESET_BBPANIC gets set) which informs the HAL during the reset path why it occured. This is almost but not quite the same; I may eventually unify both approaches in the future. This commit just extends HAL_RESET_TYPE to include both status (eg BBPANIC) and type (eg do COLD.) None of the HAL code uses it yet though; that'll come later. It also is a big no-op in each HAL - I need to go teach each of the HALs about cold/warm reset through this path.
2015-11-09 15:59:42 +00:00
HAL_RESET_NORMAL, &status)) {
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
device_printf(sc->sc_dev,
"unable to reset hardware; hal status %u\n", status);
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
return (ENODEV);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
Fix up the EDMA RX setup path to correctly initialise and reset the RX FIFO. The original code was .. well, slightly more than incorrect. It showed up as stalled RX queues if the NIC needed to be frequently reinitialised (eg during scans.) This is inspired by work done by Matt Dillon over at the DragonflyBSD project. So: * track when EDMA RX has been stopped and when the MAC has been reset; * re-initialise the ring only after a reset; * track whether RX has been stopped/started - just for debugging now; * don't bother with the RX EOL stuff for EDMA - we don't need the interrupt at all. We also don't need to disable/enable the interrupt or start DMA - once new frames are pushed into the ring via the normal RX path, it'll just restart RX DMA on its own. Tested: * AR9380, STA mode * AR9380, AP mode * AR9485, STA mode * AR9462, STA mode
2014-09-20 01:22:17 +00:00
ATH_RX_LOCK(sc);
sc->sc_rx_stopped = 1;
sc->sc_rx_resetted = 1;
ATH_RX_UNLOCK(sc);
[ath] initial station side quiet IE support. This implements hardware assisted quiet IE support. Quiet time is an optional interval on DFS channels (but doesn't have to be DFS only channels! sigh) where the station and AP can be quiet in order to allow for channel utilisation measurements. Typically that's stuff like radar detection, spectral scan, other-BSS frame sniffing, checking how busy the air is, etc. The hardware implements it as one of the generic timers, which is supplied a period, offset from the trigger period and duration to stay quiet. The AP can announce quiet time configurations which change, and so this code also tracks that. Implementation details: * track the current quiet time IE * compare the new one against the previous one - if only the TBTT counter changes, don't update things * If tbttcount=1 then program it into the hardware - that is when it is easiest to program the correct starting offset (one TBTT + configured offset). * .. later on check to see if it can be done on any tbttcount * If the IE goes away then remove the quiet timer and clear the config * Upon reset, state change, new beacon - clear quiet time IE and just let it resync from the next beacon. History: This was work done initially by sibridgetech.com in 2011/2012/2013 as part of some FreeBSD wifi DFS contracting work they had for a third party. They implemented the net80211 quiet time IE pieces and had some test code for the station side which didn't entirely use the timers correctly. I figured out how to use the timers correctly without stopping/starting the transmit DMA engine each time. When done correctly, the timer just needs to be programmed once and left alone until the next configuration change. So, thanks to Himali Patel and Parthiv Shah for their work way back then. I finally figured it out and finished it! TODO: * Now, I'd rather net80211 did the quiet time IE tracking and parsing, pushing configurations into the driver is needed. I'll look at doing that in a subsequent update. * This doesn't handle multiple quiet time IEs, which will currently just mess things up. I'll look into supporting that in the future (at least by only obeying "one" of them, and then ignoring subsequent IEs in a beacon/probe frame.) * This also implements the STA side and not the AP side - the AP side will come later, and involves taking various other intervals into account (eg the beacon offset for multi-VAP modes, the SWBA time, etc, etc) as well as obtaining the configuration when a beacon is configured/generated rather than "hearing" an IE. * .. investigate supporting quiet IE in mesh, tdma, ibss modes * .. investigate supporting quiet IE for non-DFS channels (so this can be done for say, 2GHz channels.) * Chances are i should commit NULL methods for the ar5210, ar5211 HALs.. Tested: * AR9380, STA mode - announcing quiet, removing quiet, changing quite time config, whilst doing iperf testing; * AR9380, AP mode.
2017-02-09 23:15:11 +00:00
/* Clear quiet IE state for each VAP */
ath_vap_clear_quiet_ie(sc);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
ath_chan_change(sc, ic->ic_curchan);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
Flesh out the radar detection related operations for the ath driver. This is in no way a complete DFS/radar detection implementation! It merely creates an abstracted interface which allows for future development of the DFS radar detection code. Note: Net80211 already handles the bulk of the DFS machinery, all we need to do here is figure out that a radar event has occured and inform it as such. It then drives the DFS state engine for us. The "null" DFS radar detection module is included by default; it doesn't require a device line. This commit: * Adds a simple abstracted layer for radar detection state - sys/dev/ath/ath_dfs/; * Implements a null DFS module which doesn't do anything; (ie, implements the exact behaviour at the moment); * Adds hooks to the ath driver to process received radar events and gives the DFS module a chance to determine whether a radar has been detected. Obtained from: Atheros
2011-06-01 20:09:49 +00:00
/* Let DFS at it in case it's a DFS channel */
ath_dfs_radar_enable(sc, ic->ic_curchan);
Add a new (skeleton) spectral mode manager module.
2013-01-02 03:59:02 +00:00
/* Let spectral at in case spectral is enabled */
ath_spectral_enable(sc, ic->ic_curchan);
Bring over the initial static bluetooth coexistence configuration for the WB195 combo NIC - an AR9285 w/ an AR3011 USB bluetooth NIC. The AR3011 is wired up using a 3-wire coexistence scheme to the AR9285. The code in if_ath_btcoex.c sets up the initial hardware mapping and coexistence configuration. There's nothing special about it - it's static; it doesn't try to configure bluetooth / MAC traffic priorities or try to figure out what's actually going on. It's enough to stop basic bluetooth traffic from causing traffic stalls and diassociation from the wireless network. To use this code, you must have the above NIC. No, it won't work for the AR9287+AR3012, nor the AR9485, AR9462 or AR955x combo cards. Then you set a kernel hint before boot or before kldload, where 'X' is the unit number of your AR9285 NIC: # kenv hint.ath.X.btcoex_profile=wb195 This will then appear in your boot messages: [100482] athX: Enabling WB195 BTCOEX This code is going to evolve pretty quickly (well, depending upon my spare time) so don't assume the btcoex API is going to stay stable. In order to use the bluetooth side, you must also load in firmware using ath3kfw and the binary firmware file (ath3k-1.fw in my case.) Tested: * AR9280, no interference * WB195 - AR9285 + AR3011 combo; STA mode; basic bluetooth inquiries were enough to cause traffic stalls and disassociations. This has stopped with the btcoex profile code. TODO: * Importantly - the AR9285 needs ASPM disabled if bluetooth coexistence is enabled. No, I don't know why. It's likely some kind of bug to do with the AR3011 sending bluetooth coexistence signals whilst the device is asleep. Since we don't actually sleep the MAC just yet, it shouldn't be a problem. That said, to be totally correct: + ASPM should be disabled - upon attach and wakeup + The PCIe powersave HAL code should never be called Look at what the ath9k driver does for inspiration. * Add WB197 (AR9287+AR3012) support * Add support for the AR9485, which is another combo like the AR9285 * The later NICs have a different signaling mechanism between the MAC and the bluetooth device; I haven't even begun to experiment with making that HAL code work. But it should be a lot more automatic. * The hardware can do much more interesting traffic weighting with bluetooth and wifi traffic. None of this is currently used. Ideally someone would code up something to watch the bluetooth traffic GPIO (via an interrupt) and then watch it go high/low; then figure out what the bluetooth traffic is and adjust things appropriately. * If I get the time I may add in some code to at least track this stuff and expose statistics. But it's up to someone else to experiment with the bluetooth coexistence support and add the interesting stuff (like "real" detection of bulk, audio, etc bluetooth traffic patterns and change wifi parameters appropriately - eg, maximum aggregate length, transmit power, using quiet time to control TX duty cycle, etc.)
2013-06-07 09:02:02 +00:00
/*
* Let bluetooth coexistence at in case it's needed for this channel
*/
ath_btcoex_enable(sc, ic->ic_curchan);
Enable the use of TDMA on an 802.11n channel (with aggregation disabled, of course.) There's a few things that needed to happen: * In case someone decides to set the beacon transmission rate to be at an MCS rate, use the MCS-aware version of the duration calculation to figure out how long the received beacon frame was. * If TxOP enforcing is available on the hardware and we're doing TDMA, enable it after a reset and set the TDMA guard interval to zero. This seems to behave fine. TODO: * Although I haven't yet seen packet loss, the PHY errors that would be triggered (specifically Transmit-Override-Receive) aren't enabled by the 11n HAL. I'll have to do some work to enable these PHY errors for debugging. What broke: * My recent changes to the TX queue handling has resulted in the driver not keeping the hardware queue properly filled when doing non-aggregate traffic. I have a patch to commit soon which fixes this situation (albeit by reminding me about how my ath driver locking isn't working out, sigh.) So if you want to test this without updating to the next set of patches that I commit, just bump the sysctl dev.ath.X.hwq_limit from 2 to 32. Tested: * AR5416 <-> AR5416, with ampdu disabled, HT40, 5GHz, MCS12+Short-GI. I saw 30mbit/sec in both directions using a bidirectional UDP test.
2013-05-21 18:02:54 +00:00
/*
* If we're doing TDMA, enforce the TXOP limitation for chips that
* support it.
*/
if (sc->sc_hasenforcetxop && sc->sc_tdma)
ath_hal_setenforcetxop(sc->sc_ah, 1);
else
ath_hal_setenforcetxop(sc->sc_ah, 0);
o fix setup of sc_diversity; the hal does not give us reliable status after attach, only after a reset o when setting diversity via the sysctl don't update sc_diversity until we know the hal requested worked o while here eliminate sc_hasdiversity and sc_hastpc; just query the hal each time since these are the only places we need to know MFC after: 3 days
2005-07-24 05:11:39 +00:00
/*
* Likewise this is set during reset so update
* state cached in the driver.
*/
sc->sc_diversity = ath_hal_getdiversity(ah);
Fix more ticks wrapping bugs exposed by the ticks wrapping bug check. This symptom is "calibrations don't ever run", which may cause some pretty spectacularly bad behaviour in noisy environments or with longer uptimes. Thanks to dtrace to make it easy to check if specific non-inlined functions are getting called by things like the ANI and calibration HAL methods. Grr. Tested: * AR9380, STA mode
2015-03-29 21:41:05 +00:00
sc->sc_lastlongcal = ticks;
New periodic calibration scheme needed for 11n parts that have multiple algorithms and potentially collect multiple samples. Instead of a single calibration interval we now have short and long intervals; the long interval roughly corresponds to the previous single interval. The short interval is used to speedup collection of samples and happens much quicker. We make calls using the short interval until we're told the calibration work is complete at which point we fallback to the long interval. In addition there is a much longer reset interval used to flush all calibration state and cause everthing to start anew. With these changes you can also disable calibration entirely by setting the long interval to zero.
2008-12-07 19:26:34 +00:00
sc->sc_resetcal = 1;
sc->sc_lastcalreset = 0;
Fix more ticks wrapping bugs exposed by the ticks wrapping bug check. This symptom is "calibrations don't ever run", which may cause some pretty spectacularly bad behaviour in noisy environments or with longer uptimes. Thanks to dtrace to make it easy to check if specific non-inlined functions are getting called by things like the ANI and calibration HAL methods. Grr. Tested: * AR9380, STA mode
2015-03-29 21:41:05 +00:00
sc->sc_lastani = ticks;
sc->sc_lastshortcal = ticks;
ANI changes #1 - split out the ANI polling from the RxMonitor hook. The rxmonitor hook is called on each received packet. This can get very, very busy as the tx/rx/chanbusy registers are thus read each time a packet is received. Instead, shuffle out the true per-packet processing which is needed and move the rest of the ANI processing into a periodic event which runs every 100ms by default.
2011-01-21 05:21:00 +00:00
sc->sc_doresetcal = AH_FALSE;
Fix beacon transmission after a channel set. The DFS code was tickling the channel set directly whilst going through the state RUN -> CSA -> RUN. This only changed the channel; it didn't go via ath_reset(). However in this driver, a channel change always causes a chip reset, which resets the beacon timer configuration and interrupt setup. This meant that data would go out but as the beacon timers never fired, beacons would never be queued. The confusing part is that sometimes the state transition was RUN -> SCAN -> CAC -> RUN (with CSA being in there sometimes); going via SCAN would clear sc_beacons and thus the transition to RUN would reprogram beacon transmission. In case someone tries debugging why suspending a device currently beaconing (versus just RX'ing beacons which is what occurs in STA mode), add a silly comment which should hopefully land them at this commit message. The call to ath_hal_reset() will be clearing the beacon config and it may not be always reset.
2011-06-26 13:53:24 +00:00
/*
* Beacon timers were cleared here; give ath_newstate()
* a hint that the beacon timers should be poked when
* things transition to the RUN state.
*/
sc->sc_beacons = 0;
Update with last year of work.
2004-12-08 17:34:36 +00:00
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
/*
* Setup the hardware after reset: the key cache
* is filled as needed and the receive engine is
* set going. Frame transmit is handled entirely
* in the frame output path; there's nothing to do
* here except setup the interrupt mask.
*/
if (ath_startrecv(sc) != 0) {
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
device_printf(sc->sc_dev, "unable to start recv logic\n");
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ath_power_restore_power_state(sc);
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
return (ENODEV);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
/*
* Enable interrupts.
*/
sc->sc_imask = HAL_INT_RX | HAL_INT_TX
Fix up the EDMA RX setup path to correctly initialise and reset the RX FIFO. The original code was .. well, slightly more than incorrect. It showed up as stalled RX queues if the NIC needed to be frequently reinitialised (eg during scans.) This is inspired by work done by Matt Dillon over at the DragonflyBSD project. So: * track when EDMA RX has been stopped and when the MAC has been reset; * re-initialise the ring only after a reset; * track whether RX has been stopped/started - just for debugging now; * don't bother with the RX EOL stuff for EDMA - we don't need the interrupt at all. We also don't need to disable/enable the interrupt or start DMA - once new frames are pushed into the ring via the normal RX path, it'll just restart RX DMA on its own. Tested: * AR9380, STA mode * AR9380, AP mode * AR9485, STA mode * AR9462, STA mode
2014-09-20 01:22:17 +00:00
| HAL_INT_RXORN | HAL_INT_TXURN
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
| HAL_INT_FATAL | HAL_INT_GLOBAL;
Flip on EDMA RX of both HP and LP queue frames. Yes, this is in the legacy interrupt path. The NIC does support MSI but I haven't yet sat down and written that code.
2012-07-10 07:43:31 +00:00
/*
* Enable RX EDMA bits. Note these overlap with
* HAL_INT_RX and HAL_INT_RXDESC respectively.
*/
if (sc->sc_isedma)
sc->sc_imask |= (HAL_INT_RXHP | HAL_INT_RXLP);
Fix up the EDMA RX setup path to correctly initialise and reset the RX FIFO. The original code was .. well, slightly more than incorrect. It showed up as stalled RX queues if the NIC needed to be frequently reinitialised (eg during scans.) This is inspired by work done by Matt Dillon over at the DragonflyBSD project. So: * track when EDMA RX has been stopped and when the MAC has been reset; * re-initialise the ring only after a reset; * track whether RX has been stopped/started - just for debugging now; * don't bother with the RX EOL stuff for EDMA - we don't need the interrupt at all. We also don't need to disable/enable the interrupt or start DMA - once new frames are pushed into the ring via the normal RX path, it'll just restart RX DMA on its own. Tested: * AR9380, STA mode * AR9380, AP mode * AR9485, STA mode * AR9462, STA mode
2014-09-20 01:22:17 +00:00
/*
* If we're an EDMA NIC, we don't care about RXEOL.
* Writing a new descriptor in will simply restart
* RX DMA.
*/
if (! sc->sc_isedma)
sc->sc_imask |= HAL_INT_RXEOL;
[ath] commit initial bluetooth coexistence support for the MCI NICs. This is the initial framework to call into the MCI HAL routines and drive the basic state engine. The MCI bluetooth coex model uses a command channel between wlan and bluetooth, rather than a 2-wire or 3-wire signaling protocol to control things. This means the wlan and bluetooth chip exchange a lot more information and signaling, even at the per-packet level. The NICs in question can share the input LNA and output PA on the die, so they absolutely can't stomp on each other in a silly fashion. It also allows for the bluetooth side to signal when profiles come and go, so the driver can take appropriate control. There's also the possibility of dynamic bluetooth/wlan duty cycle control which I haven't yet really played with. It configures things up with a static "wlan wins everything" coexistence, configures up the available 2GHz channel map for bluetooth, sets a static duty cycle for bluetooth/wifi traffic priority and drives the basics needed to keep the MCI HAL code happy. It doesn't do any actual coexistence except to default to "wlan wins everything", which at least demonstrates that things do indeed work. Bluetooth inquiry frames still trump wifi (including beacons), so that demonstrates things really do indeed seem to work. Tested: * AR9462 (WB222), STA mode + bt * QCA9565 (WB335), STA mode + bt TODO: * .. the rest of coexistence. yes, bluetooth, not people. That stuff's hard. * It doesn't do the initial BT side calibration, which requires a WLAN chip reset. I'll fix up the reset path a bit more first before I enable that. * The 1-ant and 2-ant configuration bits aren't being set correctly in if_ath_btcoex.c - I'll dig into that and fix it in a subsequent commit. * It's not enabled by default for WB222/WB225 even though I believe it now can be - I'll chase that up in a subsequent commit. Obtained from: Qualcomm Atheros, Linux ath9k
2016-06-02 00:51:36 +00:00
/*
* Enable MCI interrupt for MCI devices.
*/
if (sc->sc_btcoex_mci)
sc->sc_imask |= HAL_INT_MCI;
Update with last year of work.
2004-12-08 17:34:36 +00:00
/*
* Enable MIB interrupts when there are hardware phy counters.
* Note we only do this (at the moment) for station mode.
*/
if (sc->sc_needmib && ic->ic_opmode == IEEE80211_M_STA)
sc->sc_imask |= HAL_INT_MIB;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
/*
* XXX add capability for this.
*
* If we're in STA mode (and maybe IBSS?) then register for
* TSFOOR interrupts.
*/
if (ic->ic_opmode == IEEE80211_M_STA)
sc->sc_imask |= HAL_INT_TSFOOR;
Add TX carrier sense timeout statistics.
2011-04-18 14:06:18 +00:00
/* Enable global TX timeout and carrier sense timeout if available */
Add global TX timeout handling. The global TX timeout counter increments whenever a frame is ready to be transmitted and the medium is busy.
2011-04-18 12:15:43 +00:00
if (ath_hal_gtxto_supported(ah))
For now, only enable GTT. CST is firing very frequently during local tests; I'll figure out what's going on before re-enabling this as it does add to the interrupt load.
2011-04-18 14:14:54 +00:00
sc->sc_imask |= HAL_INT_GTT;
Rework the Global TX timeout handling to look more like ath9k. It correctly now sets the AR_IMR BCNMISC register, along with the GTT register in AR_IMR_S2.
2011-04-18 14:03:05 +00:00
DPRINTF(sc, ATH_DEBUG_RESET, "%s: imask=0x%x\n",
__func__, sc->sc_imask);
Add global TX timeout handling. The global TX timeout counter increments whenever a frame is ready to be transmitted and the medium is busy.
2011-04-18 12:15:43 +00:00
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
sc->sc_running = 1;
replace if_watchdog w/ private callout; probably can merge this with the calibration work sometime in the future
2009-03-09 23:10:19 +00:00
callout_reset(&sc->sc_wd_ch, hz, ath_watchdog, sc);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
ath_hal_intrset(ah, sc->sc_imask);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ath_power_restore_power_state(sc);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
return (0);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
static void
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
ath_stop(struct ath_softc *sc)
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
{
struct ath_hal *ah = sc->sc_ah;
Update with last year of work.
2004-12-08 17:34:36 +00:00
ATH_LOCK_ASSERT(sc);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
/*
* Wake the hardware up before fiddling with it.
*/
ath_power_set_power_state(sc, HAL_PM_AWAKE);
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
if (sc->sc_running) {
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
/*
* Shutdown the hardware and driver:
Update with last year of work.
2004-12-08 17:34:36 +00:00
* reset 802.11 state machine
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
* turn off timers
Update with last year of work.
2004-12-08 17:34:36 +00:00
* disable interrupts
* turn off the radio
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
* clear transmit machinery
* clear receive machinery
* drain and release tx queues
* reclaim beacon resources
* power down hardware
*
* Note that some of this work is not possible if the
* hardware is gone (invalid).
*/
add tx99 hooks MFC after: 2 weeks
2006-02-09 21:28:11 +00:00
#ifdef ATH_TX99_DIAG
if (sc->sc_tx99 != NULL)
sc->sc_tx99->stop(sc->sc_tx99);
#endif
replace if_watchdog w/ private callout; probably can merge this with the calibration work sometime in the future
2009-03-09 23:10:19 +00:00
callout_stop(&sc->sc_wd_ch);
sc->sc_wd_timer = 0;
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
sc->sc_running = 0;
Update with last year of work.
2004-12-08 17:34:36 +00:00
if (!sc->sc_invalid) {
better led blinking
2005-01-18 19:03:04 +00:00
if (sc->sc_softled) {
callout_stop(&sc->sc_ledtimer);
ath_hal_gpioset(ah, sc->sc_ledpin,
!sc->sc_ledon);
sc->sc_blinking = 0;
}
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
ath_hal_intrset(ah, 0);
Update with last year of work.
2004-12-08 17:34:36 +00:00
}
Shut down RX before TX - in theory, this should make the chip less likely to get upset. The Qualcomm Atheros reference design code goes through significant hacks to shut down RX before TX. It doesn't even try do do it in the driver - it actually makes the DMA stop routines in the HAL shut down RX before shutting down TX. So, to make this work for chips that aren't the AR9380 and later, do it in the driver. Shuffle the TX stop/drain HAL calls to be called *after* the RX stop HAL call. Tested: * AR5413 (STA) * AR5212 (STA) * AR5416 (STA) * AR9380 (STA) * AR9331 (AP) * AR9341 (AP) TODO: * test ar92xx series NIC and the AR5210/AR5211, in case there's something even odder about those.
2014-08-23 18:55:51 +00:00
/* XXX we should stop RX regardless of whether it's valid */
Update with last year of work.
2004-12-08 17:34:36 +00:00
if (!sc->sc_invalid) {
Begin breaking apart the receive setup/stop path in preparation for more "correct" handling of frames in the RX pending queue during interface transitions. * ath_stoprecv() doesn't blank out the descriptor list - that's what ath_startrecv() does. So, change a comment to reflect that. * ath_stoprecv() does include a large (3ms) delay to let pending DMA complete. However, I'm under the impression that the stopdma hal method does check for a bit in the PCU to indicate DMA has stopped. So, to help with fast abort and restart, modify ath_stoprecv() to take a flag which indicates whether this is needed. * Modify the uses of ath_stoprecv() to pass in a flag to support the existing behaviour (ie, do the delay.) * Remove some duplicate PCU teardown code (which wasn't shutting down DMA, so it wasn't entirely correct..) and replace it with a call to ath_stoprecv(sc, 0) - which disables the DELAY call. The upshoot of this is now channel change doesn't simply drop completed frames on the floor, but instead it cleanly handles those frames. It still discards pending TX frames in the software and hardware queues as there's no (current) logic which forcibly recalculates the rate control information (or whether they're appropriate to be on the TX queue after a channel change), that'll come later. This still doesn't stop all the sources of queue stalls but it does tidy up some of the code duplication. To be complete, queue stalls now occur during normal behaviour - they only occur after some kind of broken behaviour causes an interface or node flush, upsetting the TX/RX BAW. Subsequent commits will incrementally fix these and other related issues. Sponsored by: Hobnob, Inc.
2011-11-19 21:05:31 +00:00
ath_stoprecv(sc, 1);
Update with last year of work.
2004-12-08 17:34:36 +00:00
ath_hal_phydisable(ah);
} else
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
sc->sc_rxlink = NULL;
Shut down RX before TX - in theory, this should make the chip less likely to get upset. The Qualcomm Atheros reference design code goes through significant hacks to shut down RX before TX. It doesn't even try do do it in the driver - it actually makes the DMA stop routines in the HAL shut down RX before shutting down TX. So, to make this work for chips that aren't the AR9380 and later, do it in the driver. Shuffle the TX stop/drain HAL calls to be called *after* the RX stop HAL call. Tested: * AR5413 (STA) * AR5212 (STA) * AR5416 (STA) * AR9380 (STA) * AR9331 (AP) * AR9341 (AP) TODO: * test ar92xx series NIC and the AR5210/AR5211, in case there's something even odder about those.
2014-08-23 18:55:51 +00:00
ath_draintxq(sc, ATH_RESET_DEFAULT);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
ath_beacon_free(sc); /* XXX not needed */
Update with last year of work.
2004-12-08 17:34:36 +00:00
}
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
/* And now, restore the current power state */
ath_power_restore_power_state(sc);
Update with last year of work.
2004-12-08 17:34:36 +00:00
}
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
/*
* Wait until all pending TX/RX has completed.
*
* This waits until all existing transmit, receive and interrupts
* have completed. It's assumed that the caller has first
* grabbed the reset lock so it doesn't try to do overlapping
* chip resets.
*/
#define MAX_TXRX_ITERATIONS 100
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
static void
Begin breaking out the txrx stop code into a locked and unlocked variant. PR: kern/165220
2012-02-17 03:23:01 +00:00
ath_txrx_stop_locked(struct ath_softc *sc)
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
{
int i = MAX_TXRX_ITERATIONS;
ATH_UNLOCK_ASSERT(sc);
Begin breaking out the txrx stop code into a locked and unlocked variant. PR: kern/165220
2012-02-17 03:23:01 +00:00
ATH_PCU_LOCK_ASSERT(sc);
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
/*
* Sleep until all the pending operations have completed.
*
* The caller must ensure that reset has been incremented
* or the pending operations may continue being queued.
*/
while (sc->sc_rxproc_cnt || sc->sc_txproc_cnt ||
sc->sc_txstart_cnt || sc->sc_intr_cnt) {
Fix some whitespace pollution.
2011-11-21 21:59:01 +00:00
if (i <= 0)
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
break;
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
msleep(sc, &sc->sc_pcu_mtx, 0, "ath_txrx_stop",
msecs_to_ticks(10));
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
i--;
}
if (i <= 0)
device_printf(sc->sc_dev,
"%s: didn't finish after %d iterations\n",
__func__, MAX_TXRX_ITERATIONS);
}
#undef MAX_TXRX_ITERATIONS
Enforce some consistent ordering and handling of interrupt disable/enable with RX/TX halting. * Always disable/enable interrupts during a channel change, just to simply things. * Ensure that the ath taskqueue has completed and is paused before continuing. This dramatically reduces the instances of overlapping RX and reset conditions. PR: kern/165220
2012-02-17 03:46:38 +00:00
#if 0
Begin breaking out the txrx stop code into a locked and unlocked variant. PR: kern/165220
2012-02-17 03:23:01 +00:00
static void
ath_txrx_stop(struct ath_softc *sc)
{
ATH_UNLOCK_ASSERT(sc);
ATH_PCU_UNLOCK_ASSERT(sc);
ATH_PCU_LOCK(sc);
ath_txrx_stop_locked(sc);
ATH_PCU_UNLOCK(sc);
}
Enforce some consistent ordering and handling of interrupt disable/enable with RX/TX halting. * Always disable/enable interrupts during a channel change, just to simply things. * Ensure that the ath taskqueue has completed and is paused before continuing. This dramatically reduces the instances of overlapping RX and reset conditions. PR: kern/165220
2012-02-17 03:46:38 +00:00
#endif
Begin breaking out the txrx stop code into a locked and unlocked variant. PR: kern/165220
2012-02-17 03:23:01 +00:00
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
static void
ath_txrx_start(struct ath_softc *sc)
{
taskqueue_unblock(sc->sc_tq);
}
Rework this ugly mess that tries to handle reset serialisation. Some users were reporting concurrent resets _were_ occuring - ie, either two ath_reset()s ran at the same time (likely one on each CPU) or ath_reset() versus ath_chan_change(). Instead, this now tries to grab the serialisation semaphore and will pause() for a while if it fails. It will always eventually succeed though and will log an error if it hits the recursion situation. All of this stuff needs to die a horrible death at some point and be replaced with a properly serialising method of programming this stuff (eg using the net80211 taskqueue for all of this stuff.) The trouble is figuring out how to handle the concurrent ioctl() based things without introducing more LORs (which is another reason why I haven't just wrapped all of this stuff in large, long-lived locks, a-la what Linux can get away with.) MFC after: Absolutely, positively never.
2011-12-23 03:59:49 +00:00
/*
dev/ath: minor spelling fixes in comments. No functional change. Reviewed by: adrian
2016-05-02 19:56:48 +00:00
* Grab the reset lock, and wait around until no one else
Rework this ugly mess that tries to handle reset serialisation. Some users were reporting concurrent resets _were_ occuring - ie, either two ath_reset()s ran at the same time (likely one on each CPU) or ath_reset() versus ath_chan_change(). Instead, this now tries to grab the serialisation semaphore and will pause() for a while if it fails. It will always eventually succeed though and will log an error if it hits the recursion situation. All of this stuff needs to die a horrible death at some point and be replaced with a properly serialising method of programming this stuff (eg using the net80211 taskqueue for all of this stuff.) The trouble is figuring out how to handle the concurrent ioctl() based things without introducing more LORs (which is another reason why I haven't just wrapped all of this stuff in large, long-lived locks, a-la what Linux can get away with.) MFC after: Absolutely, positively never.
2011-12-23 03:59:49 +00:00
* is trying to do anything with it.
*
* This is totally horrible but we can't hold this lock for
* long enough to do TX/RX or we end up with net80211/ip stack
* LORs and eventual deadlock.
*
* "dowait" signals whether to spin, waiting for the reset
* lock count to reach 0. This should (for now) only be used
* during the reset path, as the rest of the code may not
* be locking-reentrant enough to behave correctly.
*
* Another, cleaner way should be found to serialise all of
* these operations.
*/
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
#define MAX_RESET_ITERATIONS 25
Rework this ugly mess that tries to handle reset serialisation. Some users were reporting concurrent resets _were_ occuring - ie, either two ath_reset()s ran at the same time (likely one on each CPU) or ath_reset() versus ath_chan_change(). Instead, this now tries to grab the serialisation semaphore and will pause() for a while if it fails. It will always eventually succeed though and will log an error if it hits the recursion situation. All of this stuff needs to die a horrible death at some point and be replaced with a properly serialising method of programming this stuff (eg using the net80211 taskqueue for all of this stuff.) The trouble is figuring out how to handle the concurrent ioctl() based things without introducing more LORs (which is another reason why I haven't just wrapped all of this stuff in large, long-lived locks, a-la what Linux can get away with.) MFC after: Absolutely, positively never.
2011-12-23 03:59:49 +00:00
static int
ath_reset_grablock(struct ath_softc *sc, int dowait)
{
int w = 0;
int i = MAX_RESET_ITERATIONS;
ATH_PCU_LOCK_ASSERT(sc);
do {
if (sc->sc_inreset_cnt == 0) {
w = 1;
break;
}
if (dowait == 0) {
w = 0;
break;
}
ATH_PCU_UNLOCK(sc);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
/*
* 1 tick is likely not enough time for long calibrations
* to complete. So we should wait quite a while.
*/
pause("ath_reset_grablock", msecs_to_ticks(100));
Rework this ugly mess that tries to handle reset serialisation. Some users were reporting concurrent resets _were_ occuring - ie, either two ath_reset()s ran at the same time (likely one on each CPU) or ath_reset() versus ath_chan_change(). Instead, this now tries to grab the serialisation semaphore and will pause() for a while if it fails. It will always eventually succeed though and will log an error if it hits the recursion situation. All of this stuff needs to die a horrible death at some point and be replaced with a properly serialising method of programming this stuff (eg using the net80211 taskqueue for all of this stuff.) The trouble is figuring out how to handle the concurrent ioctl() based things without introducing more LORs (which is another reason why I haven't just wrapped all of this stuff in large, long-lived locks, a-la what Linux can get away with.) MFC after: Absolutely, positively never.
2011-12-23 03:59:49 +00:00
i--;
ATH_PCU_LOCK(sc);
} while (i > 0);
/*
* We always increment the refcounter, regardless
* of whether we succeeded to get it in an exclusive
* way.
*/
sc->sc_inreset_cnt++;
if (i <= 0)
device_printf(sc->sc_dev,
"%s: didn't finish after %d iterations\n",
__func__, MAX_RESET_ITERATIONS);
if (w == 0)
device_printf(sc->sc_dev,
"%s: warning, recursive reset path!\n",
__func__);
return w;
}
#undef MAX_RESET_ITERATIONS
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
/*
* Reset the hardware w/o losing operational state. This is
* basically a more efficient way of doing ath_stop, ath_init,
* followed by state transitions to the current 802.11
Update with last year of work.
2004-12-08 17:34:36 +00:00
* operational state. Used to recover from various errors and
* to reset or reload hardware state.
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
*/
Migrate the sysctl related routines (statistics, debugging, etc) out of if_ath.c and into if_ath_sysctl.c .
2011-03-02 16:03:19 +00:00
int
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
ath_reset(struct ath_softc *sc, ATH_RESET_TYPE reset_type)
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
{
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
struct ieee80211com *ic = &sc->sc_ic;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
struct ath_hal *ah = sc->sc_ah;
HAL_STATUS status;
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
int i;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
Add KTR tracepoints to the ath driver, in order to debug TX, RX and interrupt handling. Sponsored by: Hobnob, Inc.
2011-11-08 19:02:59 +00:00
DPRINTF(sc, ATH_DEBUG_RESET, "%s: called\n", __func__);
Some more various fixes, etc from my 11n branch. * When doing software TX queue handling and flush, it's possible that the deletion of a VAP (eg a STA shutdown) will queue a "STA Disassociate" frame whilst the interface is being deleted. The VAP is then deleted, and the frame ends up being queued to a node that is freed before it can be TX'ed. Things go awry at this point. There's no way at the present to avoid freeing the underlying node when the vap is being deleted. It's too late in the game. I suspect the real fix is to make sure the frame is software queued with no completion information somehow, so it doesn't link back to a node whose underlying VAP has been freed. For now, we'll just have to do this. * Add some comments showing what's going on. * Move an instance of the ATH_LOCK() around to protect the interrupt set. I'll worry about changing that to a PCU lock later on once the 11n code is in the tree. Sponsored by: Hobnob, Inc.
2011-11-08 19:18:34 +00:00
Rework this ugly mess that tries to handle reset serialisation. Some users were reporting concurrent resets _were_ occuring - ie, either two ath_reset()s ran at the same time (likely one on each CPU) or ath_reset() versus ath_chan_change(). Instead, this now tries to grab the serialisation semaphore and will pause() for a while if it fails. It will always eventually succeed though and will log an error if it hits the recursion situation. All of this stuff needs to die a horrible death at some point and be replaced with a properly serialising method of programming this stuff (eg using the net80211 taskqueue for all of this stuff.) The trouble is figuring out how to handle the concurrent ioctl() based things without introducing more LORs (which is another reason why I haven't just wrapped all of this stuff in large, long-lived locks, a-la what Linux can get away with.) MFC after: Absolutely, positively never.
2011-12-23 03:59:49 +00:00
/* Ensure ATH_LOCK isn't held; ath_rx_proc can't be locked */
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
ATH_PCU_UNLOCK_ASSERT(sc);
ATH_UNLOCK_ASSERT(sc);
dev/ath: minor spelling fixes in comments. No functional change. Reviewed by: adrian
2016-05-02 19:56:48 +00:00
/* Try to (stop any further TX/RX from occurring */
Attempt to further fix some of the concurrency/reset issues that occur. * ath_reset() is being called in softclock context, which may have the thing sleep on a lock. To avoid this, since we really _shouldn't_ be sleeping on any locks, break out the no-loss reset path into a tasklet and call that from: + ath_calibrate() + ath_watchdog() This has the added advantage that it'll end up also doing the frame RX cleanup from within the taskqueue context, rather than the softclock context. * Shuffle around the taskqueue_block() call to be before we grab the lock and disable interrupts. The trouble here is that taskqueue_block() doesn't block currently queued (but not yet running) tasks so calling it doesn't guarantee no further tasks (that weren't running on _A_ CPU at the time of this call) will complete. Calling taskqueue_drain() on these tasks won't work because if any _other_ thread calls taskqueue_enqueue() for whatever reason, everything gets very angry and stops working. This slightly changes the race condition enough to let ath_rx_tasklet() run before we try disabling it, and thus quietens the warnings a bit. The (more) true solution will be doing something like the following: * having a taskqueue_blocked mask in ath_softc; * having an interrupt_blocked mask in ath_softc; * only calling taskqueue_drain() on each individual task _after_ the lock has been acquired - that way no further tasklet scheduling is going to occur. * Then once the tasks have been blocked _and_ the interrupt has been disabled, call taskqueue_drain() on each, ensuring that anything that _was_ scheduled or running is removed. The trouble is if something calls taskqueue_enqueue() on a task after taskqueue_blocked() has been called but BEFORE taskqueue_drain() has been called, ta_pending will be set to 1 and taskqueue_drain() will sit there stuck in msleep() until you hard-kill the machine. PR: kern/165382 PR: kern/165220
2012-02-25 19:12:54 +00:00
taskqueue_block(sc->sc_tq);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
/*
* Wake the hardware up.
*/
ATH_LOCK(sc);
ath_power_set_power_state(sc, HAL_PM_AWAKE);
ATH_UNLOCK(sc);
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
ATH_PCU_LOCK(sc);
Fix the order of TX shutdown and reset. * Grab the reset lock first, so any subsequent interrupt, TX, RX work will fail * Then shut down interrupts * Then wait for TX/RX to finish running At this point no further work will be running, so it's safe to do the reset path code. PR: kern/179232
2013-06-03 19:39:37 +00:00
/*
* Grab the reset lock before TX/RX is stopped.
*
* This is needed to ensure that when the TX/RX actually does finish,
* no further TX/RX/reset runs in parallel with this.
*/
Rework this ugly mess that tries to handle reset serialisation. Some users were reporting concurrent resets _were_ occuring - ie, either two ath_reset()s ran at the same time (likely one on each CPU) or ath_reset() versus ath_chan_change(). Instead, this now tries to grab the serialisation semaphore and will pause() for a while if it fails. It will always eventually succeed though and will log an error if it hits the recursion situation. All of this stuff needs to die a horrible death at some point and be replaced with a properly serialising method of programming this stuff (eg using the net80211 taskqueue for all of this stuff.) The trouble is figuring out how to handle the concurrent ioctl() based things without introducing more LORs (which is another reason why I haven't just wrapped all of this stuff in large, long-lived locks, a-la what Linux can get away with.) MFC after: Absolutely, positively never.
2011-12-23 03:59:49 +00:00
if (ath_reset_grablock(sc, 1) == 0) {
device_printf(sc->sc_dev, "%s: concurrent reset! Danger!\n",
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
__func__);
}
Fix the order of TX shutdown and reset. * Grab the reset lock first, so any subsequent interrupt, TX, RX work will fail * Then shut down interrupts * Then wait for TX/RX to finish running At this point no further work will be running, so it's safe to do the reset path code. PR: kern/179232
2013-06-03 19:39:37 +00:00
/* disable interrupts */
ath_hal_intrset(ah, 0);
/*
* Now, ensure that any in progress TX/RX completes before we
* continue.
*/
ath_txrx_stop_locked(sc);
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
ATH_PCU_UNLOCK(sc);
Add KTR tracepoints to the ath driver, in order to debug TX, RX and interrupt handling. Sponsored by: Hobnob, Inc.
2011-11-08 19:02:59 +00:00
/*
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
* Regardless of whether we're doing a no-loss flush or
* not, stop the PCU and handle what's in the RX queue.
* That way frames aren't dropped which shouldn't be.
Add KTR tracepoints to the ath driver, in order to debug TX, RX and interrupt handling. Sponsored by: Hobnob, Inc.
2011-11-08 19:02:59 +00:00
*/
Begin breaking apart the receive setup/stop path in preparation for more "correct" handling of frames in the RX pending queue during interface transitions. * ath_stoprecv() doesn't blank out the descriptor list - that's what ath_startrecv() does. So, change a comment to reflect that. * ath_stoprecv() does include a large (3ms) delay to let pending DMA complete. However, I'm under the impression that the stopdma hal method does check for a bit in the PCU to indicate DMA has stopped. So, to help with fast abort and restart, modify ath_stoprecv() to take a flag which indicates whether this is needed. * Modify the uses of ath_stoprecv() to pass in a flag to support the existing behaviour (ie, do the delay.) * Remove some duplicate PCU teardown code (which wasn't shutting down DMA, so it wasn't entirely correct..) and replace it with a call to ath_stoprecv(sc, 0) - which disables the DELAY call. The upshoot of this is now channel change doesn't simply drop completed frames on the floor, but instead it cleanly handles those frames. It still discards pending TX frames in the software and hardware queues as there's no (current) logic which forcibly recalculates the rate control information (or whether they're appropriate to be on the TX queue after a channel change), that'll come later. This still doesn't stop all the sources of queue stalls but it does tidy up some of the code duplication. To be complete, queue stalls now occur during normal behaviour - they only occur after some kind of broken behaviour causes an interface or node flush, upsetting the TX/RX BAW. Subsequent commits will incrementally fix these and other related issues. Sponsored by: Hobnob, Inc.
2011-11-19 21:05:31 +00:00
ath_stoprecv(sc, (reset_type != ATH_RESET_NOLOSS));
Begin abstracting out the RX path in preparation for RX EDMA support. The RX EDMA support requires a modified approach to the RX descriptor handling. Specifically: * There's now two RX queues - high and low priority; * The RX queues are implemented as FIFOs; they're now an array of pointers to buffers; * .. and the RX buffer and descriptor are in the same "buffer", rather than being separate. So to that end, this commit abstracts out most of the RX related functions from the bulk of the driver. Notably, the RX DMA/buffer allocation isn't updated, primarily because I haven't yet fleshed out what it should look like. Whilst I'm here, create a set of matching but mostly unimplemented EDMA stubs. Tested: * AR9280, station mode TODO: * Thorough AP and other mode testing for non-EDMA chips; * Figure out how to allocate RX buffers suitable for RX EDMA, including correctly setting the mbuf length to compensate for the RX descriptor and completion status area.
2012-07-03 06:59:12 +00:00
ath_rx_flush(sc);
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
Shut down RX before TX - in theory, this should make the chip less likely to get upset. The Qualcomm Atheros reference design code goes through significant hacks to shut down RX before TX. It doesn't even try do do it in the driver - it actually makes the DMA stop routines in the HAL shut down RX before shutting down TX. So, to make this work for chips that aren't the AR9380 and later, do it in the driver. Shuffle the TX stop/drain HAL calls to be called *after* the RX stop HAL call. Tested: * AR5413 (STA) * AR5212 (STA) * AR5416 (STA) * AR9380 (STA) * AR9331 (AP) * AR9341 (AP) TODO: * test ar92xx series NIC and the AR5210/AR5211, in case there's something even odder about those.
2014-08-23 18:55:51 +00:00
/*
* Should now wait for pending TX/RX to complete
dev/ath: minor spelling fixes in comments. No functional change. Reviewed by: adrian
2016-05-02 19:56:48 +00:00
* and block future ones from occurring. This needs to be
Shut down RX before TX - in theory, this should make the chip less likely to get upset. The Qualcomm Atheros reference design code goes through significant hacks to shut down RX before TX. It doesn't even try do do it in the driver - it actually makes the DMA stop routines in the HAL shut down RX before shutting down TX. So, to make this work for chips that aren't the AR9380 and later, do it in the driver. Shuffle the TX stop/drain HAL calls to be called *after* the RX stop HAL call. Tested: * AR5413 (STA) * AR5212 (STA) * AR5416 (STA) * AR9380 (STA) * AR9331 (AP) * AR9341 (AP) TODO: * test ar92xx series NIC and the AR5210/AR5211, in case there's something even odder about those.
2014-08-23 18:55:51 +00:00
* done before the TX queue is drained.
*/
ath_draintxq(sc, reset_type); /* stop xmit side */
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
ath_settkipmic(sc); /* configure TKIP MIC handling */
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
/* NB: indicate channel change so we do a full reset */
Part #2 of the TX chainmask changes: * Remove ar5416UpdateChainmasks(); * Remove the TX chainmask override code from the ar5416 TX descriptor setup routines; * Write a driver method to calculate the current chainmask based on the operating mode and update the driver state; * Call the HAL chainmask method before calling ath_hal_reset(); * Use the currently configured chainmask in the TX descriptors rather than the hardware TX chainmasks. Tested: * AR5416, STA/AP mode - legacy and 11n modes
2013-02-25 22:45:02 +00:00
ath_update_chainmasks(sc, ic->ic_curchan);
ath_hal_setchainmasks(sc->sc_ah, sc->sc_cur_txchainmask,
sc->sc_cur_rxchainmask);
ath(4): begin fleshing out a "reset type" extension to force cold/warn resets. Right now the only way to force a cold reset is: * The HAL itself detects it's needed, or * The sysctl, setting all resets to be cold. Trouble is, cold resets take quite a bit longer than warm resets. However, there are situations where a cold reset would be nice. Specifically, after a stuck beacon, BB/MAC hang, stuck calibration results, etc. The vendor HAL has a separate method to set the reset reason (which is how HAL_RESET_BBPANIC gets set) which informs the HAL during the reset path why it occured. This is almost but not quite the same; I may eventually unify both approaches in the future. This commit just extends HAL_RESET_TYPE to include both status (eg BBPANIC) and type (eg do COLD.) None of the HAL code uses it yet though; that'll come later. It also is a big no-op in each HAL - I need to go teach each of the HALs about cold/warm reset through this path.
2015-11-09 15:59:42 +00:00
if (!ath_hal_reset(ah, sc->sc_opmode, ic->ic_curchan, AH_TRUE,
HAL_RESET_NORMAL, &status))
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
device_printf(sc->sc_dev,
"%s: unable to reset hardware; hal status %u\n",
__func__, status);
o fix setup of sc_diversity; the hal does not give us reliable status after attach, only after a reset o when setting diversity via the sysctl don't update sc_diversity until we know the hal requested worked o while here eliminate sc_hasdiversity and sc_hastpc; just query the hal each time since these are the only places we need to know MFC after: 3 days
2005-07-24 05:11:39 +00:00
sc->sc_diversity = ath_hal_getdiversity(ah);
Flesh out the radar detection related operations for the ath driver. This is in no way a complete DFS/radar detection implementation! It merely creates an abstracted interface which allows for future development of the DFS radar detection code. Note: Net80211 already handles the bulk of the DFS machinery, all we need to do here is figure out that a radar event has occured and inform it as such. It then drives the DFS state engine for us. The "null" DFS radar detection module is included by default; it doesn't require a device line. This commit: * Adds a simple abstracted layer for radar detection state - sys/dev/ath/ath_dfs/; * Implements a null DFS module which doesn't do anything; (ie, implements the exact behaviour at the moment); * Adds hooks to the ath driver to process received radar events and gives the DFS module a chance to determine whether a radar has been detected. Obtained from: Atheros
2011-06-01 20:09:49 +00:00
Fix up the EDMA RX setup path to correctly initialise and reset the RX FIFO. The original code was .. well, slightly more than incorrect. It showed up as stalled RX queues if the NIC needed to be frequently reinitialised (eg during scans.) This is inspired by work done by Matt Dillon over at the DragonflyBSD project. So: * track when EDMA RX has been stopped and when the MAC has been reset; * re-initialise the ring only after a reset; * track whether RX has been stopped/started - just for debugging now; * don't bother with the RX EOL stuff for EDMA - we don't need the interrupt at all. We also don't need to disable/enable the interrupt or start DMA - once new frames are pushed into the ring via the normal RX path, it'll just restart RX DMA on its own. Tested: * AR9380, STA mode * AR9380, AP mode * AR9485, STA mode * AR9462, STA mode
2014-09-20 01:22:17 +00:00
ATH_RX_LOCK(sc);
sc->sc_rx_stopped = 1;
sc->sc_rx_resetted = 1;
ATH_RX_UNLOCK(sc);
[ath] initial station side quiet IE support. This implements hardware assisted quiet IE support. Quiet time is an optional interval on DFS channels (but doesn't have to be DFS only channels! sigh) where the station and AP can be quiet in order to allow for channel utilisation measurements. Typically that's stuff like radar detection, spectral scan, other-BSS frame sniffing, checking how busy the air is, etc. The hardware implements it as one of the generic timers, which is supplied a period, offset from the trigger period and duration to stay quiet. The AP can announce quiet time configurations which change, and so this code also tracks that. Implementation details: * track the current quiet time IE * compare the new one against the previous one - if only the TBTT counter changes, don't update things * If tbttcount=1 then program it into the hardware - that is when it is easiest to program the correct starting offset (one TBTT + configured offset). * .. later on check to see if it can be done on any tbttcount * If the IE goes away then remove the quiet timer and clear the config * Upon reset, state change, new beacon - clear quiet time IE and just let it resync from the next beacon. History: This was work done initially by sibridgetech.com in 2011/2012/2013 as part of some FreeBSD wifi DFS contracting work they had for a third party. They implemented the net80211 quiet time IE pieces and had some test code for the station side which didn't entirely use the timers correctly. I figured out how to use the timers correctly without stopping/starting the transmit DMA engine each time. When done correctly, the timer just needs to be programmed once and left alone until the next configuration change. So, thanks to Himali Patel and Parthiv Shah for their work way back then. I finally figured it out and finished it! TODO: * Now, I'd rather net80211 did the quiet time IE tracking and parsing, pushing configurations into the driver is needed. I'll look at doing that in a subsequent update. * This doesn't handle multiple quiet time IEs, which will currently just mess things up. I'll look into supporting that in the future (at least by only obeying "one" of them, and then ignoring subsequent IEs in a beacon/probe frame.) * This also implements the STA side and not the AP side - the AP side will come later, and involves taking various other intervals into account (eg the beacon offset for multi-VAP modes, the SWBA time, etc, etc) as well as obtaining the configuration when a beacon is configured/generated rather than "hearing" an IE. * .. investigate supporting quiet IE in mesh, tdma, ibss modes * .. investigate supporting quiet IE for non-DFS channels (so this can be done for say, 2GHz channels.) * Chances are i should commit NULL methods for the ar5210, ar5211 HALs.. Tested: * AR9380, STA mode - announcing quiet, removing quiet, changing quite time config, whilst doing iperf testing; * AR9380, AP mode.
2017-02-09 23:15:11 +00:00
/* Quiet time handling - ensure we resync */
ath_vap_clear_quiet_ie(sc);
Flesh out the radar detection related operations for the ath driver. This is in no way a complete DFS/radar detection implementation! It merely creates an abstracted interface which allows for future development of the DFS radar detection code. Note: Net80211 already handles the bulk of the DFS machinery, all we need to do here is figure out that a radar event has occured and inform it as such. It then drives the DFS state engine for us. The "null" DFS radar detection module is included by default; it doesn't require a device line. This commit: * Adds a simple abstracted layer for radar detection state - sys/dev/ath/ath_dfs/; * Implements a null DFS module which doesn't do anything; (ie, implements the exact behaviour at the moment); * Adds hooks to the ath driver to process received radar events and gives the DFS module a chance to determine whether a radar has been detected. Obtained from: Atheros
2011-06-01 20:09:49 +00:00
/* Let DFS at it in case it's a DFS channel */
ath_dfs_radar_enable(sc, ic->ic_curchan);
Add a new (skeleton) spectral mode manager module.
2013-01-02 03:59:02 +00:00
/* Let spectral at in case spectral is enabled */
ath_spectral_enable(sc, ic->ic_curchan);
Bring over the initial static bluetooth coexistence configuration for the WB195 combo NIC - an AR9285 w/ an AR3011 USB bluetooth NIC. The AR3011 is wired up using a 3-wire coexistence scheme to the AR9285. The code in if_ath_btcoex.c sets up the initial hardware mapping and coexistence configuration. There's nothing special about it - it's static; it doesn't try to configure bluetooth / MAC traffic priorities or try to figure out what's actually going on. It's enough to stop basic bluetooth traffic from causing traffic stalls and diassociation from the wireless network. To use this code, you must have the above NIC. No, it won't work for the AR9287+AR3012, nor the AR9485, AR9462 or AR955x combo cards. Then you set a kernel hint before boot or before kldload, where 'X' is the unit number of your AR9285 NIC: # kenv hint.ath.X.btcoex_profile=wb195 This will then appear in your boot messages: [100482] athX: Enabling WB195 BTCOEX This code is going to evolve pretty quickly (well, depending upon my spare time) so don't assume the btcoex API is going to stay stable. In order to use the bluetooth side, you must also load in firmware using ath3kfw and the binary firmware file (ath3k-1.fw in my case.) Tested: * AR9280, no interference * WB195 - AR9285 + AR3011 combo; STA mode; basic bluetooth inquiries were enough to cause traffic stalls and disassociations. This has stopped with the btcoex profile code. TODO: * Importantly - the AR9285 needs ASPM disabled if bluetooth coexistence is enabled. No, I don't know why. It's likely some kind of bug to do with the AR3011 sending bluetooth coexistence signals whilst the device is asleep. Since we don't actually sleep the MAC just yet, it shouldn't be a problem. That said, to be totally correct: + ASPM should be disabled - upon attach and wakeup + The PCIe powersave HAL code should never be called Look at what the ath9k driver does for inspiration. * Add WB197 (AR9287+AR3012) support * Add support for the AR9485, which is another combo like the AR9285 * The later NICs have a different signaling mechanism between the MAC and the bluetooth device; I haven't even begun to experiment with making that HAL code work. But it should be a lot more automatic. * The hardware can do much more interesting traffic weighting with bluetooth and wifi traffic. None of this is currently used. Ideally someone would code up something to watch the bluetooth traffic GPIO (via an interrupt) and then watch it go high/low; then figure out what the bluetooth traffic is and adjust things appropriately. * If I get the time I may add in some code to at least track this stuff and expose statistics. But it's up to someone else to experiment with the bluetooth coexistence support and add the interesting stuff (like "real" detection of bulk, audio, etc bluetooth traffic patterns and change wifi parameters appropriately - eg, maximum aggregate length, transmit power, using quiet time to control TX duty cycle, etc.)
2013-06-07 09:02:02 +00:00
/*
* Let bluetooth coexistence at in case it's needed for this channel
*/
ath_btcoex_enable(sc, ic->ic_curchan);
Enable the use of TDMA on an 802.11n channel (with aggregation disabled, of course.) There's a few things that needed to happen: * In case someone decides to set the beacon transmission rate to be at an MCS rate, use the MCS-aware version of the duration calculation to figure out how long the received beacon frame was. * If TxOP enforcing is available on the hardware and we're doing TDMA, enable it after a reset and set the TDMA guard interval to zero. This seems to behave fine. TODO: * Although I haven't yet seen packet loss, the PHY errors that would be triggered (specifically Transmit-Override-Receive) aren't enabled by the 11n HAL. I'll have to do some work to enable these PHY errors for debugging. What broke: * My recent changes to the TX queue handling has resulted in the driver not keeping the hardware queue properly filled when doing non-aggregate traffic. I have a patch to commit soon which fixes this situation (albeit by reminding me about how my ath driver locking isn't working out, sigh.) So if you want to test this without updating to the next set of patches that I commit, just bump the sysctl dev.ath.X.hwq_limit from 2 to 32. Tested: * AR5416 <-> AR5416, with ampdu disabled, HT40, 5GHz, MCS12+Short-GI. I saw 30mbit/sec in both directions using a bidirectional UDP test.
2013-05-21 18:02:54 +00:00
/*
* If we're doing TDMA, enforce the TXOP limitation for chips that
* support it.
*/
if (sc->sc_hasenforcetxop && sc->sc_tdma)
ath_hal_setenforcetxop(sc->sc_ah, 1);
else
ath_hal_setenforcetxop(sc->sc_ah, 0);
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
if (ath_startrecv(sc) != 0) /* restart recv */
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
device_printf(sc->sc_dev,
"%s: unable to start recv logic\n", __func__);
Update with last year of work.
2004-12-08 17:34:36 +00:00
/*
* We may be doing a reset in response to an ioctl
* that changes the channel so update any state that
* might change as a result.
*/
Add initial support for 900MHz cards like the Ubiquiti SR9: o eliminate assumptions that half/quarter rate channels on exist in 11a o handle frequency mapping between hal and net80211; hal gives us freq's in the range 2422..2437 that we remap MFC after: 1 month
2007-01-15 01:15:57 +00:00
ath_chan_change(sc, ic->ic_curchan);
restart tdma beacons after vap destroy
2009-06-02 21:11:26 +00:00
if (sc->sc_beacons) { /* restart beacons */
Remove ATH_SUPPORT_TDMA and use IEEE80211_SUPPORT_TDMA instead. It doesn't make much sense to configure driver support w/o net80211. Note this means ath now depends on opt_wlan.h.
2009-03-30 19:23:49 +00:00
#ifdef IEEE80211_SUPPORT_TDMA
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
if (sc->sc_tdma)
ath_tdma_config(sc, NULL);
else
#endif
restart tdma beacons after vap destroy
2009-06-02 21:11:26 +00:00
ath_beacon_config(sc, NULL);
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
}
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
/*
* Release the reset lock and re-enable interrupts here.
* If an interrupt was being processed in ath_intr(),
* it would disable interrupts at this point. So we have
* to atomically enable interrupts and decrement the
* reset counter - this way ath_intr() doesn't end up
* disabling interrupts without a corresponding enable
* in the rest or channel change path.
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
*
* Grab the TX reference in case we need to transmit.
* That way a parallel transmit doesn't.
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
*/
ATH_PCU_LOCK(sc);
sc->sc_inreset_cnt--;
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
sc->sc_txstart_cnt++;
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
/* XXX only do this if sc_inreset_cnt == 0? */
Update with last year of work.
2004-12-08 17:34:36 +00:00
ath_hal_intrset(ah, sc->sc_imask);
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
ATH_PCU_UNLOCK(sc);
Update with last year of work.
2004-12-08 17:34:36 +00:00
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
/*
* TX and RX can be started here. If it were started with
* sc_inreset_cnt > 0, the TX and RX path would abort.
* Thus if this is a nested call through the reset or
* channel change code, TX completion will occur but
* RX completion and ath_start / ath_tx_start will not
* run.
*/
/* Restart TX/RX as needed */
ath_txrx_start(sc);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
/* XXX TODO: we need to hold the tx refcount here! */
Delete the per-TXQ locks and replace them with a single TX lock. I couldn't think of a way to maintain the hardware TXQ locks _and_ layer on top of that per-TXQ software queuing and any other kind of fine-grained locks (eg per-TID, or per-node locks.) So for now, to facilitate some further code refactoring and development as part of the final push to get software queue ps-poll and u-apsd handling into this driver, just do away with them entirely. I may eventually bring them back at some point, when it looks slightly more architectually cleaner to do so. But as it stands at the present, it's not really buying us much: * in order to properly serialise things and not get bitten by scheduling and locking interactions with things higher up in the stack, we need to wrap the whole TX path in a long held lock. Otherwise we can end up being pre-empted during frame handling, resulting in some out of order frame handling between sequence number allocation and encryption handling (ie, the seqno and the CCMP IV get out of sequence); * .. so whilst that's the case, holding the lock for that long means that we're acquiring and releasing the TXQ lock _inside_ that context; * And we also acquire it per-frame during frame completion, but we currently can't hold the lock for the duration of the TX completion as we need to call net80211 layer things with the locks _unheld_ to avoid LOR. * .. the other places were grab that lock are reset/flush, which don't happen often. My eventual aim is to change the TX path so all rejected frame transmissions and all frame completions result in any ieee80211_free_node() calls to occur outside of the TX lock; then I can cut back on the amount of locking that goes on here. There may be some LORs that occur when ieee80211_free_node() is called when the TX queue path fails; I'll begin to address these in follow-up commits.
2012-12-02 06:24:08 +00:00
/* Restart TX completion and pending TX */
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
if (reset_type == ATH_RESET_NOLOSS) {
for (i = 0; i < HAL_NUM_TX_QUEUES; i++) {
if (ATH_TXQ_SETUP(sc, i)) {
Overhaul the TXQ locking (again!) as part of some beacon/cabq timing related issues. Moving the TX locking under one lock made things easier to progress on but it had one important side-effect - it increased the latency when handling CABQ setup when sending beacons. This commit introduces a bunch of new changes and a few unrelated changs that are just easier to lump in here. The aim is to have the CABQ locking separate from other locking. The CABQ transmit path in the beacon process thus doesn't have to grab the general TX lock, reducing lock contention/latency and making it more likely that we'll make the beacon TX timing. The second half of this commit is the CABQ related setup changes needed for sane looking EDMA CABQ support. Right now the EDMA TX code naively assumes that only one frame (MPDU or A-MPDU) is being pushed into each FIFO slot. For the CABQ this isn't true - a whole list of frames is being pushed in - and thus CABQ handling breaks very quickly. The aim here is to setup the CABQ list and then push _that list_ to the hardware for transmission. I can then extend the EDMA TX code to stamp that list as being "one" FIFO entry (likely by tagging the last buffer in that list as "FIFO END") so the EDMA TX completion code correctly tracks things. Major: * Migrate the per-TXQ add/removal locking back to per-TXQ, rather than a single lock. * Leave the software queue side of things under the ATH_TX_LOCK lock, (continuing) to serialise things as they are. * Add a new function which is called whenever there's a beacon miss, to print out some debugging. This is primarily designed to help me figure out if the beacon miss events are due to a noisy environment, issues with the PHY/MAC, or other. * Move the CABQ setup/enable to occur _after_ all the VAPs have been looked at. This means that for multiple VAPS in bursted mode, the CABQ gets primed once all VAPs are checked, rather than being primed on the first VAP and then having frames appended after this. Minor: * Add a (disabled) twiddle to let me enable/disable cabq traffic. It's primarily there to let me easily debug what's going on with beacon and CABQ setup/traffic; there's some DMA engine hangs which I'm finally trying to trace down. * Clear bf_next when flushing frames; it should quieten some warnings that show up when a node goes away. Tested: * AR9280, STA/hostap, up to 4 vaps (staggered) * AR5416, STA/hostap, up to 4 vaps (staggered) TODO: * (Lots) more AR9380 and later testing, as I may have missed something here. * Leverage this to fix CABQ hanling for AR9380 and later chips. * Force bursted beaconing on the chips that default to staggered beacons and ensure the CABQ stuff is all sane (eg, the MORE bits that aren't being correctly set when chaining descriptors.)
2013-03-24 00:03:12 +00:00
ATH_TXQ_LOCK(&sc->sc_txq[i]);
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
ath_txq_restart_dma(sc, &sc->sc_txq[i]);
Overhaul the TXQ locking (again!) as part of some beacon/cabq timing related issues. Moving the TX locking under one lock made things easier to progress on but it had one important side-effect - it increased the latency when handling CABQ setup when sending beacons. This commit introduces a bunch of new changes and a few unrelated changs that are just easier to lump in here. The aim is to have the CABQ locking separate from other locking. The CABQ transmit path in the beacon process thus doesn't have to grab the general TX lock, reducing lock contention/latency and making it more likely that we'll make the beacon TX timing. The second half of this commit is the CABQ related setup changes needed for sane looking EDMA CABQ support. Right now the EDMA TX code naively assumes that only one frame (MPDU or A-MPDU) is being pushed into each FIFO slot. For the CABQ this isn't true - a whole list of frames is being pushed in - and thus CABQ handling breaks very quickly. The aim here is to setup the CABQ list and then push _that list_ to the hardware for transmission. I can then extend the EDMA TX code to stamp that list as being "one" FIFO entry (likely by tagging the last buffer in that list as "FIFO END") so the EDMA TX completion code correctly tracks things. Major: * Migrate the per-TXQ add/removal locking back to per-TXQ, rather than a single lock. * Leave the software queue side of things under the ATH_TX_LOCK lock, (continuing) to serialise things as they are. * Add a new function which is called whenever there's a beacon miss, to print out some debugging. This is primarily designed to help me figure out if the beacon miss events are due to a noisy environment, issues with the PHY/MAC, or other. * Move the CABQ setup/enable to occur _after_ all the VAPs have been looked at. This means that for multiple VAPS in bursted mode, the CABQ gets primed once all VAPs are checked, rather than being primed on the first VAP and then having frames appended after this. Minor: * Add a (disabled) twiddle to let me enable/disable cabq traffic. It's primarily there to let me easily debug what's going on with beacon and CABQ setup/traffic; there's some DMA engine hangs which I'm finally trying to trace down. * Clear bf_next when flushing frames; it should quieten some warnings that show up when a node goes away. Tested: * AR9280, STA/hostap, up to 4 vaps (staggered) * AR5416, STA/hostap, up to 4 vaps (staggered) TODO: * (Lots) more AR9380 and later testing, as I may have missed something here. * Leverage this to fix CABQ hanling for AR9380 and later chips. * Force bursted beaconing on the chips that default to staggered beacons and ensure the CABQ stuff is all sane (eg, the MORE bits that aren't being correctly set when chaining descriptors.)
2013-03-24 00:03:12 +00:00
ATH_TXQ_UNLOCK(&sc->sc_txq[i]);
ATH_TX_LOCK(sc);
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
ath_txq_sched(sc, &sc->sc_txq[i]);
Overhaul the TXQ locking (again!) as part of some beacon/cabq timing related issues. Moving the TX locking under one lock made things easier to progress on but it had one important side-effect - it increased the latency when handling CABQ setup when sending beacons. This commit introduces a bunch of new changes and a few unrelated changs that are just easier to lump in here. The aim is to have the CABQ locking separate from other locking. The CABQ transmit path in the beacon process thus doesn't have to grab the general TX lock, reducing lock contention/latency and making it more likely that we'll make the beacon TX timing. The second half of this commit is the CABQ related setup changes needed for sane looking EDMA CABQ support. Right now the EDMA TX code naively assumes that only one frame (MPDU or A-MPDU) is being pushed into each FIFO slot. For the CABQ this isn't true - a whole list of frames is being pushed in - and thus CABQ handling breaks very quickly. The aim here is to setup the CABQ list and then push _that list_ to the hardware for transmission. I can then extend the EDMA TX code to stamp that list as being "one" FIFO entry (likely by tagging the last buffer in that list as "FIFO END") so the EDMA TX completion code correctly tracks things. Major: * Migrate the per-TXQ add/removal locking back to per-TXQ, rather than a single lock. * Leave the software queue side of things under the ATH_TX_LOCK lock, (continuing) to serialise things as they are. * Add a new function which is called whenever there's a beacon miss, to print out some debugging. This is primarily designed to help me figure out if the beacon miss events are due to a noisy environment, issues with the PHY/MAC, or other. * Move the CABQ setup/enable to occur _after_ all the VAPs have been looked at. This means that for multiple VAPS in bursted mode, the CABQ gets primed once all VAPs are checked, rather than being primed on the first VAP and then having frames appended after this. Minor: * Add a (disabled) twiddle to let me enable/disable cabq traffic. It's primarily there to let me easily debug what's going on with beacon and CABQ setup/traffic; there's some DMA engine hangs which I'm finally trying to trace down. * Clear bf_next when flushing frames; it should quieten some warnings that show up when a node goes away. Tested: * AR9280, STA/hostap, up to 4 vaps (staggered) * AR5416, STA/hostap, up to 4 vaps (staggered) TODO: * (Lots) more AR9380 and later testing, as I may have missed something here. * Leverage this to fix CABQ hanling for AR9380 and later chips. * Force bursted beaconing on the chips that default to staggered beacons and ensure the CABQ stuff is all sane (eg, the MORE bits that aren't being correctly set when chaining descriptors.)
2013-03-24 00:03:12 +00:00
ATH_TX_UNLOCK(sc);
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
}
}
}
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ATH_LOCK(sc);
ath_power_restore_power_state(sc);
ATH_UNLOCK(sc);
ATH_PCU_LOCK(sc);
sc->sc_txstart_cnt--;
ATH_PCU_UNLOCK(sc);
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
/* Handle any frames in the TX queue */
/*
* XXX should this be done by the caller, rather than
* ath_reset() ?
*/
Push the actual TX processing into the ath taskqueue, rather than having it run out of multiple concurrent contexts. Right now the ath(4) TX processing is a bit hairy. Specifically: * It was running out of ath_start(), which could occur from multiple concurrent sending processes (as if_start() can be started from multiple sending threads nowdays.. sigh) * during RX if fast frames are enabled (so not really at the moment, not until I fix this particular feature again..) * during ath_reset() - so anything which calls that * during ath_tx_proc*() in the ath taskqueue - ie, TX is attempted again after TX completion, as there's now hopefully some ath_bufs available. * Then, the ic_raw_xmit() method can queue raw frames for transmission at any time, from any net80211 TX context. Ew. This has caused packet ordering issues in the past - specifically, there's absolutely no guarantee that preemption won't occuring _during_ ath_start() by the TX completion processing, which will call ath_start() again. It's a mess - 802.11 really, really wants things to be in sequence or things go all kinds of loopy. So: * create a new task struct for TX'ing; * make the if_start method simply queue the task on the ath taskqueue; * make ath_start() just be called by the new TX task; * make ath_tx_kick() just schedule the ath TX task, rather than directly calling ath_start(). Now yes, this means that I've taken a step backwards in terms of concurrency - TX -and- RX now occur in the same single-task taskqueue. But there's nothing stopping me from separating out the TX / TX completion code into a separate taskqueue which runs in parallel with the RX path, if that ends up being appropriate for some platforms. This fixes the CCMP/seqno concurrency issues that creep up when you transmit large amounts of uni-directional UDP traffic (>200MBit) on a FreeBSD STA -> AP, as now there's only one TX context no matter what's going on (TX completion->retry/software queue, userland->net80211->ath_start(), TX completion -> ath_start()); but it won't fix any concurrency issues between raw transmitted frames and non-raw transmitted frames (eg EAPOL frames on TID 16 and any other TID 16 multicast traffic that gets put on the CABQ.) That is going to require a bunch more re-architecture before it's feasible to fix. In any case, this is a big step towards making the majority of the TX path locking irrelevant, as now almost all TX activity occurs in the taskqueue. Phew.
2012-10-14 20:44:08 +00:00
ath_tx_kick(sc); /* restart xmit */
Update with last year of work.
2004-12-08 17:34:36 +00:00
return 0;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
static int
ath_reset_vap(struct ieee80211vap *vap, u_long cmd)
{
intercept IEEE80211_IOC_TXPOWER and service tx power changes immediately
2008-10-27 17:12:41 +00:00
struct ieee80211com *ic = vap->iv_ic;
Remove most of the references of ifp->if_softc and replace with references to ic->ic_softc. This is in preparation for gleb's ifnet work. Tested: * ath(4), STA mode * ath(4), hostap mode * make universe
2015-08-17 02:04:11 +00:00
struct ath_softc *sc = ic->ic_softc;
intercept IEEE80211_IOC_TXPOWER and service tx power changes immediately
2008-10-27 17:12:41 +00:00
struct ath_hal *ah = sc->sc_ah;
switch (cmd) {
case IEEE80211_IOC_TXPOWER:
/*
* If per-packet TPC is enabled, then we have nothing
* to do; otherwise we need to force the global limit.
* All this can happen directly; no need to reset.
*/
if (!ath_hal_gettpc(ah))
ath_hal_settxpowlimit(ah, ic->ic_txpowlimit);
return 0;
}
In preparation for supporting 11n TX/RX properly, allow for TX queue draining and interface resets to be marked as ATH_RESET_DEFAULT, ATH_RESET_FULL, ATH_RESET_NOLOSS. Currently a reset is still a reset - ie, all tx/rx frames in the hardware queues are purged. This means that those frames will be lost to the 11n TX and RX aggregation state tracking, breaking AMPDU sessions. The (eventual) new semantics: * ATH_RESET_DEFAULT: full reset, this is the default for reset situations which I haven't yet figured out what they should be. * ATH_RESET_FULL: A full reset - for things such as channel changes. * ATH_RESET_NOLOSS: Don't flush TX/RX queues - handle pending RX frames and leave TX frames where they are; restart TX DMA from where it was.
2011-11-08 18:56:52 +00:00
/* XXX? Full or NOLOSS? */
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
return ath_reset(sc, ATH_RESET_FULL);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
}
Migrate the TX path code out of if_ath and into a separate source file. There's two reasons for this: * the raw and non-raw TX path shares a lot of duplicate code which should be refactored; * the 11n-ready chip TX path needs a little reworking.
2011-01-29 11:35:23 +00:00
struct ath_buf *
Implement a separate, smaller pool of ath_buf entries for use by management traffic. * Create sc_mgmt_txbuf and sc_mgmt_txdesc, initialise/free them appropriately. * Create an enum to represent buffer types in the API. * Extend ath_getbuf() and _ath_getbuf_locked() to take the above enum. * Right now anything sent via ic_raw_xmit() allocates via ATH_BUFTYPE_MGMT. This may not be very useful. * Add ATH_BUF_MGMT flag (ath_buf.bf_flags) which indicates the current buffer is a mgmt buffer and should go back onto the mgmt free list. * Extend 'txagg' to include debugging output for both normal and mgmt txbufs. * When checking/clearing ATH_BUF_BUSY, do it on both TX pools. Tested: * STA mode, with heavy UDP injection via iperf. This filled the TX queue however BARs were still going out successfully. TODO: * Initialise the mgmt buffers with ATH_BUF_MGMT and then ensure the right type is being allocated and freed on the appropriate list. That'd save a write operation (to bf->bf_flags) on each buffer alloc/free. * Test on AP mode, ensure that BAR TX and probe responses go out nicely when the main TX queue is filled (eg with paused traffic to a TID, awaiting a BAR to complete.) PR: kern/168170
2012-06-13 06:57:55 +00:00
_ath_getbuf_locked(struct ath_softc *sc, ath_buf_type_t btype)
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
{
struct ath_buf *bf;
ATH_TXBUF_LOCK_ASSERT(sc);
Implement a separate, smaller pool of ath_buf entries for use by management traffic. * Create sc_mgmt_txbuf and sc_mgmt_txdesc, initialise/free them appropriately. * Create an enum to represent buffer types in the API. * Extend ath_getbuf() and _ath_getbuf_locked() to take the above enum. * Right now anything sent via ic_raw_xmit() allocates via ATH_BUFTYPE_MGMT. This may not be very useful. * Add ATH_BUF_MGMT flag (ath_buf.bf_flags) which indicates the current buffer is a mgmt buffer and should go back onto the mgmt free list. * Extend 'txagg' to include debugging output for both normal and mgmt txbufs. * When checking/clearing ATH_BUF_BUSY, do it on both TX pools. Tested: * STA mode, with heavy UDP injection via iperf. This filled the TX queue however BARs were still going out successfully. TODO: * Initialise the mgmt buffers with ATH_BUF_MGMT and then ensure the right type is being allocated and freed on the appropriate list. That'd save a write operation (to bf->bf_flags) on each buffer alloc/free. * Test on AP mode, ensure that BAR TX and probe responses go out nicely when the main TX queue is filled (eg with paused traffic to a TID, awaiting a BAR to complete.) PR: kern/168170
2012-06-13 06:57:55 +00:00
if (btype == ATH_BUFTYPE_MGMT)
bf = TAILQ_FIRST(&sc->sc_txbuf_mgmt);
else
bf = TAILQ_FIRST(&sc->sc_txbuf);
Change ath_buf allocation to: * Immediately return NULL if a buffer isn't available; * Track the "buffers not available" count; * Clear some fields used for tx aggregation; * Add ath_buf_clone() which clones the majority of buffer state. This is needed when retransmission of a "busy" buffer is required. Sponsored by: Hobnob, Inc.
2011-11-08 21:13:05 +00:00
if (bf == NULL) {
sc->sc_stats.ast_tx_getnobuf++;
} else {
if (bf->bf_flags & ATH_BUF_BUSY) {
sc->sc_stats.ast_tx_getbusybuf++;
bf = NULL;
}
}
Implement a separate, smaller pool of ath_buf entries for use by management traffic. * Create sc_mgmt_txbuf and sc_mgmt_txdesc, initialise/free them appropriately. * Create an enum to represent buffer types in the API. * Extend ath_getbuf() and _ath_getbuf_locked() to take the above enum. * Right now anything sent via ic_raw_xmit() allocates via ATH_BUFTYPE_MGMT. This may not be very useful. * Add ATH_BUF_MGMT flag (ath_buf.bf_flags) which indicates the current buffer is a mgmt buffer and should go back onto the mgmt free list. * Extend 'txagg' to include debugging output for both normal and mgmt txbufs. * When checking/clearing ATH_BUF_BUSY, do it on both TX pools. Tested: * STA mode, with heavy UDP injection via iperf. This filled the TX queue however BARs were still going out successfully. TODO: * Initialise the mgmt buffers with ATH_BUF_MGMT and then ensure the right type is being allocated and freed on the appropriate list. That'd save a write operation (to bf->bf_flags) on each buffer alloc/free. * Test on AP mode, ensure that BAR TX and probe responses go out nicely when the main TX queue is filled (eg with paused traffic to a TID, awaiting a BAR to complete.) PR: kern/168170
2012-06-13 06:57:55 +00:00
if (bf != NULL && (bf->bf_flags & ATH_BUF_BUSY) == 0) {
if (btype == ATH_BUFTYPE_MGMT)
TAILQ_REMOVE(&sc->sc_txbuf_mgmt, bf, bf_list);
Implement a global (all non-mgmt traffic) TX ath_buf limitation when ath_start() is called. This (defaults to 10 frames) gives for a little headway in the TX ath_buf allocation, so buffer cloning is still possible. This requires a lot omre experimenting and tuning. It also doesn't stop a node/TID from consuming all of the available ath_buf's, especially when the node is going through high packet loss or only talking at a low TX rate. It also doesn't stop a paused TID from taking all of the ath_bufs. I'll look at fixing that up in subsequent commits. PR: kern/168170
2012-06-14 00:51:53 +00:00
else {
Implement a separate, smaller pool of ath_buf entries for use by management traffic. * Create sc_mgmt_txbuf and sc_mgmt_txdesc, initialise/free them appropriately. * Create an enum to represent buffer types in the API. * Extend ath_getbuf() and _ath_getbuf_locked() to take the above enum. * Right now anything sent via ic_raw_xmit() allocates via ATH_BUFTYPE_MGMT. This may not be very useful. * Add ATH_BUF_MGMT flag (ath_buf.bf_flags) which indicates the current buffer is a mgmt buffer and should go back onto the mgmt free list. * Extend 'txagg' to include debugging output for both normal and mgmt txbufs. * When checking/clearing ATH_BUF_BUSY, do it on both TX pools. Tested: * STA mode, with heavy UDP injection via iperf. This filled the TX queue however BARs were still going out successfully. TODO: * Initialise the mgmt buffers with ATH_BUF_MGMT and then ensure the right type is being allocated and freed on the appropriate list. That'd save a write operation (to bf->bf_flags) on each buffer alloc/free. * Test on AP mode, ensure that BAR TX and probe responses go out nicely when the main TX queue is filled (eg with paused traffic to a TID, awaiting a BAR to complete.) PR: kern/168170
2012-06-13 06:57:55 +00:00
TAILQ_REMOVE(&sc->sc_txbuf, bf, bf_list);
Implement a global (all non-mgmt traffic) TX ath_buf limitation when ath_start() is called. This (defaults to 10 frames) gives for a little headway in the TX ath_buf allocation, so buffer cloning is still possible. This requires a lot omre experimenting and tuning. It also doesn't stop a node/TID from consuming all of the available ath_buf's, especially when the node is going through high packet loss or only talking at a low TX rate. It also doesn't stop a paused TID from taking all of the ath_bufs. I'll look at fixing that up in subsequent commits. PR: kern/168170
2012-06-14 00:51:53 +00:00
sc->sc_txbuf_cnt--;
/*
* This shuldn't happen; however just to be
* safe print a warning and fudge the txbuf
* count.
*/
if (sc->sc_txbuf_cnt < 0) {
device_printf(sc->sc_dev,
"%s: sc_txbuf_cnt < 0?\n",
__func__);
sc->sc_txbuf_cnt = 0;
}
}
Implement a separate, smaller pool of ath_buf entries for use by management traffic. * Create sc_mgmt_txbuf and sc_mgmt_txdesc, initialise/free them appropriately. * Create an enum to represent buffer types in the API. * Extend ath_getbuf() and _ath_getbuf_locked() to take the above enum. * Right now anything sent via ic_raw_xmit() allocates via ATH_BUFTYPE_MGMT. This may not be very useful. * Add ATH_BUF_MGMT flag (ath_buf.bf_flags) which indicates the current buffer is a mgmt buffer and should go back onto the mgmt free list. * Extend 'txagg' to include debugging output for both normal and mgmt txbufs. * When checking/clearing ATH_BUF_BUSY, do it on both TX pools. Tested: * STA mode, with heavy UDP injection via iperf. This filled the TX queue however BARs were still going out successfully. TODO: * Initialise the mgmt buffers with ATH_BUF_MGMT and then ensure the right type is being allocated and freed on the appropriate list. That'd save a write operation (to bf->bf_flags) on each buffer alloc/free. * Test on AP mode, ensure that BAR TX and probe responses go out nicely when the main TX queue is filled (eg with paused traffic to a TID, awaiting a BAR to complete.) PR: kern/168170
2012-06-13 06:57:55 +00:00
} else
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
bf = NULL;
Change ath_buf allocation to: * Immediately return NULL if a buffer isn't available; * Track the "buffers not available" count; * Clear some fields used for tx aggregation; * Add ath_buf_clone() which clones the majority of buffer state. This is needed when retransmission of a "busy" buffer is required. Sponsored by: Hobnob, Inc.
2011-11-08 21:13:05 +00:00
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
if (bf == NULL) {
Implement a separate, smaller pool of ath_buf entries for use by management traffic. * Create sc_mgmt_txbuf and sc_mgmt_txdesc, initialise/free them appropriately. * Create an enum to represent buffer types in the API. * Extend ath_getbuf() and _ath_getbuf_locked() to take the above enum. * Right now anything sent via ic_raw_xmit() allocates via ATH_BUFTYPE_MGMT. This may not be very useful. * Add ATH_BUF_MGMT flag (ath_buf.bf_flags) which indicates the current buffer is a mgmt buffer and should go back onto the mgmt free list. * Extend 'txagg' to include debugging output for both normal and mgmt txbufs. * When checking/clearing ATH_BUF_BUSY, do it on both TX pools. Tested: * STA mode, with heavy UDP injection via iperf. This filled the TX queue however BARs were still going out successfully. TODO: * Initialise the mgmt buffers with ATH_BUF_MGMT and then ensure the right type is being allocated and freed on the appropriate list. That'd save a write operation (to bf->bf_flags) on each buffer alloc/free. * Test on AP mode, ensure that BAR TX and probe responses go out nicely when the main TX queue is filled (eg with paused traffic to a TID, awaiting a BAR to complete.) PR: kern/168170
2012-06-13 06:57:55 +00:00
/* XXX should check which list, mgmt or otherwise */
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
DPRINTF(sc, ATH_DEBUG_XMIT, "%s: %s\n", __func__,
Migrate the STAILQ lists to TAILQs. A bunch of the 11n TX aggregation logic wants to traverse lists of buffers in various ways. In order to provide O(1) behaviour in this instance, use TAILQs. This does blow out the memory footprint and CPU cycles slightly for some of these operations. I may convert some of these back to STAILQs once the rest of the software transmit queue handling has been stabilised. Sponsored by: Hobnob, Inc.
2011-11-08 17:08:12 +00:00
TAILQ_FIRST(&sc->sc_txbuf) == NULL ?
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
"out of xmit buffers" : "xmit buffer busy");
Change ath_buf allocation to: * Immediately return NULL if a buffer isn't available; * Track the "buffers not available" count; * Clear some fields used for tx aggregation; * Add ath_buf_clone() which clones the majority of buffer state. This is needed when retransmission of a "busy" buffer is required. Sponsored by: Hobnob, Inc.
2011-11-08 21:13:05 +00:00
return NULL;
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
}
Change ath_buf allocation to: * Immediately return NULL if a buffer isn't available; * Track the "buffers not available" count; * Clear some fields used for tx aggregation; * Add ath_buf_clone() which clones the majority of buffer state. This is needed when retransmission of a "busy" buffer is required. Sponsored by: Hobnob, Inc.
2011-11-08 21:13:05 +00:00
Implement a separate, smaller pool of ath_buf entries for use by management traffic. * Create sc_mgmt_txbuf and sc_mgmt_txdesc, initialise/free them appropriately. * Create an enum to represent buffer types in the API. * Extend ath_getbuf() and _ath_getbuf_locked() to take the above enum. * Right now anything sent via ic_raw_xmit() allocates via ATH_BUFTYPE_MGMT. This may not be very useful. * Add ATH_BUF_MGMT flag (ath_buf.bf_flags) which indicates the current buffer is a mgmt buffer and should go back onto the mgmt free list. * Extend 'txagg' to include debugging output for both normal and mgmt txbufs. * When checking/clearing ATH_BUF_BUSY, do it on both TX pools. Tested: * STA mode, with heavy UDP injection via iperf. This filled the TX queue however BARs were still going out successfully. TODO: * Initialise the mgmt buffers with ATH_BUF_MGMT and then ensure the right type is being allocated and freed on the appropriate list. That'd save a write operation (to bf->bf_flags) on each buffer alloc/free. * Test on AP mode, ensure that BAR TX and probe responses go out nicely when the main TX queue is filled (eg with paused traffic to a TID, awaiting a BAR to complete.) PR: kern/168170
2012-06-13 06:57:55 +00:00
/* XXX TODO: should do this at buffer list initialisation */
/* XXX (then, ensure the buffer has the right flag set) */
Add per-TXQ EDMA FIFO staging queue support. Each set of frames pushed into a FIFO is represented by a list of ath_bufs - the first ath_buf in the FIFO list is marked with ATH_BUF_FIFOPTR; the last ath_buf in the FIFO list is marked with ATH_BUF_FIFOEND. Multiple lists of frames are just glued together in the TAILQ as per normal - except that at the end of a FIFO list, the descriptor link pointer will be NULL and it'll be tagged with ATH_BUF_FIFOEND. For non-EDMA chipsets this is a no-op - the ath_txq frame list (axq_q) stays the same and is treated the same. For EDMA chipsets the frames are pushed into axq_q and then when the FIFO is to be (re) filled, frames will be moved onto the FIFO queue and then pushed into the FIFO. So: * Add a new queue in each hardware TXQ (ath_txq) for staging FIFO frame lists. It's a TAILQ (like the normal hardware frame queue) rather than the ath9k list-of-lists to represent FIFO entries. * Add new ath_buf flags - ATH_TX_FIFOPTR and ATH_TX_FIFOEND. * When allocating ath_buf entries, clear out the flag value before returning it or it'll end up having stale flags. * When cloning ath_buf entries, only clone ATH_BUF_MGMT. Don't clone the FIFO related flags. * Extend ath_tx_draintxq() to first drain the FIFO staging queue, _then_ drain the normal hardware queue. Tested: * AR9280, hostap * AR9280, STA * AR9380/AR9580 - hostap TODO: * Test on other chipsets, just to be thorough.
2013-03-26 19:46:51 +00:00
bf->bf_flags = 0;
Implement a separate, smaller pool of ath_buf entries for use by management traffic. * Create sc_mgmt_txbuf and sc_mgmt_txdesc, initialise/free them appropriately. * Create an enum to represent buffer types in the API. * Extend ath_getbuf() and _ath_getbuf_locked() to take the above enum. * Right now anything sent via ic_raw_xmit() allocates via ATH_BUFTYPE_MGMT. This may not be very useful. * Add ATH_BUF_MGMT flag (ath_buf.bf_flags) which indicates the current buffer is a mgmt buffer and should go back onto the mgmt free list. * Extend 'txagg' to include debugging output for both normal and mgmt txbufs. * When checking/clearing ATH_BUF_BUSY, do it on both TX pools. Tested: * STA mode, with heavy UDP injection via iperf. This filled the TX queue however BARs were still going out successfully. TODO: * Initialise the mgmt buffers with ATH_BUF_MGMT and then ensure the right type is being allocated and freed on the appropriate list. That'd save a write operation (to bf->bf_flags) on each buffer alloc/free. * Test on AP mode, ensure that BAR TX and probe responses go out nicely when the main TX queue is filled (eg with paused traffic to a TID, awaiting a BAR to complete.) PR: kern/168170
2012-06-13 06:57:55 +00:00
if (btype == ATH_BUFTYPE_MGMT)
bf->bf_flags |= ATH_BUF_MGMT;
else
bf->bf_flags &= (~ATH_BUF_MGMT);
Change ath_buf allocation to: * Immediately return NULL if a buffer isn't available; * Track the "buffers not available" count; * Clear some fields used for tx aggregation; * Add ath_buf_clone() which clones the majority of buffer state. This is needed when retransmission of a "busy" buffer is required. Sponsored by: Hobnob, Inc.
2011-11-08 21:13:05 +00:00
/* Valid bf here; clear some basic fields */
bf->bf_next = NULL; /* XXX just to be sure */
bf->bf_last = NULL; /* XXX again, just to be sure */
bf->bf_comp = NULL; /* XXX again, just to be sure */
bzero(&bf->bf_state, sizeof(bf->bf_state));
Implement a sequential descriptor ID value and stuff it in the ath_buf. This will be used by the EDMA TX code to assign descriptor IDs in order to provide some debugging.
2012-08-15 06:48:34 +00:00
/*
* Track the descriptor ID only if doing EDMA
*/
if (sc->sc_isedma) {
bf->bf_descid = sc->sc_txbuf_descid;
sc->sc_txbuf_descid++;
}
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
return bf;
}
Change ath_buf allocation to: * Immediately return NULL if a buffer isn't available; * Track the "buffers not available" count; * Clear some fields used for tx aggregation; * Add ath_buf_clone() which clones the majority of buffer state. This is needed when retransmission of a "busy" buffer is required. Sponsored by: Hobnob, Inc.
2011-11-08 21:13:05 +00:00
/*
* When retrying a software frame, buffers marked ATH_BUF_BUSY
* can't be thrown back on the queue as they could still be
* in use by the hardware.
*
* This duplicates the buffer, or returns NULL.
*
* The descriptor is also copied but the link pointers and
* the DMA segments aren't copied; this frame should thus
* be again passed through the descriptor setup/chain routines
* so the link is correct.
*
* The caller must free the buffer using ath_freebuf().
*/
struct ath_buf *
Ensure that we only call the busdma unmap/flush routines once, when the buffer is being freed. * When buffers are cloned, the original mapping isn't copied but it wasn't freeing the mapping until later. To be safe, free the mapping when the buffer is cloned. * ath_freebuf() now no longer calls the busdma sync/unmap routines. * ath_tx_freebuf() now calls sync/unmap. * Call sync first, before calling unmap. Tested: * AR5416, STA mode
2013-04-01 20:57:13 +00:00
ath_buf_clone(struct ath_softc *sc, struct ath_buf *bf)
Change ath_buf allocation to: * Immediately return NULL if a buffer isn't available; * Track the "buffers not available" count; * Clear some fields used for tx aggregation; * Add ath_buf_clone() which clones the majority of buffer state. This is needed when retransmission of a "busy" buffer is required. Sponsored by: Hobnob, Inc.
2011-11-08 21:13:05 +00:00
{
struct ath_buf *tbf;
Implement a separate, smaller pool of ath_buf entries for use by management traffic. * Create sc_mgmt_txbuf and sc_mgmt_txdesc, initialise/free them appropriately. * Create an enum to represent buffer types in the API. * Extend ath_getbuf() and _ath_getbuf_locked() to take the above enum. * Right now anything sent via ic_raw_xmit() allocates via ATH_BUFTYPE_MGMT. This may not be very useful. * Add ATH_BUF_MGMT flag (ath_buf.bf_flags) which indicates the current buffer is a mgmt buffer and should go back onto the mgmt free list. * Extend 'txagg' to include debugging output for both normal and mgmt txbufs. * When checking/clearing ATH_BUF_BUSY, do it on both TX pools. Tested: * STA mode, with heavy UDP injection via iperf. This filled the TX queue however BARs were still going out successfully. TODO: * Initialise the mgmt buffers with ATH_BUF_MGMT and then ensure the right type is being allocated and freed on the appropriate list. That'd save a write operation (to bf->bf_flags) on each buffer alloc/free. * Test on AP mode, ensure that BAR TX and probe responses go out nicely when the main TX queue is filled (eg with paused traffic to a TID, awaiting a BAR to complete.) PR: kern/168170
2012-06-13 06:57:55 +00:00
tbf = ath_getbuf(sc,
(bf->bf_flags & ATH_BUF_MGMT) ?
ATH_BUFTYPE_MGMT : ATH_BUFTYPE_NORMAL);
Change ath_buf allocation to: * Immediately return NULL if a buffer isn't available; * Track the "buffers not available" count; * Clear some fields used for tx aggregation; * Add ath_buf_clone() which clones the majority of buffer state. This is needed when retransmission of a "busy" buffer is required. Sponsored by: Hobnob, Inc.
2011-11-08 21:13:05 +00:00
if (tbf == NULL)
return NULL; /* XXX failure? Why? */
/* Copy basics */
tbf->bf_next = NULL;
tbf->bf_nseg = bf->bf_nseg;
Add per-TXQ EDMA FIFO staging queue support. Each set of frames pushed into a FIFO is represented by a list of ath_bufs - the first ath_buf in the FIFO list is marked with ATH_BUF_FIFOPTR; the last ath_buf in the FIFO list is marked with ATH_BUF_FIFOEND. Multiple lists of frames are just glued together in the TAILQ as per normal - except that at the end of a FIFO list, the descriptor link pointer will be NULL and it'll be tagged with ATH_BUF_FIFOEND. For non-EDMA chipsets this is a no-op - the ath_txq frame list (axq_q) stays the same and is treated the same. For EDMA chipsets the frames are pushed into axq_q and then when the FIFO is to be (re) filled, frames will be moved onto the FIFO queue and then pushed into the FIFO. So: * Add a new queue in each hardware TXQ (ath_txq) for staging FIFO frame lists. It's a TAILQ (like the normal hardware frame queue) rather than the ath9k list-of-lists to represent FIFO entries. * Add new ath_buf flags - ATH_TX_FIFOPTR and ATH_TX_FIFOEND. * When allocating ath_buf entries, clear out the flag value before returning it or it'll end up having stale flags. * When cloning ath_buf entries, only clone ATH_BUF_MGMT. Don't clone the FIFO related flags. * Extend ath_tx_draintxq() to first drain the FIFO staging queue, _then_ drain the normal hardware queue. Tested: * AR9280, hostap * AR9280, STA * AR9380/AR9580 - hostap TODO: * Test on other chipsets, just to be thorough.
2013-03-26 19:46:51 +00:00
tbf->bf_flags = bf->bf_flags & ATH_BUF_FLAGS_CLONE;
Change ath_buf allocation to: * Immediately return NULL if a buffer isn't available; * Track the "buffers not available" count; * Clear some fields used for tx aggregation; * Add ath_buf_clone() which clones the majority of buffer state. This is needed when retransmission of a "busy" buffer is required. Sponsored by: Hobnob, Inc.
2011-11-08 21:13:05 +00:00
tbf->bf_status = bf->bf_status;
tbf->bf_m = bf->bf_m;
tbf->bf_node = bf->bf_node;
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
KASSERT((bf->bf_node != NULL), ("%s: bf_node=NULL!", __func__));
Change ath_buf allocation to: * Immediately return NULL if a buffer isn't available; * Track the "buffers not available" count; * Clear some fields used for tx aggregation; * Add ath_buf_clone() which clones the majority of buffer state. This is needed when retransmission of a "busy" buffer is required. Sponsored by: Hobnob, Inc.
2011-11-08 21:13:05 +00:00
/* will be setup by the chain/setup function */
tbf->bf_lastds = NULL;
/* for now, last == self */
tbf->bf_last = tbf;
tbf->bf_comp = bf->bf_comp;
/* NOTE: DMA segments will be setup by the setup/chain functions */
/* The caller has to re-init the descriptor + links */
Ensure that we only call the busdma unmap/flush routines once, when the buffer is being freed. * When buffers are cloned, the original mapping isn't copied but it wasn't freeing the mapping until later. To be safe, free the mapping when the buffer is cloned. * ath_freebuf() now no longer calls the busdma sync/unmap routines. * ath_tx_freebuf() now calls sync/unmap. * Call sync first, before calling unmap. Tested: * AR5416, STA mode
2013-04-01 20:57:13 +00:00
/*
* Free the DMA mapping here, before we NULL the mbuf.
* We must only call bus_dmamap_unload() once per mbuf chain
* or behaviour is undefined.
*/
if (bf->bf_m != NULL) {
/*
* XXX is this POSTWRITE call required?
*/
bus_dmamap_sync(sc->sc_dmat, bf->bf_dmamap,
BUS_DMASYNC_POSTWRITE);
bus_dmamap_unload(sc->sc_dmat, bf->bf_dmamap);
}
bf->bf_m = NULL;
bf->bf_node = NULL;
Change ath_buf allocation to: * Immediately return NULL if a buffer isn't available; * Track the "buffers not available" count; * Clear some fields used for tx aggregation; * Add ath_buf_clone() which clones the majority of buffer state. This is needed when retransmission of a "busy" buffer is required. Sponsored by: Hobnob, Inc.
2011-11-08 21:13:05 +00:00
/* Copy state */
memcpy(&tbf->bf_state, &bf->bf_state, sizeof(bf->bf_state));
return tbf;
}
Migrate the TX path code out of if_ath and into a separate source file. There's two reasons for this: * the raw and non-raw TX path shares a lot of duplicate code which should be refactored; * the 11n-ready chip TX path needs a little reworking.
2011-01-29 11:35:23 +00:00
struct ath_buf *
Implement a separate, smaller pool of ath_buf entries for use by management traffic. * Create sc_mgmt_txbuf and sc_mgmt_txdesc, initialise/free them appropriately. * Create an enum to represent buffer types in the API. * Extend ath_getbuf() and _ath_getbuf_locked() to take the above enum. * Right now anything sent via ic_raw_xmit() allocates via ATH_BUFTYPE_MGMT. This may not be very useful. * Add ATH_BUF_MGMT flag (ath_buf.bf_flags) which indicates the current buffer is a mgmt buffer and should go back onto the mgmt free list. * Extend 'txagg' to include debugging output for both normal and mgmt txbufs. * When checking/clearing ATH_BUF_BUSY, do it on both TX pools. Tested: * STA mode, with heavy UDP injection via iperf. This filled the TX queue however BARs were still going out successfully. TODO: * Initialise the mgmt buffers with ATH_BUF_MGMT and then ensure the right type is being allocated and freed on the appropriate list. That'd save a write operation (to bf->bf_flags) on each buffer alloc/free. * Test on AP mode, ensure that BAR TX and probe responses go out nicely when the main TX queue is filled (eg with paused traffic to a TID, awaiting a BAR to complete.) PR: kern/168170
2012-06-13 06:57:55 +00:00
ath_getbuf(struct ath_softc *sc, ath_buf_type_t btype)
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
{
struct ath_buf *bf;
ATH_TXBUF_LOCK(sc);
Implement a separate, smaller pool of ath_buf entries for use by management traffic. * Create sc_mgmt_txbuf and sc_mgmt_txdesc, initialise/free them appropriately. * Create an enum to represent buffer types in the API. * Extend ath_getbuf() and _ath_getbuf_locked() to take the above enum. * Right now anything sent via ic_raw_xmit() allocates via ATH_BUFTYPE_MGMT. This may not be very useful. * Add ATH_BUF_MGMT flag (ath_buf.bf_flags) which indicates the current buffer is a mgmt buffer and should go back onto the mgmt free list. * Extend 'txagg' to include debugging output for both normal and mgmt txbufs. * When checking/clearing ATH_BUF_BUSY, do it on both TX pools. Tested: * STA mode, with heavy UDP injection via iperf. This filled the TX queue however BARs were still going out successfully. TODO: * Initialise the mgmt buffers with ATH_BUF_MGMT and then ensure the right type is being allocated and freed on the appropriate list. That'd save a write operation (to bf->bf_flags) on each buffer alloc/free. * Test on AP mode, ensure that BAR TX and probe responses go out nicely when the main TX queue is filled (eg with paused traffic to a TID, awaiting a BAR to complete.) PR: kern/168170
2012-06-13 06:57:55 +00:00
bf = _ath_getbuf_locked(sc, btype);
/*
* If a mgmt buffer was requested but we're out of those,
* try requesting a normal one.
*/
if (bf == NULL && btype == ATH_BUFTYPE_MGMT)
bf = _ath_getbuf_locked(sc, ATH_BUFTYPE_NORMAL);
Stick the if_drv_flags access (check and modify) behind the ifq lock. Although access to the flags to check/set OACTIVE is racy due to how the default if_start() function works, this should remove any races with read/modify/write between threads.
2012-03-10 20:09:02 +00:00
ATH_TXBUF_UNLOCK(sc);
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
if (bf == NULL) {
DPRINTF(sc, ATH_DEBUG_XMIT, "%s: stop queue\n", __func__);
sc->sc_stats.ast_tx_qstop++;
}
return bf;
}
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
/*
* Transmit a single frame.
*
* net80211 will free the node reference if the transmit
* fails, so don't free the node reference here.
*/
static int
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
ath_transmit(struct ieee80211com *ic, struct mbuf *m)
Push the actual TX processing into the ath taskqueue, rather than having it run out of multiple concurrent contexts. Right now the ath(4) TX processing is a bit hairy. Specifically: * It was running out of ath_start(), which could occur from multiple concurrent sending processes (as if_start() can be started from multiple sending threads nowdays.. sigh) * during RX if fast frames are enabled (so not really at the moment, not until I fix this particular feature again..) * during ath_reset() - so anything which calls that * during ath_tx_proc*() in the ath taskqueue - ie, TX is attempted again after TX completion, as there's now hopefully some ath_bufs available. * Then, the ic_raw_xmit() method can queue raw frames for transmission at any time, from any net80211 TX context. Ew. This has caused packet ordering issues in the past - specifically, there's absolutely no guarantee that preemption won't occuring _during_ ath_start() by the TX completion processing, which will call ath_start() again. It's a mess - 802.11 really, really wants things to be in sequence or things go all kinds of loopy. So: * create a new task struct for TX'ing; * make the if_start method simply queue the task on the ath taskqueue; * make ath_start() just be called by the new TX task; * make ath_tx_kick() just schedule the ath TX task, rather than directly calling ath_start(). Now yes, this means that I've taken a step backwards in terms of concurrency - TX -and- RX now occur in the same single-task taskqueue. But there's nothing stopping me from separating out the TX / TX completion code into a separate taskqueue which runs in parallel with the RX path, if that ends up being appropriate for some platforms. This fixes the CCMP/seqno concurrency issues that creep up when you transmit large amounts of uni-directional UDP traffic (>200MBit) on a FreeBSD STA -> AP, as now there's only one TX context no matter what's going on (TX completion->retry/software queue, userland->net80211->ath_start(), TX completion -> ath_start()); but it won't fix any concurrency issues between raw transmitted frames and non-raw transmitted frames (eg EAPOL frames on TID 16 and any other TID 16 multicast traffic that gets put on the CABQ.) That is going to require a bunch more re-architecture before it's feasible to fix. In any case, this is a big step towards making the majority of the TX path locking irrelevant, as now almost all TX activity occurs in the taskqueue. Phew.
2012-10-14 20:44:08 +00:00
{
Remove most of the references of ifp->if_softc and replace with references to ic->ic_softc. This is in preparation for gleb's ifnet work. Tested: * ath(4), STA mode * ath(4), hostap mode * make universe
2015-08-17 02:04:11 +00:00
struct ath_softc *sc = ic->ic_softc;
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
struct ieee80211_node *ni;
struct mbuf *next;
struct ath_buf *bf;
ath_bufhead frags;
int retval = 0;
I give up - introduce a TX lock to serialise TX operations. I've tried serialising TX using queues and such but unfortunately due to how this interacts with the locking going on elsewhere in the networking stack, the TX task gets delayed, resulting in quite a noticable throughput loss: * baseline TCP for 2x2 11n HT40 is ~ 170mbit/sec; * TCP for TX task in the ath taskq, with the RX also going on - 80mbit/sec; * TCP for TX task in a separate, second taskq - 100mbit/sec. So for now I'm going with the Linux wireless stack approach - lock tx early. The linux code does in the wireless stack, before the 802.11 state stuff happens and before it's punted to the driver. But TX locking needs to also occur at the driver layer as the TX completion code _also_ begins to drain the ifnet TX queue. Whilst I'm here, add some KTR traces for the TX path. Note: * This really should be done at the net80211 layer (as well, at least.) But that'll have to wait for a little more thought to happen.
2012-10-31 06:27:58 +00:00
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
/*
* Tell the reset path that we're currently transmitting.
*/
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
ATH_PCU_LOCK(sc);
if (sc->sc_inreset_cnt > 0) {
Move a lot of debugging printf's to DPRINTF. Approved by: adrian MFC after: 2 weeks
2013-10-17 01:53:07 +00:00
DPRINTF(sc, ATH_DEBUG_XMIT,
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
"%s: sc_inreset_cnt > 0; bailing\n", __func__);
ATH_PCU_UNLOCK(sc);
Implement a global (all non-mgmt traffic) TX ath_buf limitation when ath_start() is called. This (defaults to 10 frames) gives for a little headway in the TX ath_buf allocation, so buffer cloning is still possible. This requires a lot omre experimenting and tuning. It also doesn't stop a node/TID from consuming all of the available ath_buf's, especially when the node is going through high packet loss or only talking at a low TX rate. It also doesn't stop a paused TID from taking all of the ath_bufs. I'll look at fixing that up in subsequent commits. PR: kern/168170
2012-06-14 00:51:53 +00:00
sc->sc_stats.ast_tx_qstop++;
I give up - introduce a TX lock to serialise TX operations. I've tried serialising TX using queues and such but unfortunately due to how this interacts with the locking going on elsewhere in the networking stack, the TX task gets delayed, resulting in quite a noticable throughput loss: * baseline TCP for 2x2 11n HT40 is ~ 170mbit/sec; * TCP for TX task in the ath taskq, with the RX also going on - 80mbit/sec; * TCP for TX task in a separate, second taskq - 100mbit/sec. So for now I'm going with the Linux wireless stack approach - lock tx early. The linux code does in the wireless stack, before the 802.11 state stuff happens and before it's punted to the driver. But TX locking needs to also occur at the driver layer as the TX completion code _also_ begins to drain the ifnet TX queue. Whilst I'm here, add some KTR traces for the TX path. Note: * This really should be done at the net80211 layer (as well, at least.) But that'll have to wait for a little more thought to happen.
2012-10-31 06:27:58 +00:00
ATH_KTR(sc, ATH_KTR_TX, 0, "ath_start_task: OACTIVE, finish");
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
return (ENOBUFS); /* XXX should be EINVAL or? */
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
}
sc->sc_txstart_cnt++;
ATH_PCU_UNLOCK(sc);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
/* Wake the hardware up already */
ATH_LOCK(sc);
ath_power_set_power_state(sc, HAL_PM_AWAKE);
ATH_UNLOCK(sc);
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
ATH_KTR(sc, ATH_KTR_TX, 0, "ath_transmit: start");
/*
* Grab the TX lock - it's ok to do this here; we haven't
* yet started transmitting.
*/
Pull out the if_transmit() work and revert back to ath_start(). My changed had some rather significant behavioural changes to throughput. The two issues I noticed: * With if_start and the ifnet mbuf queue, any temporary latency would get eaten up by some mbufs being queued. With ath_transmit() queuing things to ath_buf's, I'd only get 512 TX buffers before I couldn't queue any further frames. * There's also some non-zero latency involved with TX being pushed into a taskqueue via direct dispatch. Any time the scheduler didn't immediately schedule the ath TX task would cause extra latency. Various 1ge/10ge drivers implement both direct dispatch (if the TX lock can be acquired) and deferred task transmission (if the TX lock can't be acquired), with frames being pushed into a drbd queue. I'll have to do this at some point, but until I figure out how to deal with 802.11 fragments, I'll have to wait a while longer. So what I saw: * lots of extra latency, specially under load - if the taskqueue wasn't immediately scheduled, things went pear shaped; * any extra latency would result in TX ath_buf's taking their sweet time being replenished, so any further calls to ath_transmit() would drop mbufs. * .. yes, there's no explicit backpressure here - things are just dropped. Eek. With this, the general performance has gone up, but those subtle if_start() related race conditions are back. For some reason, this is doubly-obvious with the AR5416 NIC and I don't quite understand why yet. There's an unrelated issue with AR5416 performance in STA mode (it's fine in AP mode when bridging frames, weirdly..) that requires a little further investigation. Specifically - it works fine on a Lenovo T40 (single core CPU) running a March 2012 9-STABLE kernel, but a Lenovo T60 (dual core) running an early November 2012 kernel behaves very poorly. The same hardware with an AR9160 or AR9280 behaves perfectly.
2013-02-13 05:32:19 +00:00
ATH_TX_LOCK(sc);
Push the actual TX processing into the ath taskqueue, rather than having it run out of multiple concurrent contexts. Right now the ath(4) TX processing is a bit hairy. Specifically: * It was running out of ath_start(), which could occur from multiple concurrent sending processes (as if_start() can be started from multiple sending threads nowdays.. sigh) * during RX if fast frames are enabled (so not really at the moment, not until I fix this particular feature again..) * during ath_reset() - so anything which calls that * during ath_tx_proc*() in the ath taskqueue - ie, TX is attempted again after TX completion, as there's now hopefully some ath_bufs available. * Then, the ic_raw_xmit() method can queue raw frames for transmission at any time, from any net80211 TX context. Ew. This has caused packet ordering issues in the past - specifically, there's absolutely no guarantee that preemption won't occuring _during_ ath_start() by the TX completion processing, which will call ath_start() again. It's a mess - 802.11 really, really wants things to be in sequence or things go all kinds of loopy. So: * create a new task struct for TX'ing; * make the if_start method simply queue the task on the ath taskqueue; * make ath_start() just be called by the new TX task; * make ath_tx_kick() just schedule the ath TX task, rather than directly calling ath_start(). Now yes, this means that I've taken a step backwards in terms of concurrency - TX -and- RX now occur in the same single-task taskqueue. But there's nothing stopping me from separating out the TX / TX completion code into a separate taskqueue which runs in parallel with the RX path, if that ends up being appropriate for some platforms. This fixes the CCMP/seqno concurrency issues that creep up when you transmit large amounts of uni-directional UDP traffic (>200MBit) on a FreeBSD STA -> AP, as now there's only one TX context no matter what's going on (TX completion->retry/software queue, userland->net80211->ath_start(), TX completion -> ath_start()); but it won't fix any concurrency issues between raw transmitted frames and non-raw transmitted frames (eg EAPOL frames on TID 16 and any other TID 16 multicast traffic that gets put on the CABQ.) That is going to require a bunch more re-architecture before it's feasible to fix. In any case, this is a big step towards making the majority of the TX path locking irrelevant, as now almost all TX activity occurs in the taskqueue. Phew.
2012-10-14 20:44:08 +00:00
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
/*
* Node reference, if there's one.
*/
ni = (struct ieee80211_node *) m->m_pkthdr.rcvif;
Implement frame (data) transmission using if_transmit(), rather than if_start(). This removes the overlapping data path TX from occuring, which solves quite a number of the potential TX queue races in ath(4). It doesn't fix the net80211 layer TX queue races and it doesn't fix the raw TX path yet, but it's an important step towards this. This hasn't dropped the TX performance in my testing; primarily because now the TX path can quickly queue frames and continue along processing. This involves a few rather deep changes: * Use the ath_buf as a queue placeholder for now, as we need to be able to support queuing a list of mbufs (ie, when transmitting fragments) and m_nextpkt can't be used here (because it's what is joining the fragments together) * if_transmit() now simply allocates the ath_buf and queues it to a driver TX staging queue. * TX is now moved into a taskqueue function. * The TX taskqueue function now dequeues and transmits frames. * Fragments are handled correctly here - as the current API passes the fragment list as one mbuf list (joined with m_nextpkt) through to the driver if_transmit(). * For the couple of places where ath_start() may be called (mostly from net80211 when starting the VAP up again), just reimplement it using the new enqueue and taskqueue methods. What I don't like (about this work and the TX code in general): * I'm using the same lock for the staging TX queue management and the actual TX. This isn't required; I'm just being slack. * I haven't yet moved TX to a separate taskqueue (but the taskqueue is created); it's easy enough to do this later if necessary. I just need to make sure it's a higher priority queue, so TX has the same behaviour as it used to (where it would preempt existing RX..) * I need to re-review the TX path a little more and make sure that ieee80211_node_*() functions aren't called within the TX lock. When queueing, I should just push failed frames into a queue and when I'm wrapping up the TX code, unlock the TX lock and call ieee80211_node_free() on each. * It would be nice if I could hold the TX lock for the entire TX and TX completion, rather than this release/re-acquire behaviour. But that requires that I shuffle around the TX completion code to handle actual ath_buf free and net80211 callback/free outside of the TX lock. That's one of my next projects. * the ic_raw_xmit() path doesn't use this yet - so it still has sequencing problems with parallel, overlapping calls to the data path. I'll fix this later. Tested: * Hostap - AR9280, AR9220 * STA - AR5212, AR9280, AR5416
2013-01-15 18:01:23 +00:00
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
/*
* Enforce how deep a node queue can get.
*
* XXX it would be nicer if we kept an mbuf queue per
* node and only whacked them into ath_bufs when we
* are ready to schedule some traffic from them.
* .. that may come later.
*
* XXX we should also track the per-node hardware queue
* depth so it is easy to limit the _SUM_ of the swq and
* hwq frames. Since we only schedule two HWQ frames
* at a time, this should be OK for now.
*/
if ((!(m->m_flags & M_EAPOL)) &&
(ATH_NODE(ni)->an_swq_depth > sc->sc_txq_node_maxdepth)) {
sc->sc_stats.ast_tx_nodeq_overflow++;
retval = ENOBUFS;
goto finish;
}
Implement frame (data) transmission using if_transmit(), rather than if_start(). This removes the overlapping data path TX from occuring, which solves quite a number of the potential TX queue races in ath(4). It doesn't fix the net80211 layer TX queue races and it doesn't fix the raw TX path yet, but it's an important step towards this. This hasn't dropped the TX performance in my testing; primarily because now the TX path can quickly queue frames and continue along processing. This involves a few rather deep changes: * Use the ath_buf as a queue placeholder for now, as we need to be able to support queuing a list of mbufs (ie, when transmitting fragments) and m_nextpkt can't be used here (because it's what is joining the fragments together) * if_transmit() now simply allocates the ath_buf and queues it to a driver TX staging queue. * TX is now moved into a taskqueue function. * The TX taskqueue function now dequeues and transmits frames. * Fragments are handled correctly here - as the current API passes the fragment list as one mbuf list (joined with m_nextpkt) through to the driver if_transmit(). * For the couple of places where ath_start() may be called (mostly from net80211 when starting the VAP up again), just reimplement it using the new enqueue and taskqueue methods. What I don't like (about this work and the TX code in general): * I'm using the same lock for the staging TX queue management and the actual TX. This isn't required; I'm just being slack. * I haven't yet moved TX to a separate taskqueue (but the taskqueue is created); it's easy enough to do this later if necessary. I just need to make sure it's a higher priority queue, so TX has the same behaviour as it used to (where it would preempt existing RX..) * I need to re-review the TX path a little more and make sure that ieee80211_node_*() functions aren't called within the TX lock. When queueing, I should just push failed frames into a queue and when I'm wrapping up the TX code, unlock the TX lock and call ieee80211_node_free() on each. * It would be nice if I could hold the TX lock for the entire TX and TX completion, rather than this release/re-acquire behaviour. But that requires that I shuffle around the TX completion code to handle actual ath_buf free and net80211 callback/free outside of the TX lock. That's one of my next projects. * the ic_raw_xmit() path doesn't use this yet - so it still has sequencing problems with parallel, overlapping calls to the data path. I'll fix this later. Tested: * Hostap - AR9280, AR9220 * STA - AR5212, AR9280, AR5416
2013-01-15 18:01:23 +00:00
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
/*
* Check how many TX buffers are available.
*
* If this is for non-EAPOL traffic, just leave some
* space free in order for buffer cloning and raw
* frame transmission to occur.
*
* If it's for EAPOL traffic, ignore this for now.
* Management traffic will be sent via the raw transmit
* method which bypasses this check.
*
* This is needed to ensure that EAPOL frames during
* (re) keying have a chance to go out.
*
* See kern/138379 for more information.
*/
if ((!(m->m_flags & M_EAPOL)) &&
(sc->sc_txbuf_cnt <= sc->sc_txq_data_minfree)) {
sc->sc_stats.ast_tx_nobuf++;
retval = ENOBUFS;
goto finish;
}
Implement frame (data) transmission using if_transmit(), rather than if_start(). This removes the overlapping data path TX from occuring, which solves quite a number of the potential TX queue races in ath(4). It doesn't fix the net80211 layer TX queue races and it doesn't fix the raw TX path yet, but it's an important step towards this. This hasn't dropped the TX performance in my testing; primarily because now the TX path can quickly queue frames and continue along processing. This involves a few rather deep changes: * Use the ath_buf as a queue placeholder for now, as we need to be able to support queuing a list of mbufs (ie, when transmitting fragments) and m_nextpkt can't be used here (because it's what is joining the fragments together) * if_transmit() now simply allocates the ath_buf and queues it to a driver TX staging queue. * TX is now moved into a taskqueue function. * The TX taskqueue function now dequeues and transmits frames. * Fragments are handled correctly here - as the current API passes the fragment list as one mbuf list (joined with m_nextpkt) through to the driver if_transmit(). * For the couple of places where ath_start() may be called (mostly from net80211 when starting the VAP up again), just reimplement it using the new enqueue and taskqueue methods. What I don't like (about this work and the TX code in general): * I'm using the same lock for the staging TX queue management and the actual TX. This isn't required; I'm just being slack. * I haven't yet moved TX to a separate taskqueue (but the taskqueue is created); it's easy enough to do this later if necessary. I just need to make sure it's a higher priority queue, so TX has the same behaviour as it used to (where it would preempt existing RX..) * I need to re-review the TX path a little more and make sure that ieee80211_node_*() functions aren't called within the TX lock. When queueing, I should just push failed frames into a queue and when I'm wrapping up the TX code, unlock the TX lock and call ieee80211_node_free() on each. * It would be nice if I could hold the TX lock for the entire TX and TX completion, rather than this release/re-acquire behaviour. But that requires that I shuffle around the TX completion code to handle actual ath_buf free and net80211 callback/free outside of the TX lock. That's one of my next projects. * the ic_raw_xmit() path doesn't use this yet - so it still has sequencing problems with parallel, overlapping calls to the data path. I'll fix this later. Tested: * Hostap - AR9280, AR9220 * STA - AR5212, AR9280, AR5416
2013-01-15 18:01:23 +00:00
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
/*
* Grab a TX buffer and associated resources.
*
* If it's an EAPOL frame, allocate a MGMT ath_buf.
* That way even with temporary buffer exhaustion due to
* the data path doesn't leave us without the ability
* to transmit management frames.
*
* Otherwise allocate a normal buffer.
*/
if (m->m_flags & M_EAPOL)
bf = ath_getbuf(sc, ATH_BUFTYPE_MGMT);
else
bf = ath_getbuf(sc, ATH_BUFTYPE_NORMAL);
Re-work how transmit buffer limits are enforced - partly to fix the PR, but partly to just tidy up things. The problem here - there are too many TX buffers in the queue! By the time one needs to transmit an EAPOL frame (for this PR, it's the response to the group rekey notification from the AP) there are no ath_buf entries free and the EAPOL frame doesn't go out. Now, the problem! * Enforcing the TX buffer limitation _before_ we dequeue the frame? Bad idea. Because.. * .. it means I can't check whether the mbuf has M_EAPOL set. The solution(s): * De-queue the frame first * Don't bother doing the TX buffer minimum free check until after we know whether it's an EAPOL frame or not. * If it's an EAPOL frame, allocate the buffer from the mgmt pool rather than the default pool. Whilst I'm here: * Add a tweak to limit how many buffers a single node can acquire. * Don't enforce that for EAPOL frames. * .. set that to default to 1/4 of the available buffers, or 32, whichever is more sane. This doesn't fix issues due to a sleeping node or a very poor performing node; but this doesn't make it worse. Tested: * AR5416 STA, TX'ing 100+ mbit UDP to an AP, but only 50mbit being received (thus the TX queue fills up.) * .. with CCMP / WPA2 encryption configured * .. and the group rekey time set to 10 seconds, just to elicit the behaviour very quickly. PR: kern/138379
2013-05-07 07:52:18 +00:00
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
if (bf == NULL) {
Re-work how transmit buffer limits are enforced - partly to fix the PR, but partly to just tidy up things. The problem here - there are too many TX buffers in the queue! By the time one needs to transmit an EAPOL frame (for this PR, it's the response to the group rekey notification from the AP) there are no ath_buf entries free and the EAPOL frame doesn't go out. Now, the problem! * Enforcing the TX buffer limitation _before_ we dequeue the frame? Bad idea. Because.. * .. it means I can't check whether the mbuf has M_EAPOL set. The solution(s): * De-queue the frame first * Don't bother doing the TX buffer minimum free check until after we know whether it's an EAPOL frame or not. * If it's an EAPOL frame, allocate the buffer from the mgmt pool rather than the default pool. Whilst I'm here: * Add a tweak to limit how many buffers a single node can acquire. * Don't enforce that for EAPOL frames. * .. set that to default to 1/4 of the available buffers, or 32, whichever is more sane. This doesn't fix issues due to a sleeping node or a very poor performing node; but this doesn't make it worse. Tested: * AR5416 STA, TX'ing 100+ mbit UDP to an AP, but only 50mbit being received (thus the TX queue fills up.) * .. with CCMP / WPA2 encryption configured * .. and the group rekey time set to 10 seconds, just to elicit the behaviour very quickly. PR: kern/138379
2013-05-07 07:52:18 +00:00
/*
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
* If we failed to allocate a buffer, fail.
Re-work how transmit buffer limits are enforced - partly to fix the PR, but partly to just tidy up things. The problem here - there are too many TX buffers in the queue! By the time one needs to transmit an EAPOL frame (for this PR, it's the response to the group rekey notification from the AP) there are no ath_buf entries free and the EAPOL frame doesn't go out. Now, the problem! * Enforcing the TX buffer limitation _before_ we dequeue the frame? Bad idea. Because.. * .. it means I can't check whether the mbuf has M_EAPOL set. The solution(s): * De-queue the frame first * Don't bother doing the TX buffer minimum free check until after we know whether it's an EAPOL frame or not. * If it's an EAPOL frame, allocate the buffer from the mgmt pool rather than the default pool. Whilst I'm here: * Add a tweak to limit how many buffers a single node can acquire. * Don't enforce that for EAPOL frames. * .. set that to default to 1/4 of the available buffers, or 32, whichever is more sane. This doesn't fix issues due to a sleeping node or a very poor performing node; but this doesn't make it worse. Tested: * AR5416 STA, TX'ing 100+ mbit UDP to an AP, but only 50mbit being received (thus the TX queue fills up.) * .. with CCMP / WPA2 encryption configured * .. and the group rekey time set to 10 seconds, just to elicit the behaviour very quickly. PR: kern/138379
2013-05-07 07:52:18 +00:00
*
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
* We shouldn't fail normally, due to the check
* above.
Re-work how transmit buffer limits are enforced - partly to fix the PR, but partly to just tidy up things. The problem here - there are too many TX buffers in the queue! By the time one needs to transmit an EAPOL frame (for this PR, it's the response to the group rekey notification from the AP) there are no ath_buf entries free and the EAPOL frame doesn't go out. Now, the problem! * Enforcing the TX buffer limitation _before_ we dequeue the frame? Bad idea. Because.. * .. it means I can't check whether the mbuf has M_EAPOL set. The solution(s): * De-queue the frame first * Don't bother doing the TX buffer minimum free check until after we know whether it's an EAPOL frame or not. * If it's an EAPOL frame, allocate the buffer from the mgmt pool rather than the default pool. Whilst I'm here: * Add a tweak to limit how many buffers a single node can acquire. * Don't enforce that for EAPOL frames. * .. set that to default to 1/4 of the available buffers, or 32, whichever is more sane. This doesn't fix issues due to a sleeping node or a very poor performing node; but this doesn't make it worse. Tested: * AR5416 STA, TX'ing 100+ mbit UDP to an AP, but only 50mbit being received (thus the TX queue fills up.) * .. with CCMP / WPA2 encryption configured * .. and the group rekey time set to 10 seconds, just to elicit the behaviour very quickly. PR: kern/138379
2013-05-07 07:52:18 +00:00
*/
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
sc->sc_stats.ast_tx_nobuf++;
retval = ENOBUFS;
goto finish;
}
/*
* At this point we have a buffer; so we need to free it
* if we hit any error conditions.
*/
/*
* Check for fragmentation. If this frame
* has been broken up verify we have enough
* buffers to send all the fragments so all
* go out or none...
*/
TAILQ_INIT(&frags);
if ((m->m_flags & M_FRAG) &&
!ath_txfrag_setup(sc, &frags, m, ni)) {
DPRINTF(sc, ATH_DEBUG_XMIT,
"%s: out of txfrag buffers\n", __func__);
sc->sc_stats.ast_tx_nofrag++;
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
if_inc_counter(ni->ni_vap->iv_ifp, IFCOUNTER_OERRORS, 1);
/*
* XXXGL: is mbuf valid after ath_txfrag_setup? If yes,
* we shouldn't free it but return back.
*/
net80211: separate mbuf cleanup from ieee80211_fragment() * Create ieee80211_free_mbuf() which frees a list of mbufs. * Use it in the fragment transmit path and ath / uath transmit paths. * Call it in xmit_pkt() if the transmission fails; otherwise fragments may be leaked. This should be a big no-op. Submitted by: <s3erios@gmail.com> Differential Revision: https://reviews.freebsd.org/D3769
2015-10-12 03:27:08 +00:00
ieee80211_free_mbuf(m);
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
m = NULL;
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
goto bad;
}
/*
* At this point if we have any TX fragments, then we will
* have bumped the node reference once for each of those.
*/
/*
* XXX Is there anything actually _enforcing_ that the
* fragments are being transmitted in one hit, rather than
* being interleaved with other transmissions on that
* hardware queue?
*
* The ATH TX output lock is the only thing serialising this
* right now.
*/
/*
* Calculate the "next fragment" length field in ath_buf
* in order to let the transmit path know enough about
* what to next write to the hardware.
*/
if (m->m_flags & M_FRAG) {
struct ath_buf *fbf = bf;
struct ath_buf *n_fbf = NULL;
struct mbuf *fm = m->m_nextpkt;
Re-work how transmit buffer limits are enforced - partly to fix the PR, but partly to just tidy up things. The problem here - there are too many TX buffers in the queue! By the time one needs to transmit an EAPOL frame (for this PR, it's the response to the group rekey notification from the AP) there are no ath_buf entries free and the EAPOL frame doesn't go out. Now, the problem! * Enforcing the TX buffer limitation _before_ we dequeue the frame? Bad idea. Because.. * .. it means I can't check whether the mbuf has M_EAPOL set. The solution(s): * De-queue the frame first * Don't bother doing the TX buffer minimum free check until after we know whether it's an EAPOL frame or not. * If it's an EAPOL frame, allocate the buffer from the mgmt pool rather than the default pool. Whilst I'm here: * Add a tweak to limit how many buffers a single node can acquire. * Don't enforce that for EAPOL frames. * .. set that to default to 1/4 of the available buffers, or 32, whichever is more sane. This doesn't fix issues due to a sleeping node or a very poor performing node; but this doesn't make it worse. Tested: * AR5416 STA, TX'ing 100+ mbit UDP to an AP, but only 50mbit being received (thus the TX queue fills up.) * .. with CCMP / WPA2 encryption configured * .. and the group rekey time set to 10 seconds, just to elicit the behaviour very quickly. PR: kern/138379
2013-05-07 07:52:18 +00:00
/*
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
* We need to walk the list of fragments and set
* the next size to the following buffer.
* However, the first buffer isn't in the frag
* list, so we have to do some gymnastics here.
Re-work how transmit buffer limits are enforced - partly to fix the PR, but partly to just tidy up things. The problem here - there are too many TX buffers in the queue! By the time one needs to transmit an EAPOL frame (for this PR, it's the response to the group rekey notification from the AP) there are no ath_buf entries free and the EAPOL frame doesn't go out. Now, the problem! * Enforcing the TX buffer limitation _before_ we dequeue the frame? Bad idea. Because.. * .. it means I can't check whether the mbuf has M_EAPOL set. The solution(s): * De-queue the frame first * Don't bother doing the TX buffer minimum free check until after we know whether it's an EAPOL frame or not. * If it's an EAPOL frame, allocate the buffer from the mgmt pool rather than the default pool. Whilst I'm here: * Add a tweak to limit how many buffers a single node can acquire. * Don't enforce that for EAPOL frames. * .. set that to default to 1/4 of the available buffers, or 32, whichever is more sane. This doesn't fix issues due to a sleeping node or a very poor performing node; but this doesn't make it worse. Tested: * AR5416 STA, TX'ing 100+ mbit UDP to an AP, but only 50mbit being received (thus the TX queue fills up.) * .. with CCMP / WPA2 encryption configured * .. and the group rekey time set to 10 seconds, just to elicit the behaviour very quickly. PR: kern/138379
2013-05-07 07:52:18 +00:00
*/
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
TAILQ_FOREACH(n_fbf, &frags, bf_list) {
fbf->bf_nextfraglen = fm->m_pkthdr.len;
fbf = n_fbf;
fm = fm->m_nextpkt;
Pull out the if_transmit() work and revert back to ath_start(). My changed had some rather significant behavioural changes to throughput. The two issues I noticed: * With if_start and the ifnet mbuf queue, any temporary latency would get eaten up by some mbufs being queued. With ath_transmit() queuing things to ath_buf's, I'd only get 512 TX buffers before I couldn't queue any further frames. * There's also some non-zero latency involved with TX being pushed into a taskqueue via direct dispatch. Any time the scheduler didn't immediately schedule the ath TX task would cause extra latency. Various 1ge/10ge drivers implement both direct dispatch (if the TX lock can be acquired) and deferred task transmission (if the TX lock can't be acquired), with frames being pushed into a drbd queue. I'll have to do this at some point, but until I figure out how to deal with 802.11 fragments, I'll have to wait a while longer. So what I saw: * lots of extra latency, specially under load - if the taskqueue wasn't immediately scheduled, things went pear shaped; * any extra latency would result in TX ath_buf's taking their sweet time being replenished, so any further calls to ath_transmit() would drop mbufs. * .. yes, there's no explicit backpressure here - things are just dropped. Eek. With this, the general performance has gone up, but those subtle if_start() related race conditions are back. For some reason, this is doubly-obvious with the AR5416 NIC and I don't quite understand why yet. There's an unrelated issue with AR5416 performance in STA mode (it's fine in AP mode when bridging frames, weirdly..) that requires a little further investigation. Specifically - it works fine on a Lenovo T40 (single core CPU) running a March 2012 9-STABLE kernel, but a Lenovo T60 (dual core) running an early November 2012 kernel behaves very poorly. The same hardware with an AR9160 or AR9280 behaves perfectly.
2013-02-13 05:32:19 +00:00
}
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
}
Re-work how transmit buffer limits are enforced - partly to fix the PR, but partly to just tidy up things. The problem here - there are too many TX buffers in the queue! By the time one needs to transmit an EAPOL frame (for this PR, it's the response to the group rekey notification from the AP) there are no ath_buf entries free and the EAPOL frame doesn't go out. Now, the problem! * Enforcing the TX buffer limitation _before_ we dequeue the frame? Bad idea. Because.. * .. it means I can't check whether the mbuf has M_EAPOL set. The solution(s): * De-queue the frame first * Don't bother doing the TX buffer minimum free check until after we know whether it's an EAPOL frame or not. * If it's an EAPOL frame, allocate the buffer from the mgmt pool rather than the default pool. Whilst I'm here: * Add a tweak to limit how many buffers a single node can acquire. * Don't enforce that for EAPOL frames. * .. set that to default to 1/4 of the available buffers, or 32, whichever is more sane. This doesn't fix issues due to a sleeping node or a very poor performing node; but this doesn't make it worse. Tested: * AR5416 STA, TX'ing 100+ mbit UDP to an AP, but only 50mbit being received (thus the TX queue fills up.) * .. with CCMP / WPA2 encryption configured * .. and the group rekey time set to 10 seconds, just to elicit the behaviour very quickly. PR: kern/138379
2013-05-07 07:52:18 +00:00
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
nextfrag:
/*
* Pass the frame to the h/w for transmission.
* Fragmented frames have each frag chained together
* with m_nextpkt. We know there are sufficient ath_buf's
* to send all the frags because of work done by
* ath_txfrag_setup. We leave m_nextpkt set while
* calling ath_tx_start so it can use it to extend the
* the tx duration to cover the subsequent frag and
* so it can reclaim all the mbufs in case of an error;
* ath_tx_start clears m_nextpkt once it commits to
* handing the frame to the hardware.
*
* Note: if this fails, then the mbufs are freed but
* not the node reference.
ath(4) - don't try to free buffers / return an error if we've committed to transmit the buffer. ath_tx_start() may manipulate/reallocate the mbuf as part of the DMA code, so we can't expect the mbuf can be returned back to the caller. Now, the net80211 ifnet work changed the semantics slightly so if an error is returned here, the mbuf/reference is freed by the caller (here, it's net80211.) So, once we reach ath_tx_start(), we never return failure. If we fail then we still return OK and we free the mbuf/noderef ourselves, and we increment OERRORS.
2015-11-03 21:11:30 +00:00
*
* So, we now have to free the node reference ourselves here
* and return OK up to the stack.
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
*/
next = m->m_nextpkt;
if (ath_tx_start(sc, ni, bf, m)) {
bad:
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
if_inc_counter(ni->ni_vap->iv_ifp, IFCOUNTER_OERRORS, 1);
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
reclaim:
bf->bf_m = NULL;
bf->bf_node = NULL;
ATH_TXBUF_LOCK(sc);
ath_returnbuf_head(sc, bf);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
/*
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
* Free the rest of the node references and
* buffers for the fragment list.
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
*/
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
ath_txfrag_cleanup(sc, &frags, ni);
ATH_TXBUF_UNLOCK(sc);
ath(4) - don't try to free buffers / return an error if we've committed to transmit the buffer. ath_tx_start() may manipulate/reallocate the mbuf as part of the DMA code, so we can't expect the mbuf can be returned back to the caller. Now, the net80211 ifnet work changed the semantics slightly so if an error is returned here, the mbuf/reference is freed by the caller (here, it's net80211.) So, once we reach ath_tx_start(), we never return failure. If we fail then we still return OK and we free the mbuf/noderef ourselves, and we increment OERRORS.
2015-11-03 21:11:30 +00:00
/*
* XXX: And free the node/return OK; ath_tx_start() may have
* modified the buffer. We currently have no way to
* signify that the mbuf was freed but there was an error.
*/
ieee80211_free_node(ni);
retval = 0;
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
goto finish;
}
Re-work how transmit buffer limits are enforced - partly to fix the PR, but partly to just tidy up things. The problem here - there are too many TX buffers in the queue! By the time one needs to transmit an EAPOL frame (for this PR, it's the response to the group rekey notification from the AP) there are no ath_buf entries free and the EAPOL frame doesn't go out. Now, the problem! * Enforcing the TX buffer limitation _before_ we dequeue the frame? Bad idea. Because.. * .. it means I can't check whether the mbuf has M_EAPOL set. The solution(s): * De-queue the frame first * Don't bother doing the TX buffer minimum free check until after we know whether it's an EAPOL frame or not. * If it's an EAPOL frame, allocate the buffer from the mgmt pool rather than the default pool. Whilst I'm here: * Add a tweak to limit how many buffers a single node can acquire. * Don't enforce that for EAPOL frames. * .. set that to default to 1/4 of the available buffers, or 32, whichever is more sane. This doesn't fix issues due to a sleeping node or a very poor performing node; but this doesn't make it worse. Tested: * AR5416 STA, TX'ing 100+ mbit UDP to an AP, but only 50mbit being received (thus the TX queue fills up.) * .. with CCMP / WPA2 encryption configured * .. and the group rekey time set to 10 seconds, just to elicit the behaviour very quickly. PR: kern/138379
2013-05-07 07:52:18 +00:00
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
/*
* Check here if the node is in power save state.
*/
ath_tx_update_tim(sc, ni, 1);
Re-work how transmit buffer limits are enforced - partly to fix the PR, but partly to just tidy up things. The problem here - there are too many TX buffers in the queue! By the time one needs to transmit an EAPOL frame (for this PR, it's the response to the group rekey notification from the AP) there are no ath_buf entries free and the EAPOL frame doesn't go out. Now, the problem! * Enforcing the TX buffer limitation _before_ we dequeue the frame? Bad idea. Because.. * .. it means I can't check whether the mbuf has M_EAPOL set. The solution(s): * De-queue the frame first * Don't bother doing the TX buffer minimum free check until after we know whether it's an EAPOL frame or not. * If it's an EAPOL frame, allocate the buffer from the mgmt pool rather than the default pool. Whilst I'm here: * Add a tweak to limit how many buffers a single node can acquire. * Don't enforce that for EAPOL frames. * .. set that to default to 1/4 of the available buffers, or 32, whichever is more sane. This doesn't fix issues due to a sleeping node or a very poor performing node; but this doesn't make it worse. Tested: * AR5416 STA, TX'ing 100+ mbit UDP to an AP, but only 50mbit being received (thus the TX queue fills up.) * .. with CCMP / WPA2 encryption configured * .. and the group rekey time set to 10 seconds, just to elicit the behaviour very quickly. PR: kern/138379
2013-05-07 07:52:18 +00:00
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
if (next != NULL) {
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
/*
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
* Beware of state changing between frags.
* XXX check sta power-save state?
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
*/
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
if (ni->ni_vap->iv_state != IEEE80211_S_RUN) {
Pull out the if_transmit() work and revert back to ath_start(). My changed had some rather significant behavioural changes to throughput. The two issues I noticed: * With if_start and the ifnet mbuf queue, any temporary latency would get eaten up by some mbufs being queued. With ath_transmit() queuing things to ath_buf's, I'd only get 512 TX buffers before I couldn't queue any further frames. * There's also some non-zero latency involved with TX being pushed into a taskqueue via direct dispatch. Any time the scheduler didn't immediately schedule the ath TX task would cause extra latency. Various 1ge/10ge drivers implement both direct dispatch (if the TX lock can be acquired) and deferred task transmission (if the TX lock can't be acquired), with frames being pushed into a drbd queue. I'll have to do this at some point, but until I figure out how to deal with 802.11 fragments, I'll have to wait a while longer. So what I saw: * lots of extra latency, specially under load - if the taskqueue wasn't immediately scheduled, things went pear shaped; * any extra latency would result in TX ath_buf's taking their sweet time being replenished, so any further calls to ath_transmit() would drop mbufs. * .. yes, there's no explicit backpressure here - things are just dropped. Eek. With this, the general performance has gone up, but those subtle if_start() related race conditions are back. For some reason, this is doubly-obvious with the AR5416 NIC and I don't quite understand why yet. There's an unrelated issue with AR5416 performance in STA mode (it's fine in AP mode when bridging frames, weirdly..) that requires a little further investigation. Specifically - it works fine on a Lenovo T40 (single core CPU) running a March 2012 9-STABLE kernel, but a Lenovo T60 (dual core) running an early November 2012 kernel behaves very poorly. The same hardware with an AR9160 or AR9280 behaves perfectly.
2013-02-13 05:32:19 +00:00
DPRINTF(sc, ATH_DEBUG_XMIT,
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
"%s: flush fragmented packet, state %s\n",
__func__,
ieee80211_state_name[ni->ni_vap->iv_state]);
/* XXX dmamap */
net80211: separate mbuf cleanup from ieee80211_fragment() * Create ieee80211_free_mbuf() which frees a list of mbufs. * Use it in the fragment transmit path and ath / uath transmit paths. * Call it in xmit_pkt() if the transmission fails; otherwise fragments may be leaked. This should be a big no-op. Submitted by: <s3erios@gmail.com> Differential Revision: https://reviews.freebsd.org/D3769
2015-10-12 03:27:08 +00:00
ieee80211_free_mbuf(next);
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
goto reclaim;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
m = next;
bf = TAILQ_FIRST(&frags);
KASSERT(bf != NULL, ("no buf for txfrag"));
TAILQ_REMOVE(&frags, bf, bf_list);
goto nextfrag;
}
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
/*
* Bump watchdog timer.
*/
sc->sc_wd_timer = 5;
Implement frame (data) transmission using if_transmit(), rather than if_start(). This removes the overlapping data path TX from occuring, which solves quite a number of the potential TX queue races in ath(4). It doesn't fix the net80211 layer TX queue races and it doesn't fix the raw TX path yet, but it's an important step towards this. This hasn't dropped the TX performance in my testing; primarily because now the TX path can quickly queue frames and continue along processing. This involves a few rather deep changes: * Use the ath_buf as a queue placeholder for now, as we need to be able to support queuing a list of mbufs (ie, when transmitting fragments) and m_nextpkt can't be used here (because it's what is joining the fragments together) * if_transmit() now simply allocates the ath_buf and queues it to a driver TX staging queue. * TX is now moved into a taskqueue function. * The TX taskqueue function now dequeues and transmits frames. * Fragments are handled correctly here - as the current API passes the fragment list as one mbuf list (joined with m_nextpkt) through to the driver if_transmit(). * For the couple of places where ath_start() may be called (mostly from net80211 when starting the VAP up again), just reimplement it using the new enqueue and taskqueue methods. What I don't like (about this work and the TX code in general): * I'm using the same lock for the staging TX queue management and the actual TX. This isn't required; I'm just being slack. * I haven't yet moved TX to a separate taskqueue (but the taskqueue is created); it's easy enough to do this later if necessary. I just need to make sure it's a higher priority queue, so TX has the same behaviour as it used to (where it would preempt existing RX..) * I need to re-review the TX path a little more and make sure that ieee80211_node_*() functions aren't called within the TX lock. When queueing, I should just push failed frames into a queue and when I'm wrapping up the TX code, unlock the TX lock and call ieee80211_node_free() on each. * It would be nice if I could hold the TX lock for the entire TX and TX completion, rather than this release/re-acquire behaviour. But that requires that I shuffle around the TX completion code to handle actual ath_buf free and net80211 callback/free outside of the TX lock. That's one of my next projects. * the ic_raw_xmit() path doesn't use this yet - so it still has sequencing problems with parallel, overlapping calls to the data path. I'll fix this later. Tested: * Hostap - AR9280, AR9220 * STA - AR5212, AR9280, AR5416
2013-01-15 18:01:23 +00:00
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
finish:
ATH_TX_UNLOCK(sc);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
/*
* Finished transmitting!
*/
ATH_PCU_LOCK(sc);
sc->sc_txstart_cnt--;
ATH_PCU_UNLOCK(sc);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
/* Sleep the hardware if required */
ATH_LOCK(sc);
ath_power_restore_power_state(sc);
ATH_UNLOCK(sc);
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
ATH_KTR(sc, ATH_KTR_TX, 0, "ath_transmit: finished");
return (retval);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
2013-05-26 22:23:39 +00:00
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
static int
ath_media_change(struct ifnet *ifp)
{
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
int error = ieee80211_media_change(ifp);
/* NB: only the fixed rate can change and that doesn't need a reset */
return (error == ENETRESET ? 0 : error);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
Update with last year of work.
2004-12-08 17:34:36 +00:00
/*
* Block/unblock tx+rx processing while a key change is done.
* We assume the caller serializes key management operations
* so we only need to worry about synchronization with other
* uses that originate in the driver.
*/
static void
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
ath_key_update_begin(struct ieee80211vap *vap)
Update with last year of work.
2004-12-08 17:34:36 +00:00
{
Remove most of the references of ifp->if_softc and replace with references to ic->ic_softc. This is in preparation for gleb's ifnet work. Tested: * ath(4), STA mode * ath(4), hostap mode * make universe
2015-08-17 02:04:11 +00:00
struct ath_softc *sc = vap->iv_ic->ic_softc;
Update with last year of work.
2004-12-08 17:34:36 +00:00
DPRINTF(sc, ATH_DEBUG_KEYCACHE, "%s:\n", __func__);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
taskqueue_block(sc->sc_tq);
Update with last year of work.
2004-12-08 17:34:36 +00:00
}
static void
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
ath_key_update_end(struct ieee80211vap *vap)
Update with last year of work.
2004-12-08 17:34:36 +00:00
{
Remove most of the references of ifp->if_softc and replace with references to ic->ic_softc. This is in preparation for gleb's ifnet work. Tested: * ath(4), STA mode * ath(4), hostap mode * make universe
2015-08-17 02:04:11 +00:00
struct ath_softc *sc = vap->iv_ic->ic_softc;
Update with last year of work.
2004-12-08 17:34:36 +00:00
DPRINTF(sc, ATH_DEBUG_KEYCACHE, "%s:\n", __func__);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
taskqueue_unblock(sc->sc_tq);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
o consolidate rx filter calculations in one place o enable beacon reception when operating in adhoc mode so the 802.11 layer can use them to create nodes for peers
2003-10-17 21:58:39 +00:00
static void
Change three methods in struct ieee80211com, namely ic_updateslot, ic_update_mcast and ic_update_promisc, to pass pointer to the ieee80211com, not to the ifnet. Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-05-25 19:53:29 +00:00
ath_update_promisc(struct ieee80211com *ic)
o consolidate rx filter calculations in one place o enable beacon reception when operating in adhoc mode so the 802.11 layer can use them to create nodes for peers
2003-10-17 21:58:39 +00:00
{
Change three methods in struct ieee80211com, namely ic_updateslot, ic_update_mcast and ic_update_promisc, to pass pointer to the ieee80211com, not to the ifnet. Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-05-25 19:53:29 +00:00
struct ath_softc *sc = ic->ic_softc;
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
u_int32_t rfilt;
o consolidate rx filter calculations in one place o enable beacon reception when operating in adhoc mode so the 802.11 layer can use them to create nodes for peers
2003-10-17 21:58:39 +00:00
/* configure rx filter */
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ATH_LOCK(sc);
ath_power_set_power_state(sc, HAL_PM_AWAKE);
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
rfilt = ath_calcrxfilter(sc);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
ath_hal_setrxfilter(sc->sc_ah, rfilt);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ath_power_restore_power_state(sc);
ATH_UNLOCK(sc);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
DPRINTF(sc, ATH_DEBUG_MODE, "%s: RX filter 0x%x\n", __func__, rfilt);
}
Update with last year of work.
2004-12-08 17:34:36 +00:00
Convert to if_foreach_llmaddr() KPI.
2019-10-21 18:06:15 +00:00
static u_int
ath_hash_maddr(void *arg, struct sockaddr_dl *sdl, u_int cnt)
{
uint32_t val, *mfilt = arg;
char *dl;
uint8_t pos;
/* calculate XOR of eight 6bit values */
dl = LLADDR(sdl);
val = le32dec(dl + 0);
pos = (val >> 18) ^ (val >> 12) ^ (val >> 6) ^ val;
val = le32dec(dl + 3);
pos ^= (val >> 18) ^ (val >> 12) ^ (val >> 6) ^ val;
pos &= 0x3f;
mfilt[pos / 32] |= (1 << (pos % 32));
return (1);
}
Break out the multicast programming into its own hardware specific call, which assumes the hardware is awake. Turn ath_update_mcast() into a routine that's only called from the net80211 layer - and it forces the hardware awake first. This fixes a LOR from the EDMA RX path which calls ath_mode_init() with the RX lock held - the driver lock can't also be grabbed. This path assumes that the ath_mode_init() callers all wake up the NIC first. Tested: * AR9485, STA mode, powersave
2014-05-05 08:12:21 +00:00
/*
* Driver-internal mcast update call.
*
* Assumes the hardware is already awake.
*/
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
static void
Break out the multicast programming into its own hardware specific call, which assumes the hardware is awake. Turn ath_update_mcast() into a routine that's only called from the net80211 layer - and it forces the hardware awake first. This fixes a LOR from the EDMA RX path which calls ath_mode_init() with the RX lock held - the driver lock can't also be grabbed. This path assumes that the ath_mode_init() callers all wake up the NIC first. Tested: * AR9485, STA mode, powersave
2014-05-05 08:12:21 +00:00
ath_update_mcast_hw(struct ath_softc *sc)
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
{
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
struct ieee80211com *ic = &sc->sc_ic;
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
u_int32_t mfilt[2];
o consolidate rx filter calculations in one place o enable beacon reception when operating in adhoc mode so the 802.11 layer can use them to create nodes for peers
2003-10-17 21:58:39 +00:00
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
/* calculate and install multicast filter */
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
if (ic->ic_allmulti == 0) {
struct ieee80211vap *vap;
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
/*
* Merge multicast addresses to form the hardware filter.
*/
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
mfilt[0] = mfilt[1] = 0;
Convert to if_foreach_llmaddr() KPI.
2019-10-21 18:06:15 +00:00
TAILQ_FOREACH(vap, &ic->ic_vaps, iv_next)
if_foreach_llmaddr(vap->iv_ifp, ath_hash_maddr, &mfilt);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
} else
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
mfilt[0] = mfilt[1] = ~0;
Break out the multicast programming into its own hardware specific call, which assumes the hardware is awake. Turn ath_update_mcast() into a routine that's only called from the net80211 layer - and it forces the hardware awake first. This fixes a LOR from the EDMA RX path which calls ath_mode_init() with the RX lock held - the driver lock can't also be grabbed. This path assumes that the ath_mode_init() callers all wake up the NIC first. Tested: * AR9485, STA mode, powersave
2014-05-05 08:12:21 +00:00
ath_hal_setmcastfilter(sc->sc_ah, mfilt[0], mfilt[1]);
DPRINTF(sc, ATH_DEBUG_MODE, "%s: MC filter %08x:%08x\n",
__func__, mfilt[0], mfilt[1]);
}
/*
* Called from the net80211 layer - force the hardware
* awake before operating.
*/
static void
Change three methods in struct ieee80211com, namely ic_updateslot, ic_update_mcast and ic_update_promisc, to pass pointer to the ieee80211com, not to the ifnet. Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-05-25 19:53:29 +00:00
ath_update_mcast(struct ieee80211com *ic)
Break out the multicast programming into its own hardware specific call, which assumes the hardware is awake. Turn ath_update_mcast() into a routine that's only called from the net80211 layer - and it forces the hardware awake first. This fixes a LOR from the EDMA RX path which calls ath_mode_init() with the RX lock held - the driver lock can't also be grabbed. This path assumes that the ath_mode_init() callers all wake up the NIC first. Tested: * AR9485, STA mode, powersave
2014-05-05 08:12:21 +00:00
{
Change three methods in struct ieee80211com, namely ic_updateslot, ic_update_mcast and ic_update_promisc, to pass pointer to the ieee80211com, not to the ifnet. Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-05-25 19:53:29 +00:00
struct ath_softc *sc = ic->ic_softc;
Break out the multicast programming into its own hardware specific call, which assumes the hardware is awake. Turn ath_update_mcast() into a routine that's only called from the net80211 layer - and it forces the hardware awake first. This fixes a LOR from the EDMA RX path which calls ath_mode_init() with the RX lock held - the driver lock can't also be grabbed. This path assumes that the ath_mode_init() callers all wake up the NIC first. Tested: * AR9485, STA mode, powersave
2014-05-05 08:12:21 +00:00
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ATH_LOCK(sc);
ath_power_set_power_state(sc, HAL_PM_AWAKE);
Break out the multicast programming into its own hardware specific call, which assumes the hardware is awake. Turn ath_update_mcast() into a routine that's only called from the net80211 layer - and it forces the hardware awake first. This fixes a LOR from the EDMA RX path which calls ath_mode_init() with the RX lock held - the driver lock can't also be grabbed. This path assumes that the ath_mode_init() callers all wake up the NIC first. Tested: * AR9485, STA mode, powersave
2014-05-05 08:12:21 +00:00
ATH_UNLOCK(sc);
ath_update_mcast_hw(sc);
ATH_LOCK(sc);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ath_power_restore_power_state(sc);
ATH_UNLOCK(sc);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
}
Migrate the bulk of the RX routines out from if_ath.c to if_ath_rx.[ch]. * migrate the rx processing out into if_ath_rx.c * migrate the TSF functions into if_ath_tsf.h, as inlines This is in prepration for supporting the EDMA RX routines, required to support the AR93xx series NICs. TODO: * ath_start() shouldn't be private, but it's called as part of the RX path. I should likely migrate ath_rx_tasklet() back into if_ath.c and then return this to be 'static'. The RX code really shouldn't need to see TX routines (and vice versa.) * ath_beacon_* should be in if_ath_beacon.[ch]. * ath_tdma_* should be in if_ath_tdma.[ch] ...
2012-05-20 02:05:10 +00:00
void
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
ath_mode_init(struct ath_softc *sc)
{
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
struct ieee80211com *ic = &sc->sc_ic;
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
struct ath_hal *ah = sc->sc_ah;
u_int32_t rfilt;
[ath] fix "doing stuff before wakeup" warning; add comments for ACK/CTS handling during DFS/PASSIVE channels * Although the hardware is awake, the power state handling doesn't think so. So just explicitly wake it up early in setup so ath_hal calls don't complain. * We shouldn't be transmitting or ACKing frames during DFS CAC or on passive channels before we hear a beacon. So, start laying down comments in the places where this work has to be done. Note: * The main bit missing from finishing this particular bit of work is a state call to transition a VAP from passive to non-passive when a beacon is heard. CAC is easy, it's an interface state. So, I'll go and add a method to control that soon.
2017-01-27 01:17:00 +00:00
/* XXX power state? */
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
/* configure rx filter */
rfilt = ath_calcrxfilter(sc);
ath_hal_setrxfilter(ah, rfilt);
/* configure operational mode */
ath_hal_setopmode(ah);
Eliminate ic_myaddr so changing the mac address of a device works correctly: o remove ic_myaddr from ieee80211com o change ieee80211_ifattach to take the mac address of the physical device and use that to setup the lladdr. o replace all references to ic_myaddr in drivers by IF_LLADDR o related cleanups (e.g. kill dead code) PR: kern/133178 Reviewed by: thompsa, rpaulo
2009-03-29 17:59:14 +00:00
/* handle any link-level address change */
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
ath_hal_setmac(ah, ic->ic_macaddr);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
/* calculate and install multicast filter */
Break out the multicast programming into its own hardware specific call, which assumes the hardware is awake. Turn ath_update_mcast() into a routine that's only called from the net80211 layer - and it forces the hardware awake first. This fixes a LOR from the EDMA RX path which calls ath_mode_init() with the RX lock held - the driver lock can't also be grabbed. This path assumes that the ath_mode_init() callers all wake up the NIC first. Tested: * AR9485, STA mode, powersave
2014-05-05 08:12:21 +00:00
ath_update_mcast_hw(sc);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
Update with last year of work.
2004-12-08 17:34:36 +00:00
/*
* Set the slot time based on the current setting.
*/
Migrate most of the beacon handling functions out to if_ath_beacon.c. This is also in preparation for supporting AR9300 and later NICs.
2012-05-20 04:14:29 +00:00
void
Update with last year of work.
2004-12-08 17:34:36 +00:00
ath_setslottime(struct ath_softc *sc)
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
{
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
struct ieee80211com *ic = &sc->sc_ic;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
struct ath_hal *ah = sc->sc_ah;
Add half/quarter rate 11a channel support: o change handling of regdomain-related mib knobs so they can be set post-attach: regdomain, countrycode, outdoor, and xchanmode; the hal will not permit changing the regdomain but we expose it for now o on regdomain/countrycode change recalculate the channel list and push it to the net80211 layer (NB: looks to need more tweaking) o setup rate tables for half/quarter rate channels o honor half/quarter rate channel configs when changing channels o honor half/quarter rate channel configs when setting the slot time o use hack/nonstandard channel numbering scheme for the public safety band to avoid overlapping 2.4G channels on dual-band cards o remove setup of ic_sup_rates; the net80211 layer can do this for us and it simplifies handling of half/quarter rate channels Tested only in Public Safety Band with cards that have RF5112.
2006-12-27 19:07:09 +00:00
u_int usec;
Update with last year of work.
2004-12-08 17:34:36 +00:00
Add initial support for 900MHz cards like the Ubiquiti SR9: o eliminate assumptions that half/quarter rate channels on exist in 11a o handle frequency mapping between hal and net80211; hal gives us freq's in the range 2422..2437 that we remap MFC after: 1 month
2007-01-15 01:15:57 +00:00
if (IEEE80211_IS_CHAN_HALF(ic->ic_curchan))
usec = 13;
else if (IEEE80211_IS_CHAN_QUARTER(ic->ic_curchan))
usec = 21;
else if (IEEE80211_IS_CHAN_ANYG(ic->ic_curchan)) {
/* honor short/long slot time only in 11g */
/* XXX shouldn't honor on pure g or turbo g channel */
if (ic->ic_flags & IEEE80211_F_SHSLOT)
Add half/quarter rate 11a channel support: o change handling of regdomain-related mib knobs so they can be set post-attach: regdomain, countrycode, outdoor, and xchanmode; the hal will not permit changing the regdomain but we expose it for now o on regdomain/countrycode change recalculate the channel list and push it to the net80211 layer (NB: looks to need more tweaking) o setup rate tables for half/quarter rate channels o honor half/quarter rate channel configs when changing channels o honor half/quarter rate channel configs when setting the slot time o use hack/nonstandard channel numbering scheme for the public safety band to avoid overlapping 2.4G channels on dual-band cards o remove setup of ic_sup_rates; the net80211 layer can do this for us and it simplifies handling of half/quarter rate channels Tested only in Public Safety Band with cards that have RF5112.
2006-12-27 19:07:09 +00:00
usec = HAL_SLOT_TIME_9;
Add initial support for 900MHz cards like the Ubiquiti SR9: o eliminate assumptions that half/quarter rate channels on exist in 11a o handle frequency mapping between hal and net80211; hal gives us freq's in the range 2422..2437 that we remap MFC after: 1 month
2007-01-15 01:15:57 +00:00
else
usec = HAL_SLOT_TIME_20;
} else
Add half/quarter rate 11a channel support: o change handling of regdomain-related mib knobs so they can be set post-attach: regdomain, countrycode, outdoor, and xchanmode; the hal will not permit changing the regdomain but we expose it for now o on regdomain/countrycode change recalculate the channel list and push it to the net80211 layer (NB: looks to need more tweaking) o setup rate tables for half/quarter rate channels o honor half/quarter rate channel configs when changing channels o honor half/quarter rate channel configs when setting the slot time o use hack/nonstandard channel numbering scheme for the public safety band to avoid overlapping 2.4G channels on dual-band cards o remove setup of ic_sup_rates; the net80211 layer can do this for us and it simplifies handling of half/quarter rate channels Tested only in Public Safety Band with cards that have RF5112.
2006-12-27 19:07:09 +00:00
usec = HAL_SLOT_TIME_9;
DPRINTF(sc, ATH_DEBUG_RESET,
"%s: chan %u MHz flags 0x%x %s slot, %u usec\n",
__func__, ic->ic_curchan->ic_freq, ic->ic_curchan->ic_flags,
ic->ic_flags & IEEE80211_F_SHSLOT ? "short" : "long", usec);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
/* Wake up the hardware first before updating the slot time */
ATH_LOCK(sc);
ath_power_set_power_state(sc, HAL_PM_AWAKE);
Add half/quarter rate 11a channel support: o change handling of regdomain-related mib knobs so they can be set post-attach: regdomain, countrycode, outdoor, and xchanmode; the hal will not permit changing the regdomain but we expose it for now o on regdomain/countrycode change recalculate the channel list and push it to the net80211 layer (NB: looks to need more tweaking) o setup rate tables for half/quarter rate channels o honor half/quarter rate channel configs when changing channels o honor half/quarter rate channel configs when setting the slot time o use hack/nonstandard channel numbering scheme for the public safety band to avoid overlapping 2.4G channels on dual-band cards o remove setup of ic_sup_rates; the net80211 layer can do this for us and it simplifies handling of half/quarter rate channels Tested only in Public Safety Band with cards that have RF5112.
2006-12-27 19:07:09 +00:00
ath_hal_setslottime(ah, usec);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ath_power_restore_power_state(sc);
Update with last year of work.
2004-12-08 17:34:36 +00:00
sc->sc_updateslot = OK;
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ATH_UNLOCK(sc);
Update with last year of work.
2004-12-08 17:34:36 +00:00
}
/*
* Callback from the 802.11 layer to update the
* slot time based on the current setting.
*/
static void
Change three methods in struct ieee80211com, namely ic_updateslot, ic_update_mcast and ic_update_promisc, to pass pointer to the ieee80211com, not to the ifnet. Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-05-25 19:53:29 +00:00
ath_updateslot(struct ieee80211com *ic)
Update with last year of work.
2004-12-08 17:34:36 +00:00
{
Change three methods in struct ieee80211com, namely ic_updateslot, ic_update_mcast and ic_update_promisc, to pass pointer to the ieee80211com, not to the ifnet. Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-05-25 19:53:29 +00:00
struct ath_softc *sc = ic->ic_softc;
Update with last year of work.
2004-12-08 17:34:36 +00:00
/*
* When not coordinating the BSS, change the hardware
* immediately. For other operation we defer the change
* until beacon updates have propagated to the stations.
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
*
* XXX sc_updateslot isn't changed behind a lock?
Update with last year of work.
2004-12-08 17:34:36 +00:00
*/
Implementation of the upcoming Wireless Mesh standard, 802.11s, on the net80211 wireless stack. This work is based on the March 2009 D3.0 draft standard. This standard is expected to become final next year. This includes two main net80211 modules, ieee80211_mesh.c which deals with peer link management, link metric calculation, routing table control and mesh configuration and ieee80211_hwmp.c which deals with the actually routing process on the mesh network. HWMP is the mandatory routing protocol on by the mesh standard, but others, such as RA-OLSR, can be implemented. Authentication and encryption are not implemented. There are several scripts under tools/tools/net80211/scripts that can be used to test different mesh network topologies and they also teach you how to setup a mesh vap (for the impatient: ifconfig wlan0 create wlandev ... wlanmode mesh). A new build option is available: IEEE80211_SUPPORT_MESH and it's enabled by default on GENERIC kernels for i386, amd64, sparc64 and pc98. Drivers that support mesh networks right now are: ath, ral and mwl. More information at: http://wiki.freebsd.org/WifiMesh Please note that this work is experimental. Also, please note that bridging a mesh vap with another network interface is not yet supported. Many thanks to the FreeBSD Foundation for sponsoring this project and to Sam Leffler for his support. Also, I would like to thank Gateworks Corporation for sending me a Cambria board which was used during the development of this project. Reviewed by: sam Approved by: re (kensmith) Obtained from: projects/mesh11s
2009-07-11 15:02:45 +00:00
if (ic->ic_opmode == IEEE80211_M_HOSTAP ||
ic->ic_opmode == IEEE80211_M_MBSS)
Update with last year of work.
2004-12-08 17:34:36 +00:00
sc->sc_updateslot = UPDATE;
else
ath_setslottime(sc);
}
Close race in handling mcast traffic when operating as an ap with stations in power save: add a new q where mcast frames are stashed and on beacon update (at DTIM) move frames from the mcast q to the cabq and start it. This ensures the cabq is only manipulated in one place. Sponsored by: Hobnob MFC after: 2 weeks
2006-06-26 03:10:45 +00:00
/*
* Append the contents of src to dst; both queues
* are assumed to be locked.
*/
Migrate most of the beacon handling functions out to if_ath_beacon.c. This is also in preparation for supporting AR9300 and later NICs.
2012-05-20 04:14:29 +00:00
void
Close race in handling mcast traffic when operating as an ap with stations in power save: add a new q where mcast frames are stashed and on beacon update (at DTIM) move frames from the mcast q to the cabq and start it. This ensures the cabq is only manipulated in one place. Sponsored by: Hobnob MFC after: 2 weeks
2006-06-26 03:10:45 +00:00
ath_txqmove(struct ath_txq *dst, struct ath_txq *src)
{
Insert extra paranoia into the ath(4) driver. This function must be called with both the source and destination TXQs locked or things will get hairy. I added this as part of some debugging in a PR but it turned out to not be the cause. I still think it's -correct- so, here it is.
2012-03-09 08:36:30 +00:00
Overhaul the TXQ locking (again!) as part of some beacon/cabq timing related issues. Moving the TX locking under one lock made things easier to progress on but it had one important side-effect - it increased the latency when handling CABQ setup when sending beacons. This commit introduces a bunch of new changes and a few unrelated changs that are just easier to lump in here. The aim is to have the CABQ locking separate from other locking. The CABQ transmit path in the beacon process thus doesn't have to grab the general TX lock, reducing lock contention/latency and making it more likely that we'll make the beacon TX timing. The second half of this commit is the CABQ related setup changes needed for sane looking EDMA CABQ support. Right now the EDMA TX code naively assumes that only one frame (MPDU or A-MPDU) is being pushed into each FIFO slot. For the CABQ this isn't true - a whole list of frames is being pushed in - and thus CABQ handling breaks very quickly. The aim here is to setup the CABQ list and then push _that list_ to the hardware for transmission. I can then extend the EDMA TX code to stamp that list as being "one" FIFO entry (likely by tagging the last buffer in that list as "FIFO END") so the EDMA TX completion code correctly tracks things. Major: * Migrate the per-TXQ add/removal locking back to per-TXQ, rather than a single lock. * Leave the software queue side of things under the ATH_TX_LOCK lock, (continuing) to serialise things as they are. * Add a new function which is called whenever there's a beacon miss, to print out some debugging. This is primarily designed to help me figure out if the beacon miss events are due to a noisy environment, issues with the PHY/MAC, or other. * Move the CABQ setup/enable to occur _after_ all the VAPs have been looked at. This means that for multiple VAPS in bursted mode, the CABQ gets primed once all VAPs are checked, rather than being primed on the first VAP and then having frames appended after this. Minor: * Add a (disabled) twiddle to let me enable/disable cabq traffic. It's primarily there to let me easily debug what's going on with beacon and CABQ setup/traffic; there's some DMA engine hangs which I'm finally trying to trace down. * Clear bf_next when flushing frames; it should quieten some warnings that show up when a node goes away. Tested: * AR9280, STA/hostap, up to 4 vaps (staggered) * AR5416, STA/hostap, up to 4 vaps (staggered) TODO: * (Lots) more AR9380 and later testing, as I may have missed something here. * Leverage this to fix CABQ hanling for AR9380 and later chips. * Force bursted beaconing on the chips that default to staggered beacons and ensure the CABQ stuff is all sane (eg, the MORE bits that aren't being correctly set when chaining descriptors.)
2013-03-24 00:03:12 +00:00
ATH_TXQ_LOCK_ASSERT(src);
ATH_TXQ_LOCK_ASSERT(dst);
Migrate the STAILQ lists to TAILQs. A bunch of the 11n TX aggregation logic wants to traverse lists of buffers in various ways. In order to provide O(1) behaviour in this instance, use TAILQs. This does blow out the memory footprint and CPU cycles slightly for some of these operations. I may convert some of these back to STAILQs once the rest of the software transmit queue handling has been stabilised. Sponsored by: Hobnob, Inc.
2011-11-08 17:08:12 +00:00
TAILQ_CONCAT(&dst->axq_q, &src->axq_q, bf_list);
Close race in handling mcast traffic when operating as an ap with stations in power save: add a new q where mcast frames are stashed and on beacon update (at DTIM) move frames from the mcast q to the cabq and start it. This ensures the cabq is only manipulated in one place. Sponsored by: Hobnob MFC after: 2 weeks
2006-06-26 03:10:45 +00:00
dst->axq_link = src->axq_link;
src->axq_link = NULL;
dst->axq_depth += src->axq_depth;
Change the descriptor logic to use bf_lastds to point to the last descriptor, rather than using the maths involving bf_desc[bf_nseg - 1]. When doing TX aggregation, the status will be updated in the -final- descriptor of the -final- subframe in an aggregate. Thus bf_lastds may point to the last descriptor in a completely different ath_buf. Sponsored by: Hobnob, Inc.
2011-11-08 21:25:36 +00:00
dst->axq_aggr_depth += src->axq_aggr_depth;
Close race in handling mcast traffic when operating as an ap with stations in power save: add a new q where mcast frames are stashed and on beacon update (at DTIM) move frames from the mcast q to the cabq and start it. This ensures the cabq is only manipulated in one place. Sponsored by: Hobnob MFC after: 2 weeks
2006-06-26 03:10:45 +00:00
src->axq_depth = 0;
Change the descriptor logic to use bf_lastds to point to the last descriptor, rather than using the maths involving bf_desc[bf_nseg - 1]. When doing TX aggregation, the status will be updated in the -final- descriptor of the -final- subframe in an aggregate. Thus bf_lastds may point to the last descriptor in a completely different ath_buf. Sponsored by: Hobnob, Inc.
2011-11-08 21:25:36 +00:00
src->axq_aggr_depth = 0;
Close race in handling mcast traffic when operating as an ap with stations in power save: add a new q where mcast frames are stashed and on beacon update (at DTIM) move frames from the mcast q to the cabq and start it. This ensures the cabq is only manipulated in one place. Sponsored by: Hobnob MFC after: 2 weeks
2006-06-26 03:10:45 +00:00
}
Attempt to further fix some of the concurrency/reset issues that occur. * ath_reset() is being called in softclock context, which may have the thing sleep on a lock. To avoid this, since we really _shouldn't_ be sleeping on any locks, break out the no-loss reset path into a tasklet and call that from: + ath_calibrate() + ath_watchdog() This has the added advantage that it'll end up also doing the frame RX cleanup from within the taskqueue context, rather than the softclock context. * Shuffle around the taskqueue_block() call to be before we grab the lock and disable interrupts. The trouble here is that taskqueue_block() doesn't block currently queued (but not yet running) tasks so calling it doesn't guarantee no further tasks (that weren't running on _A_ CPU at the time of this call) will complete. Calling taskqueue_drain() on these tasks won't work because if any _other_ thread calls taskqueue_enqueue() for whatever reason, everything gets very angry and stops working. This slightly changes the race condition enough to let ath_rx_tasklet() run before we try disabling it, and thus quietens the warnings a bit. The (more) true solution will be doing something like the following: * having a taskqueue_blocked mask in ath_softc; * having an interrupt_blocked mask in ath_softc; * only calling taskqueue_drain() on each individual task _after_ the lock has been acquired - that way no further tasklet scheduling is going to occur. * Then once the tasks have been blocked _and_ the interrupt has been disabled, call taskqueue_drain() on each, ensuring that anything that _was_ scheduled or running is removed. The trouble is if something calls taskqueue_enqueue() on a task after taskqueue_blocked() has been called but BEFORE taskqueue_drain() has been called, ta_pending will be set to 1 and taskqueue_drain() will sit there stuck in msleep() until you hard-kill the machine. PR: kern/165382 PR: kern/165220
2012-02-25 19:12:54 +00:00
/*
* Reset the hardware, with no loss.
*
* This can't be used for a general case reset.
*/
static void
ath_reset_proc(void *arg, int pending)
{
struct ath_softc *sc = arg;
#if 0
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
device_printf(sc->sc_dev, "%s: resetting\n", __func__);
Attempt to further fix some of the concurrency/reset issues that occur. * ath_reset() is being called in softclock context, which may have the thing sleep on a lock. To avoid this, since we really _shouldn't_ be sleeping on any locks, break out the no-loss reset path into a tasklet and call that from: + ath_calibrate() + ath_watchdog() This has the added advantage that it'll end up also doing the frame RX cleanup from within the taskqueue context, rather than the softclock context. * Shuffle around the taskqueue_block() call to be before we grab the lock and disable interrupts. The trouble here is that taskqueue_block() doesn't block currently queued (but not yet running) tasks so calling it doesn't guarantee no further tasks (that weren't running on _A_ CPU at the time of this call) will complete. Calling taskqueue_drain() on these tasks won't work because if any _other_ thread calls taskqueue_enqueue() for whatever reason, everything gets very angry and stops working. This slightly changes the race condition enough to let ath_rx_tasklet() run before we try disabling it, and thus quietens the warnings a bit. The (more) true solution will be doing something like the following: * having a taskqueue_blocked mask in ath_softc; * having an interrupt_blocked mask in ath_softc; * only calling taskqueue_drain() on each individual task _after_ the lock has been acquired - that way no further tasklet scheduling is going to occur. * Then once the tasks have been blocked _and_ the interrupt has been disabled, call taskqueue_drain() on each, ensuring that anything that _was_ scheduled or running is removed. The trouble is if something calls taskqueue_enqueue() on a task after taskqueue_blocked() has been called but BEFORE taskqueue_drain() has been called, ta_pending will be set to 1 and taskqueue_drain() will sit there stuck in msleep() until you hard-kill the machine. PR: kern/165382 PR: kern/165220
2012-02-25 19:12:54 +00:00
#endif
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
ath_reset(sc, ATH_RESET_NOLOSS);
Attempt to further fix some of the concurrency/reset issues that occur. * ath_reset() is being called in softclock context, which may have the thing sleep on a lock. To avoid this, since we really _shouldn't_ be sleeping on any locks, break out the no-loss reset path into a tasklet and call that from: + ath_calibrate() + ath_watchdog() This has the added advantage that it'll end up also doing the frame RX cleanup from within the taskqueue context, rather than the softclock context. * Shuffle around the taskqueue_block() call to be before we grab the lock and disable interrupts. The trouble here is that taskqueue_block() doesn't block currently queued (but not yet running) tasks so calling it doesn't guarantee no further tasks (that weren't running on _A_ CPU at the time of this call) will complete. Calling taskqueue_drain() on these tasks won't work because if any _other_ thread calls taskqueue_enqueue() for whatever reason, everything gets very angry and stops working. This slightly changes the race condition enough to let ath_rx_tasklet() run before we try disabling it, and thus quietens the warnings a bit. The (more) true solution will be doing something like the following: * having a taskqueue_blocked mask in ath_softc; * having an interrupt_blocked mask in ath_softc; * only calling taskqueue_drain() on each individual task _after_ the lock has been acquired - that way no further tasklet scheduling is going to occur. * Then once the tasks have been blocked _and_ the interrupt has been disabled, call taskqueue_drain() on each, ensuring that anything that _was_ scheduled or running is removed. The trouble is if something calls taskqueue_enqueue() on a task after taskqueue_blocked() has been called but BEFORE taskqueue_drain() has been called, ta_pending will be set to 1 and taskqueue_drain() will sit there stuck in msleep() until you hard-kill the machine. PR: kern/165382 PR: kern/165220
2012-02-25 19:12:54 +00:00
}
Update with last year of work.
2004-12-08 17:34:36 +00:00
/*
* Reset the hardware after detecting beacons have stopped.
*/
static void
ath_bstuck_proc(void *arg, int pending)
{
struct ath_softc *sc = arg;
Some more various fixes, etc from my 11n branch. * When doing software TX queue handling and flush, it's possible that the deletion of a VAP (eg a STA shutdown) will queue a "STA Disassociate" frame whilst the interface is being deleted. The VAP is then deleted, and the frame ends up being queued to a node that is freed before it can be TX'ed. Things go awry at this point. There's no way at the present to avoid freeing the underlying node when the vap is being deleted. It's too late in the game. I suspect the real fix is to make sure the frame is software queued with no completion information somehow, so it doesn't link back to a node whose underlying VAP has been freed. For now, we'll just have to do this. * Add some comments showing what's going on. * Move an instance of the ATH_LOCK() around to protect the interrupt set. I'll worry about changing that to a PCU lock later on once the 11n code is in the tree. Sponsored by: Hobnob, Inc.
2011-11-08 19:18:34 +00:00
uint32_t hangs = 0;
if (ath_hal_gethangstate(sc->sc_ah, 0xff, &hangs) && hangs != 0)
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
device_printf(sc->sc_dev, "bb hang detected (0x%x)\n", hangs);
Update with last year of work.
2004-12-08 17:34:36 +00:00
Add ALQ beacon debugging.
2013-05-13 21:18:00 +00:00
#ifdef ATH_DEBUG_ALQ
if (if_ath_alq_checkdebug(&sc->sc_alq, ATH_ALQ_STUCK_BEACON))
if_ath_alq_post(&sc->sc_alq, ATH_ALQ_STUCK_BEACON, 0, NULL);
#endif
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
device_printf(sc->sc_dev, "stuck beacon; resetting (bmiss count %u)\n",
sc->sc_bmisscount);
count stuck beacon events
2009-02-07 05:34:41 +00:00
sc->sc_stats.ast_bstuck++;
Some more various fixes, etc from my 11n branch. * When doing software TX queue handling and flush, it's possible that the deletion of a VAP (eg a STA shutdown) will queue a "STA Disassociate" frame whilst the interface is being deleted. The VAP is then deleted, and the frame ends up being queued to a node that is freed before it can be TX'ed. Things go awry at this point. There's no way at the present to avoid freeing the underlying node when the vap is being deleted. It's too late in the game. I suspect the real fix is to make sure the frame is software queued with no completion information somehow, so it doesn't link back to a node whose underlying VAP has been freed. For now, we'll just have to do this. * Add some comments showing what's going on. * Move an instance of the ATH_LOCK() around to protect the interrupt set. I'll worry about changing that to a PCU lock later on once the 11n code is in the tree. Sponsored by: Hobnob, Inc.
2011-11-08 19:18:34 +00:00
/*
* This assumes that there's no simultaneous channel mode change
dev/ath: minor spelling fixes in comments. No functional change. Reviewed by: adrian
2016-05-02 19:56:48 +00:00
* occurring.
Some more various fixes, etc from my 11n branch. * When doing software TX queue handling and flush, it's possible that the deletion of a VAP (eg a STA shutdown) will queue a "STA Disassociate" frame whilst the interface is being deleted. The VAP is then deleted, and the frame ends up being queued to a node that is freed before it can be TX'ed. Things go awry at this point. There's no way at the present to avoid freeing the underlying node when the vap is being deleted. It's too late in the game. I suspect the real fix is to make sure the frame is software queued with no completion information somehow, so it doesn't link back to a node whose underlying VAP has been freed. For now, we'll just have to do this. * Add some comments showing what's going on. * Move an instance of the ATH_LOCK() around to protect the interrupt set. I'll worry about changing that to a PCU lock later on once the 11n code is in the tree. Sponsored by: Hobnob, Inc.
2011-11-08 19:18:34 +00:00
*/
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
ath_reset(sc, ATH_RESET_NOLOSS);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
}
Update with last year of work.
2004-12-08 17:34:36 +00:00
static int
ath_desc_alloc(struct ath_softc *sc)
{
int error;
error = ath_descdma_setup(sc, &sc->sc_txdma, &sc->sc_txbuf,
Use ATH_MAX_SCATTER rather than ATH_TXDESC. ATH_MAX_SCATTER is used to size the ath_buf DMA segment array. We thus should use it when checking sizes of things.
2013-04-01 20:12:21 +00:00
"tx", sc->sc_tx_desclen, ath_txbuf, ATH_MAX_SCATTER);
Update with last year of work.
2004-12-08 17:34:36 +00:00
if (error != 0) {
return error;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
Implement a global (all non-mgmt traffic) TX ath_buf limitation when ath_start() is called. This (defaults to 10 frames) gives for a little headway in the TX ath_buf allocation, so buffer cloning is still possible. This requires a lot omre experimenting and tuning. It also doesn't stop a node/TID from consuming all of the available ath_buf's, especially when the node is going through high packet loss or only talking at a low TX rate. It also doesn't stop a paused TID from taking all of the ath_bufs. I'll look at fixing that up in subsequent commits. PR: kern/168170
2012-06-14 00:51:53 +00:00
sc->sc_txbuf_cnt = ath_txbuf;
Update with last year of work.
2004-12-08 17:34:36 +00:00
Implement a separate, smaller pool of ath_buf entries for use by management traffic. * Create sc_mgmt_txbuf and sc_mgmt_txdesc, initialise/free them appropriately. * Create an enum to represent buffer types in the API. * Extend ath_getbuf() and _ath_getbuf_locked() to take the above enum. * Right now anything sent via ic_raw_xmit() allocates via ATH_BUFTYPE_MGMT. This may not be very useful. * Add ATH_BUF_MGMT flag (ath_buf.bf_flags) which indicates the current buffer is a mgmt buffer and should go back onto the mgmt free list. * Extend 'txagg' to include debugging output for both normal and mgmt txbufs. * When checking/clearing ATH_BUF_BUSY, do it on both TX pools. Tested: * STA mode, with heavy UDP injection via iperf. This filled the TX queue however BARs were still going out successfully. TODO: * Initialise the mgmt buffers with ATH_BUF_MGMT and then ensure the right type is being allocated and freed on the appropriate list. That'd save a write operation (to bf->bf_flags) on each buffer alloc/free. * Test on AP mode, ensure that BAR TX and probe responses go out nicely when the main TX queue is filled (eg with paused traffic to a TID, awaiting a BAR to complete.) PR: kern/168170
2012-06-13 06:57:55 +00:00
error = ath_descdma_setup(sc, &sc->sc_txdma_mgmt, &sc->sc_txbuf_mgmt,
Modify ath_descdma_setup() to take a descriptor size parameter. The AR9300 and later descriptors are 128 bytes, however I'd like to make sure that isn't used for earlier chips. * Populate the TX descriptor length field in the softc with sizeof(ath_desc) * Use this field when allocating the TX descriptors * Pre-AR93xx TX/RX descriptors will use the ath_desc size; newer ones will query the HAL for these sizes.
2012-07-23 23:40:13 +00:00
"tx_mgmt", sc->sc_tx_desclen, ath_txbuf_mgmt,
ATH_TXDESC);
Implement a separate, smaller pool of ath_buf entries for use by management traffic. * Create sc_mgmt_txbuf and sc_mgmt_txdesc, initialise/free them appropriately. * Create an enum to represent buffer types in the API. * Extend ath_getbuf() and _ath_getbuf_locked() to take the above enum. * Right now anything sent via ic_raw_xmit() allocates via ATH_BUFTYPE_MGMT. This may not be very useful. * Add ATH_BUF_MGMT flag (ath_buf.bf_flags) which indicates the current buffer is a mgmt buffer and should go back onto the mgmt free list. * Extend 'txagg' to include debugging output for both normal and mgmt txbufs. * When checking/clearing ATH_BUF_BUSY, do it on both TX pools. Tested: * STA mode, with heavy UDP injection via iperf. This filled the TX queue however BARs were still going out successfully. TODO: * Initialise the mgmt buffers with ATH_BUF_MGMT and then ensure the right type is being allocated and freed on the appropriate list. That'd save a write operation (to bf->bf_flags) on each buffer alloc/free. * Test on AP mode, ensure that BAR TX and probe responses go out nicely when the main TX queue is filled (eg with paused traffic to a TID, awaiting a BAR to complete.) PR: kern/168170
2012-06-13 06:57:55 +00:00
if (error != 0) {
ath_descdma_cleanup(sc, &sc->sc_txdma, &sc->sc_txbuf);
return error;
}
/*
* XXX mark txbuf_mgmt frames with ATH_BUF_MGMT, so the
* flag doesn't have to be set in ath_getbuf_locked().
*/
Update with last year of work.
2004-12-08 17:34:36 +00:00
error = ath_descdma_setup(sc, &sc->sc_bdma, &sc->sc_bbuf,
Modify ath_descdma_setup() to take a descriptor size parameter. The AR9300 and later descriptors are 128 bytes, however I'd like to make sure that isn't used for earlier chips. * Populate the TX descriptor length field in the softc with sizeof(ath_desc) * Use this field when allocating the TX descriptors * Pre-AR93xx TX/RX descriptors will use the ath_desc size; newer ones will query the HAL for these sizes.
2012-07-23 23:40:13 +00:00
"beacon", sc->sc_tx_desclen, ATH_BCBUF, 1);
Update with last year of work.
2004-12-08 17:34:36 +00:00
if (error != 0) {
Implement a separate, smaller pool of ath_buf entries for use by management traffic. * Create sc_mgmt_txbuf and sc_mgmt_txdesc, initialise/free them appropriately. * Create an enum to represent buffer types in the API. * Extend ath_getbuf() and _ath_getbuf_locked() to take the above enum. * Right now anything sent via ic_raw_xmit() allocates via ATH_BUFTYPE_MGMT. This may not be very useful. * Add ATH_BUF_MGMT flag (ath_buf.bf_flags) which indicates the current buffer is a mgmt buffer and should go back onto the mgmt free list. * Extend 'txagg' to include debugging output for both normal and mgmt txbufs. * When checking/clearing ATH_BUF_BUSY, do it on both TX pools. Tested: * STA mode, with heavy UDP injection via iperf. This filled the TX queue however BARs were still going out successfully. TODO: * Initialise the mgmt buffers with ATH_BUF_MGMT and then ensure the right type is being allocated and freed on the appropriate list. That'd save a write operation (to bf->bf_flags) on each buffer alloc/free. * Test on AP mode, ensure that BAR TX and probe responses go out nicely when the main TX queue is filled (eg with paused traffic to a TID, awaiting a BAR to complete.) PR: kern/168170
2012-06-13 06:57:55 +00:00
ath_descdma_cleanup(sc, &sc->sc_txdma, &sc->sc_txbuf);
ath_descdma_cleanup(sc, &sc->sc_txdma_mgmt,
&sc->sc_txbuf_mgmt);
Update with last year of work.
2004-12-08 17:34:36 +00:00
return error;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
Update with last year of work.
2004-12-08 17:34:36 +00:00
return 0;
}
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
Update with last year of work.
2004-12-08 17:34:36 +00:00
static void
ath_desc_free(struct ath_softc *sc)
{
if (sc->sc_bdma.dd_desc_len != 0)
ath_descdma_cleanup(sc, &sc->sc_bdma, &sc->sc_bbuf);
if (sc->sc_txdma.dd_desc_len != 0)
ath_descdma_cleanup(sc, &sc->sc_txdma, &sc->sc_txbuf);
Implement a separate, smaller pool of ath_buf entries for use by management traffic. * Create sc_mgmt_txbuf and sc_mgmt_txdesc, initialise/free them appropriately. * Create an enum to represent buffer types in the API. * Extend ath_getbuf() and _ath_getbuf_locked() to take the above enum. * Right now anything sent via ic_raw_xmit() allocates via ATH_BUFTYPE_MGMT. This may not be very useful. * Add ATH_BUF_MGMT flag (ath_buf.bf_flags) which indicates the current buffer is a mgmt buffer and should go back onto the mgmt free list. * Extend 'txagg' to include debugging output for both normal and mgmt txbufs. * When checking/clearing ATH_BUF_BUSY, do it on both TX pools. Tested: * STA mode, with heavy UDP injection via iperf. This filled the TX queue however BARs were still going out successfully. TODO: * Initialise the mgmt buffers with ATH_BUF_MGMT and then ensure the right type is being allocated and freed on the appropriate list. That'd save a write operation (to bf->bf_flags) on each buffer alloc/free. * Test on AP mode, ensure that BAR TX and probe responses go out nicely when the main TX queue is filled (eg with paused traffic to a TID, awaiting a BAR to complete.) PR: kern/168170
2012-06-13 06:57:55 +00:00
if (sc->sc_txdma_mgmt.dd_desc_len != 0)
ath_descdma_cleanup(sc, &sc->sc_txdma_mgmt,
&sc->sc_txbuf_mgmt);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
static struct ieee80211_node *
Change the calling convention for ic_node_alloc to deal with some longstanding issues: o pass the vap since it's now the "coin of the realm" and required to do things like set initial tx parameters in private node state for use prior to association o pass the mac address as cards that maintain outboard station tables require this to create an entry (e.g. in ibss mode) o remove the node table reference, we only have one node table and it's unlikely this will change so this is not needed to find the com structure
2008-06-07 18:38:02 +00:00
ath_node_alloc(struct ieee80211vap *vap, const uint8_t mac[IEEE80211_ADDR_LEN])
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
{
Change the calling convention for ic_node_alloc to deal with some longstanding issues: o pass the vap since it's now the "coin of the realm" and required to do things like set initial tx parameters in private node state for use prior to association o pass the mac address as cards that maintain outboard station tables require this to create an entry (e.g. in ibss mode) o remove the node table reference, we only have one node table and it's unlikely this will change so this is not needed to find the com structure
2008-06-07 18:38:02 +00:00
struct ieee80211com *ic = vap->iv_ic;
Remove most of the references of ifp->if_softc and replace with references to ic->ic_softc. This is in preparation for gleb's ifnet work. Tested: * ath(4), STA mode * ath(4), hostap mode * make universe
2015-08-17 02:04:11 +00:00
struct ath_softc *sc = ic->ic_softc;
Update with last year of work.
2004-12-08 17:34:36 +00:00
const size_t space = sizeof(struct ath_node) + sc->sc_rc->arc_space;
struct ath_node *an;
an = malloc(space, M_80211_NODE, M_NOWAIT|M_ZERO);
if (an == NULL) {
/* XXX stat+msg */
Maintain a history of data associated with received frames and use this to calculate smoothed signal quality data for each node. o add a 16-deep history buffer to each driver-private node storage that holds rssi and antenna info for received frames o override the default per-node "get rssi" method to return an average rssi value based on samples collected over the last second o enable beacon reception so even idle systems maintain a running history of signal quality This data may also be useful for improving the rate control algorithm. Based on work by Tom Marshall <tommy@home.tig-grr.com> for MADWIFI.
2003-09-15 22:34:46 +00:00
return NULL;
Update with last year of work.
2004-12-08 17:34:36 +00:00
}
ath_rate_node_init(sc, an);
Begin merging in some of my 802.11n TX aggregation driver changes. * Add a PCU lock, which isn't currently used but will eventually be used to serialise some of the driver access. * Add in all the software TX aggregation state, that's kept per-node and per-TID. * Add in the software and aggregation state to ath_buf. * Add in hooks to ath_softc for aggregation state and the (upcoming) aggregation TX state calls. * Add / fix the HAL access macros. Obtained from: Linux, ath9k Sponsored by: Hobnob, Inc.
2011-11-08 02:12:11 +00:00
/* Setup the mutex - there's no associd yet so set the name to NULL */
snprintf(an->an_name, sizeof(an->an_name), "%s: node %p",
device_get_nameunit(sc->sc_dev), an);
mtx_init(&an->an_mtx, an->an_name, NULL, MTX_DEF);
Introduce TX aggregation and software TX queue management for Atheros AR5416 and later wireless devices. This is a very large commit - the complete history can be found in the user/adrian/if_ath_tx branch. Legacy (ie, pre-AR5416) devices also use the per-software TXQ support and (in theory) can support non-aggregation ADDBA sessions. However, the net80211 stack doesn't currently support this. In summary: TX path: * queued frames normally go onto a per-TID, per-node queue * some special frames (eg ADDBA control frames) are thrown directly onto the relevant hardware queue so they can go out before any software queued frames are queued. * Add methods to create, suspend, resume and tear down an aggregation session. * Add in software retransmission of both normal and aggregate frames. * Add in completion handling of aggregate frames, including parsing the block ack bitmap provided by the hardware. * Write an aggregation function which can assemble frames into an aggregate based on the selected rate control and channel configuration. * The per-TID queues are locked based on their target hardware TX queue. This matches what ath9k/atheros does, and thus simplified porting over some of the aggregation logic. * When doing TX aggregation, stick the sequence number allocation in the TX path rather than net80211 TX path, and protect it by the TXQ lock. Rate control: * Delay rate control selection until the frame is about to be queued to the hardware, so retried frames can have their rate control choices changed. Frames with a static rate control selection have that applied before each TX, just to simplify the TX path (ie, not have "static" and "dynamic" rate control special cased.) * Teach ath_rate_sample about aggregates - both completion and errors. * Add an EWMA for tracking what the current "good" MCS rate is based on failure rates. Misc: * Introduce a bunch of dirty hacks and workarounds so TID mapping and net80211 frame inspection can be kept out of the net80211 layer. Because of the way this code works (and it's from Atheros and Linux ath9k), there is a consistent, 1:1 mapping between TID and AC. So we need to ensure that frames going to a specific TID will _always_ end up on the right AC, and vice versa, or the completion/locking will simply get very confused. I plan on addressing this mess in the future. Known issues: * There is no BAR frame transmission just yet. A whole lot of tidying up needs to occur before BAR frame TX can occur in the "correct" place - ie, once the TID TX queue has been drained. * Interface reset/purge/etc results in frames in the TX and RX queues being removed. This creates holes in the sequence numbers being assigned and the TX/RX AMPDU code (on either side) just hangs. * There's no filtered frame support at the present moment, so stations going into power saving mode will simply have a number of frames dropped - likely resulting in a traffic "hang". * Raw frame TX is going to just not function with 11n aggregation. Likely this needs to be modified to always override the sequence number if the frame is going into an aggregation session. However, general raw frame injection currently doesn't work in general in net80211, so let's just ignore this for now until this is sorted out. * HT protection is just not implemented and won't be until the above is sorted out. In addition, the AR5416 has issues RTS protecting large aggregates (anything >8k), so the work around needs to be ported and tested. Thus, this will be put on hold until the above work is complete. * The rate control module 'sample' is the only currently supported module; onoe/amrr haven't been tested and have likely bit rotted a little. I'll follow up with some commits to make them work again for non-11n rates, but they won't be updated to handle 11n and aggregation. If someone wishes to do so then they're welcome to send along patches. * .. and "sample" doesn't really do a good job of 11n TX. Specifically, the metrics used (packet TX time and failure/success rates) isn't as useful for 11n. It's likely that it should be extended to take into account the aggregate throughput possible and then choose a rate which maximises that. Ie, it may be acceptable for a higher MCS rate with a higher failure to be used if it gives a more acceptable throughput/latency then a lower MCS rate @ a lower error rate. Again, patches will be gratefully accepted. Because of this, ATH_ENABLE_11N is still not enabled by default. Sponsored by: Hobnob, Inc. Obtained from: Linux, Atheros
2011-11-08 22:43:13 +00:00
/* XXX setup ath_tid */
ath_tx_tid_init(sc, an);
[ath] [ath_rate] Fix ANI calibration during non-ACTIVE states; start poking at rate control These are some fun issues I've found with my upstairs wifi link at such a ridiculous low signal level (like, < 5dB.) * Add per-station tx/rx rssi statistics, in potential preparation to use that in the RX rate control. * Call the rate control on each received frame to let it potentially use it as a hint for what rates to potentially use. It's a no-op right now. * Do ANI calibration during scan as well. The ath_newstate() call was disabling the ANI timer and only re-enabling it during transitions to _RUN. This has the unfortunate side-effect that if ANI deafened the NIC because of interference and it disassociated, it wouldn't be reset and the scan would never hear beacons. The ANI configuration is stored at least globally on some HALs and per-channel on others. Because of this a NIC reset wouldn't help; the ANI parameters would simply be programmed back in. Now, I have a feeling I also need to do this during AUTH/ASSOC too and maybe, if I'm feeling clever, I need to reset the ANI parameters on a given channel during a transition through INIT or if the VAP is destroyed/re-created. However for now this gets me out of the immediate weeds with connectivity upstairs (and thus I /can/ commit); I'll keep chipping away at tidying this stuff up in subsequent commits. Tested: * AR9344 (Wasp), 2G STA mode
2019-05-05 04:56:37 +00:00
an->an_node_stats.ns_avgbrssi = ATH_RSSI_DUMMY_MARKER;
an->an_node_stats.ns_avgrssi = ATH_RSSI_DUMMY_MARKER;
an->an_node_stats.ns_avgtxrssi = ATH_RSSI_DUMMY_MARKER;
Improve the debugging output - use the MAC address rather than various pointer values everywhere.
2013-05-13 19:52:35 +00:00
DPRINTF(sc, ATH_DEBUG_NODE, "%s: %6D: an %p\n", __func__, mac, ":", an);
Update with last year of work.
2004-12-08 17:34:36 +00:00
return &an->an_node;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
Break out the node cleanup and node free path, in preparation for doing software TX queue management. The software queued TX frames will be freed by the new cleanup function. Sponsored by: Hobnob, Inc.
2011-11-08 18:48:26 +00:00
static void
ath_node_cleanup(struct ieee80211_node *ni)
{
struct ieee80211com *ic = ni->ni_ic;
Remove most of the references of ifp->if_softc and replace with references to ic->ic_softc. This is in preparation for gleb's ifnet work. Tested: * ath(4), STA mode * ath(4), hostap mode * make universe
2015-08-17 02:04:11 +00:00
struct ath_softc *sc = ic->ic_softc;
Break out the node cleanup and node free path, in preparation for doing software TX queue management. The software queued TX frames will be freed by the new cleanup function. Sponsored by: Hobnob, Inc.
2011-11-08 18:48:26 +00:00
Improve the debugging output - use the MAC address rather than various pointer values everywhere.
2013-05-13 19:52:35 +00:00
DPRINTF(sc, ATH_DEBUG_NODE, "%s: %6D: an %p\n", __func__,
ni->ni_macaddr, ":", ATH_NODE(ni));
Break out the node cleanup and node free path, in preparation for doing software TX queue management. The software queued TX frames will be freed by the new cleanup function. Sponsored by: Hobnob, Inc.
2011-11-08 18:48:26 +00:00
/* Cleanup ath_tid, free unused bufs, unlink bufs in TXQ */
Introduce TX aggregation and software TX queue management for Atheros AR5416 and later wireless devices. This is a very large commit - the complete history can be found in the user/adrian/if_ath_tx branch. Legacy (ie, pre-AR5416) devices also use the per-software TXQ support and (in theory) can support non-aggregation ADDBA sessions. However, the net80211 stack doesn't currently support this. In summary: TX path: * queued frames normally go onto a per-TID, per-node queue * some special frames (eg ADDBA control frames) are thrown directly onto the relevant hardware queue so they can go out before any software queued frames are queued. * Add methods to create, suspend, resume and tear down an aggregation session. * Add in software retransmission of both normal and aggregate frames. * Add in completion handling of aggregate frames, including parsing the block ack bitmap provided by the hardware. * Write an aggregation function which can assemble frames into an aggregate based on the selected rate control and channel configuration. * The per-TID queues are locked based on their target hardware TX queue. This matches what ath9k/atheros does, and thus simplified porting over some of the aggregation logic. * When doing TX aggregation, stick the sequence number allocation in the TX path rather than net80211 TX path, and protect it by the TXQ lock. Rate control: * Delay rate control selection until the frame is about to be queued to the hardware, so retried frames can have their rate control choices changed. Frames with a static rate control selection have that applied before each TX, just to simplify the TX path (ie, not have "static" and "dynamic" rate control special cased.) * Teach ath_rate_sample about aggregates - both completion and errors. * Add an EWMA for tracking what the current "good" MCS rate is based on failure rates. Misc: * Introduce a bunch of dirty hacks and workarounds so TID mapping and net80211 frame inspection can be kept out of the net80211 layer. Because of the way this code works (and it's from Atheros and Linux ath9k), there is a consistent, 1:1 mapping between TID and AC. So we need to ensure that frames going to a specific TID will _always_ end up on the right AC, and vice versa, or the completion/locking will simply get very confused. I plan on addressing this mess in the future. Known issues: * There is no BAR frame transmission just yet. A whole lot of tidying up needs to occur before BAR frame TX can occur in the "correct" place - ie, once the TID TX queue has been drained. * Interface reset/purge/etc results in frames in the TX and RX queues being removed. This creates holes in the sequence numbers being assigned and the TX/RX AMPDU code (on either side) just hangs. * There's no filtered frame support at the present moment, so stations going into power saving mode will simply have a number of frames dropped - likely resulting in a traffic "hang". * Raw frame TX is going to just not function with 11n aggregation. Likely this needs to be modified to always override the sequence number if the frame is going into an aggregation session. However, general raw frame injection currently doesn't work in general in net80211, so let's just ignore this for now until this is sorted out. * HT protection is just not implemented and won't be until the above is sorted out. In addition, the AR5416 has issues RTS protecting large aggregates (anything >8k), so the work around needs to be ported and tested. Thus, this will be put on hold until the above work is complete. * The rate control module 'sample' is the only currently supported module; onoe/amrr haven't been tested and have likely bit rotted a little. I'll follow up with some commits to make them work again for non-11n rates, but they won't be updated to handle 11n and aggregation. If someone wishes to do so then they're welcome to send along patches. * .. and "sample" doesn't really do a good job of 11n TX. Specifically, the metrics used (packet TX time and failure/success rates) isn't as useful for 11n. It's likely that it should be extended to take into account the aggregate throughput possible and then choose a rate which maximises that. Ie, it may be acceptable for a higher MCS rate with a higher failure to be used if it gives a more acceptable throughput/latency then a lower MCS rate @ a lower error rate. Again, patches will be gratefully accepted. Because of this, ATH_ENABLE_11N is still not enabled by default. Sponsored by: Hobnob, Inc. Obtained from: Linux, Atheros
2011-11-08 22:43:13 +00:00
ath_tx_node_flush(sc, ATH_NODE(ni));
Break out the node cleanup and node free path, in preparation for doing software TX queue management. The software queued TX frames will be freed by the new cleanup function. Sponsored by: Hobnob, Inc.
2011-11-08 18:48:26 +00:00
ath_rate_node_cleanup(sc, ATH_NODE(ni));
sc->sc_node_cleanup(ni);
}
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
static void
Update with last year of work.
2004-12-08 17:34:36 +00:00
ath_node_free(struct ieee80211_node *ni)
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
{
Update with last year of work.
2004-12-08 17:34:36 +00:00
struct ieee80211com *ic = ni->ni_ic;
Remove most of the references of ifp->if_softc and replace with references to ic->ic_softc. This is in preparation for gleb's ifnet work. Tested: * ath(4), STA mode * ath(4), hostap mode * make universe
2015-08-17 02:04:11 +00:00
struct ath_softc *sc = ic->ic_softc;
do proper subclassing of node free+copy; the previous hack falls apart when the 802.11 layer does useful work Obtained from: madwifi
2004-04-03 00:06:23 +00:00
Improve the debugging output - use the MAC address rather than various pointer values everywhere.
2013-05-13 19:52:35 +00:00
DPRINTF(sc, ATH_DEBUG_NODE, "%s: %6D: an %p\n", __func__,
ni->ni_macaddr, ":", ATH_NODE(ni));
Begin merging in some of my 802.11n TX aggregation driver changes. * Add a PCU lock, which isn't currently used but will eventually be used to serialise some of the driver access. * Add in all the software TX aggregation state, that's kept per-node and per-TID. * Add in the software and aggregation state to ath_buf. * Add in hooks to ath_softc for aggregation state and the (upcoming) aggregation TX state calls. * Add / fix the HAL access macros. Obtained from: Linux, ath9k Sponsored by: Hobnob, Inc.
2011-11-08 02:12:11 +00:00
mtx_destroy(&ATH_NODE(ni)->an_mtx);
Update with last year of work.
2004-12-08 17:34:36 +00:00
sc->sc_node_free(ni);
}
Maintain a history of data associated with received frames and use this to calculate smoothed signal quality data for each node. o add a 16-deep history buffer to each driver-private node storage that holds rssi and antenna info for received frames o override the default per-node "get rssi" method to return an average rssi value based on samples collected over the last second o enable beacon reception so even idle systems maintain a running history of signal quality This data may also be useful for improving the rate control algorithm. Based on work by Tom Marshall <tommy@home.tig-grr.com> for MADWIFI.
2003-09-15 22:34:46 +00:00
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
static void
ath_node_getsignal(const struct ieee80211_node *ni, int8_t *rssi, int8_t *noise)
{
struct ieee80211com *ic = ni->ni_ic;
Remove most of the references of ifp->if_softc and replace with references to ic->ic_softc. This is in preparation for gleb's ifnet work. Tested: * ath(4), STA mode * ath(4), hostap mode * make universe
2015-08-17 02:04:11 +00:00
struct ath_softc *sc = ic->ic_softc;
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
struct ath_hal *ah = sc->sc_ah;
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
*rssi = ic->ic_node_getrssi(ni);
Overhaul regulatory support: o remove HAL_CHANNEL; convert the hal to use net80211 channels; this mostly involves mechanical changes to variable names and channel attribute macros o gut HAL_CHANNEL_PRIVATE as most of the contents are now redundant with the net80211 channel available o change api for ath_hal_init_channels: no more reglass id's, no more outdoor indication (was a noop), anM contents o add ath_hal_getchannels to have the hal construct a channel list without altering runtime state; this is used to retrieve the calibration list for the device in ath_getradiocaps o add ath_hal_set_channels to take a channel list and regulatory data from above and construct internal state to match (maps frequencies for 900MHz cards, setup for CTL lookups, etc) o compact the private channel table: we keep one private channel per frequency instead of one per HAL_CHANNEL; this gives a big space savings and potentially improves ani and calibration by sharing state (to be seen; didn't see anything in testing); a new config option AH_MAXCHAN controls the table size (default to 96 which was chosen to be ~3x the largest expected size) o shrink ani state and change to mirror private channel table (one entry per frequency indexed by ic_devdata) o move ani state flags to private channel state o remove country codes; use net80211 definitions instead o remove GSM regulatory support; it's no longer needed now that we pass in channel lists from above o consolidate ADHOC_NO_11A attribute with DISALLOW_ADHOC_11A o simplify initial channel list construction based on the EEPROM contents; we preserve country code support for now but may want to just fallback to a WWR sku and dispatch the discovered country code up to user space so the channel list can be constructed using the master regdomain tables o defer to net80211 for max antenna gain o eliminate sorting of internal channel table; now that we use ic_devdata as an index, table lookups are O(1) o remove internal copy of the country code; the public one is sufficient o remove AH_SUPPORT_11D conditional compilation; we always support 11d o remove ath_hal_ispublicsafetysku; not needed any more o remove ath_hal_isgsmsku; no more GSM stuff o move Conformance Test Limit (CTL) state from private channel to a lookup using per-band pointers cached in the private state block o remove regulatory class id support; was unused and belongs in net80211 o fix channel list construction to set IEEE80211_CHAN_NOADHOC, IEEE80211_CHAN_NOHOSTAP, and IEEE80211_CHAN_4MSXMIT o remove private channel flags CHANNEL_DFS and CHANNEL_4MS_LIMIT; these are now set in the constructed net80211 channel o store CHANNEL_NFCREQUIRED (Noise Floor Required) channel attribute in one of the driver-private flag bits of the net80211 channel o move 900MHz frequency mapping into the hal; the mapped frequency is stored in the private channel and used throughout the hal (no more mapping in the driver and/or net80211) o remove ath_hal_mhz2ieee; it's no longer needed as net80211 does the calculation and available in the net80211 channel o change noise floor calibration logic to work with compacted private channel table setup; this may require revisiting as we no longer can distinguish channel attributes (e.g. 11b vs 11g vs turbo) but since the data is used only to calculate status data we can live with it for now o change ah_getChipPowerLimits internal method to operate on a single channel instead of all channels in the private channel table o add ath_hal_gethwchannel to map a net80211 channel to a h/w frequency (always the same except for 900MHz channels) o add HAL_EEBADREG and HAL_EEBADCC status codes to better identify regulatory problems o remove CTRY_DEBUG and CTRY_DEFAULT enum's; these come from net80211 now o change ath_hal_getwirelessmodes to really return wireless modes supported by the hardware (was previously applying regulatory constraints) o return channel interference status with IEEE80211_CHANSTATE_CWINT (should change to a callback so hal api's can take const pointers) o remove some #define's no longer needed with the inclusion of <net80211/_ieee80211.h> Sponsored by: Carlson Wireless
2009-01-28 18:00:22 +00:00
if (ni->ni_chan != IEEE80211_CHAN_ANYC)
*noise = ath_hal_getchannoise(ah, ni->ni_chan);
else
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
*noise = -95; /* nominally correct */
}
Update with last year of work.
2004-12-08 17:34:36 +00:00
/*
* Set the default antenna.
*/
Migrate the bulk of the RX routines out from if_ath.c to if_ath_rx.[ch]. * migrate the rx processing out into if_ath_rx.c * migrate the TSF functions into if_ath_tsf.h, as inlines This is in prepration for supporting the EDMA RX routines, required to support the AR93xx series NICs. TODO: * ath_start() shouldn't be private, but it's called as part of the RX path. I should likely migrate ath_rx_tasklet() back into if_ath.c and then return this to be 'static'. The RX code really shouldn't need to see TX routines (and vice versa.) * ath_beacon_* should be in if_ath_beacon.[ch]. * ath_tdma_* should be in if_ath_tdma.[ch] ...
2012-05-20 02:05:10 +00:00
void
Update with last year of work.
2004-12-08 17:34:36 +00:00
ath_setdefantenna(struct ath_softc *sc, u_int antenna)
{
struct ath_hal *ah = sc->sc_ah;
/* XXX block beacon interrupts */
ath_hal_setdefantenna(ah, antenna);
if (sc->sc_defant != antenna)
sc->sc_stats.ast_ant_defswitch++;
sc->sc_defant = antenna;
sc->sc_rxotherant = 0;
}
Close race in handling mcast traffic when operating as an ap with stations in power save: add a new q where mcast frames are stashed and on beacon update (at DTIM) move frames from the mcast q to the cabq and start it. This ensures the cabq is only manipulated in one place. Sponsored by: Hobnob MFC after: 2 weeks
2006-06-26 03:10:45 +00:00
static void
ath_txq_init(struct ath_softc *sc, struct ath_txq *txq, int qnum)
{
txq->axq_qnum = qnum;
Hoist 802.11 encapsulation up into net80211: o call ieee80211_encap in ieee80211_start so frames passed down to drivers are already encapsulated o remove ieee80211_encap calls in drivers o fixup wi so it recreates the 802.3 head it requires from the 802.11 header contents o move fast-frame aggregation from ath to net80211 (conditional on IEEE80211_SUPPORT_SUPERG): - aggregation is now done in ieee80211_start; it is enabled when the packets/sec exceeds ieee80211_ffppsmin (net.wlan.ffppsmin) and frames are held on a staging queue according to ieee80211_ffagemax (net.wlan.ffagemax) to wait for a frame to combine with - drivers must call back to age/flush the staging queue (ath does this on tx done, at swba, and on rx according to the state of the tx queues and/or the contents of the staging queue) - remove fast-frame-related data structures from ath - add ieee80211_ff_node_init and ieee80211_ff_node_cleanup to handle per-node fast-frames state (we reuse 11n tx ampdu state) o change ieee80211_encap calling convention to include an explicit vap so frames coming through a WDS vap are recognized w/o setting M_WDS With these changes any device able to tx/rx 3Kbyte+ frames can use fast-frames. Reviewed by: thompsa, rpaulo, avatar, imp, sephe
2009-03-30 21:53:27 +00:00
txq->axq_ac = 0;
Close race in handling mcast traffic when operating as an ap with stations in power save: add a new q where mcast frames are stashed and on beacon update (at DTIM) move frames from the mcast q to the cabq and start it. This ensures the cabq is only manipulated in one place. Sponsored by: Hobnob MFC after: 2 weeks
2006-06-26 03:10:45 +00:00
txq->axq_depth = 0;
Some more various fixes, etc from my 11n branch. * When doing software TX queue handling and flush, it's possible that the deletion of a VAP (eg a STA shutdown) will queue a "STA Disassociate" frame whilst the interface is being deleted. The VAP is then deleted, and the frame ends up being queued to a node that is freed before it can be TX'ed. Things go awry at this point. There's no way at the present to avoid freeing the underlying node when the vap is being deleted. It's too late in the game. I suspect the real fix is to make sure the frame is software queued with no completion information somehow, so it doesn't link back to a node whose underlying VAP has been freed. For now, we'll just have to do this. * Add some comments showing what's going on. * Move an instance of the ATH_LOCK() around to protect the interrupt set. I'll worry about changing that to a PCU lock later on once the 11n code is in the tree. Sponsored by: Hobnob, Inc.
2011-11-08 19:18:34 +00:00
txq->axq_aggr_depth = 0;
Close race in handling mcast traffic when operating as an ap with stations in power save: add a new q where mcast frames are stashed and on beacon update (at DTIM) move frames from the mcast q to the cabq and start it. This ensures the cabq is only manipulated in one place. Sponsored by: Hobnob MFC after: 2 weeks
2006-06-26 03:10:45 +00:00
txq->axq_intrcnt = 0;
txq->axq_link = NULL;
Migrate the STAILQ lists to TAILQs. A bunch of the 11n TX aggregation logic wants to traverse lists of buffers in various ways. In order to provide O(1) behaviour in this instance, use TAILQs. This does blow out the memory footprint and CPU cycles slightly for some of these operations. I may convert some of these back to STAILQs once the rest of the software transmit queue handling has been stabilised. Sponsored by: Hobnob, Inc.
2011-11-08 17:08:12 +00:00
txq->axq_softc = sc;
TAILQ_INIT(&txq->axq_q);
TAILQ_INIT(&txq->axq_tidq);
Add per-TXQ EDMA FIFO staging queue support. Each set of frames pushed into a FIFO is represented by a list of ath_bufs - the first ath_buf in the FIFO list is marked with ATH_BUF_FIFOPTR; the last ath_buf in the FIFO list is marked with ATH_BUF_FIFOEND. Multiple lists of frames are just glued together in the TAILQ as per normal - except that at the end of a FIFO list, the descriptor link pointer will be NULL and it'll be tagged with ATH_BUF_FIFOEND. For non-EDMA chipsets this is a no-op - the ath_txq frame list (axq_q) stays the same and is treated the same. For EDMA chipsets the frames are pushed into axq_q and then when the FIFO is to be (re) filled, frames will be moved onto the FIFO queue and then pushed into the FIFO. So: * Add a new queue in each hardware TXQ (ath_txq) for staging FIFO frame lists. It's a TAILQ (like the normal hardware frame queue) rather than the ath9k list-of-lists to represent FIFO entries. * Add new ath_buf flags - ATH_TX_FIFOPTR and ATH_TX_FIFOEND. * When allocating ath_buf entries, clear out the flag value before returning it or it'll end up having stale flags. * When cloning ath_buf entries, only clone ATH_BUF_MGMT. Don't clone the FIFO related flags. * Extend ath_tx_draintxq() to first drain the FIFO staging queue, _then_ drain the normal hardware queue. Tested: * AR9280, hostap * AR9280, STA * AR9380/AR9580 - hostap TODO: * Test on other chipsets, just to be thorough.
2013-03-26 19:46:51 +00:00
TAILQ_INIT(&txq->fifo.axq_q);
Overhaul the TXQ locking (again!) as part of some beacon/cabq timing related issues. Moving the TX locking under one lock made things easier to progress on but it had one important side-effect - it increased the latency when handling CABQ setup when sending beacons. This commit introduces a bunch of new changes and a few unrelated changs that are just easier to lump in here. The aim is to have the CABQ locking separate from other locking. The CABQ transmit path in the beacon process thus doesn't have to grab the general TX lock, reducing lock contention/latency and making it more likely that we'll make the beacon TX timing. The second half of this commit is the CABQ related setup changes needed for sane looking EDMA CABQ support. Right now the EDMA TX code naively assumes that only one frame (MPDU or A-MPDU) is being pushed into each FIFO slot. For the CABQ this isn't true - a whole list of frames is being pushed in - and thus CABQ handling breaks very quickly. The aim here is to setup the CABQ list and then push _that list_ to the hardware for transmission. I can then extend the EDMA TX code to stamp that list as being "one" FIFO entry (likely by tagging the last buffer in that list as "FIFO END") so the EDMA TX completion code correctly tracks things. Major: * Migrate the per-TXQ add/removal locking back to per-TXQ, rather than a single lock. * Leave the software queue side of things under the ATH_TX_LOCK lock, (continuing) to serialise things as they are. * Add a new function which is called whenever there's a beacon miss, to print out some debugging. This is primarily designed to help me figure out if the beacon miss events are due to a noisy environment, issues with the PHY/MAC, or other. * Move the CABQ setup/enable to occur _after_ all the VAPs have been looked at. This means that for multiple VAPS in bursted mode, the CABQ gets primed once all VAPs are checked, rather than being primed on the first VAP and then having frames appended after this. Minor: * Add a (disabled) twiddle to let me enable/disable cabq traffic. It's primarily there to let me easily debug what's going on with beacon and CABQ setup/traffic; there's some DMA engine hangs which I'm finally trying to trace down. * Clear bf_next when flushing frames; it should quieten some warnings that show up when a node goes away. Tested: * AR9280, STA/hostap, up to 4 vaps (staggered) * AR5416, STA/hostap, up to 4 vaps (staggered) TODO: * (Lots) more AR9380 and later testing, as I may have missed something here. * Leverage this to fix CABQ hanling for AR9380 and later chips. * Force bursted beaconing on the chips that default to staggered beacons and ensure the CABQ stuff is all sane (eg, the MORE bits that aren't being correctly set when chaining descriptors.)
2013-03-24 00:03:12 +00:00
ATH_TXQ_LOCK_INIT(sc, txq);
Close race in handling mcast traffic when operating as an ap with stations in power save: add a new q where mcast frames are stashed and on beacon update (at DTIM) move frames from the mcast q to the cabq and start it. This ensures the cabq is only manipulated in one place. Sponsored by: Hobnob MFC after: 2 weeks
2006-06-26 03:10:45 +00:00
}
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
/*
Update with last year of work.
2004-12-08 17:34:36 +00:00
* Setup a h/w transmit queue.
*/
static struct ath_txq *
ath_txq_setup(struct ath_softc *sc, int qtype, int subtype)
{
struct ath_hal *ah = sc->sc_ah;
HAL_TXQ_INFO qi;
int qnum;
memset(&qi, 0, sizeof(qi));
qi.tqi_subtype = subtype;
qi.tqi_aifs = HAL_TXQ_USEDEFAULT;
qi.tqi_cwmin = HAL_TXQ_USEDEFAULT;
qi.tqi_cwmax = HAL_TXQ_USEDEFAULT;
/*
* Enable interrupts only for EOL and DESC conditions.
* We mark tx descriptors to receive a DESC interrupt
* when a tx queue gets deep; otherwise waiting for the
* EOL to reap descriptors. Note that this is done to
* reduce interrupt load and this only defers reaping
* descriptors, never transmitting frames. Aside from
* reducing interrupts this also permits more concurrency.
* The only potential downside is if the tx queue backs
* up in which case the top half of the kernel may backup
* due to a lack of tx descriptors.
*/
Always enable TXOK interrupts when setting up TX queues for EDMA NICs.
2013-04-11 22:02:35 +00:00
if (sc->sc_isedma)
qi.tqi_qflags = HAL_TXQ_TXEOLINT_ENABLE |
HAL_TXQ_TXOKINT_ENABLE;
else
qi.tqi_qflags = HAL_TXQ_TXEOLINT_ENABLE |
HAL_TXQ_TXDESCINT_ENABLE;
Update with last year of work.
2004-12-08 17:34:36 +00:00
qnum = ath_hal_setuptxqueue(ah, qtype, &qi);
if (qnum == -1) {
/*
Misc keycache changes: o purge ath_initkeytable; it's not needed o add multicast key search support for supporting multiple group keys (disabled for now; requires updated hal) o create keycache entry for stations using open auth so they get h/w antenna management support o add keycache -> node mapping table; eliminates mac-based lookup in the net80211 layer
2005-06-06 16:39:21 +00:00
* NB: don't print a message, this happens
correct some typos Submitted by: Tai-hwa Liang
2004-12-31 20:35:05 +00:00
* normally on parts with too few tx queues
Update with last year of work.
2004-12-08 17:34:36 +00:00
*/
return NULL;
}
net80211 & wireless drivers: remove duplicate defines (noop) * IEEE80211_DIR_DSTODS(wh) -> IEEE80211_IS_DSTODS(wh). * N(a) -> nitems(a). * Remove LE_READ_2(p)/LE_READ_4(p) definitions (and include ieee80211_input.h instead). * <drvname>_TXOP_TO_US(txop) -> IEEE80211_TXOP_TO_US(txop). * Put IEEE80211_RV(v) into ieee80211_proto.h and remove local RV(v) definitions. Submitted by: Andriy Voskoboinyk <s3erios@gmail.com> Differential Revision: https://reviews.freebsd.org/D3705
2015-09-22 02:44:59 +00:00
if (qnum >= nitems(sc->sc_txq)) {
Make this amd64-clean. sizeof is long on amd64, so things that do a printf of a sizeof, need to use %z to get the correct type on all our platforms. Also, convert integers<->pointers via uintptr_t. (I think Sam's instructions were for me to commit this. If I misunderstood, then I apologize in advance.)
2004-12-15 02:25:21 +00:00
device_printf(sc->sc_dev,
"hal qnum %u out of range, max %zu!\n",
net80211 & wireless drivers: remove duplicate defines (noop) * IEEE80211_DIR_DSTODS(wh) -> IEEE80211_IS_DSTODS(wh). * N(a) -> nitems(a). * Remove LE_READ_2(p)/LE_READ_4(p) definitions (and include ieee80211_input.h instead). * <drvname>_TXOP_TO_US(txop) -> IEEE80211_TXOP_TO_US(txop). * Put IEEE80211_RV(v) into ieee80211_proto.h and remove local RV(v) definitions. Submitted by: Andriy Voskoboinyk <s3erios@gmail.com> Differential Revision: https://reviews.freebsd.org/D3705
2015-09-22 02:44:59 +00:00
qnum, nitems(sc->sc_txq));
Update with last year of work.
2004-12-08 17:34:36 +00:00
ath_hal_releasetxqueue(ah, qnum);
return NULL;
}
if (!ATH_TXQ_SETUP(sc, qnum)) {
Close race in handling mcast traffic when operating as an ap with stations in power save: add a new q where mcast frames are stashed and on beacon update (at DTIM) move frames from the mcast q to the cabq and start it. This ensures the cabq is only manipulated in one place. Sponsored by: Hobnob MFC after: 2 weeks
2006-06-26 03:10:45 +00:00
ath_txq_init(sc, &sc->sc_txq[qnum], qnum);
Update with last year of work.
2004-12-08 17:34:36 +00:00
sc->sc_txqsetup |= 1<<qnum;
}
return &sc->sc_txq[qnum];
}
/*
* Setup a hardware data transmit queue for the specified
* access control. The hal may not support all requested
* queues in which case it will return a reference to a
* previously setup queue. We record the mapping from ac's
* to h/w queues for use by ath_tx_start and also track
* the set of h/w queues being used to optimize work in the
* transmit interrupt handler and related routines.
*/
static int
ath_tx_setup(struct ath_softc *sc, int ac, int haltype)
{
struct ath_txq *txq;
net80211 & wireless drivers: remove duplicate defines (noop) * IEEE80211_DIR_DSTODS(wh) -> IEEE80211_IS_DSTODS(wh). * N(a) -> nitems(a). * Remove LE_READ_2(p)/LE_READ_4(p) definitions (and include ieee80211_input.h instead). * <drvname>_TXOP_TO_US(txop) -> IEEE80211_TXOP_TO_US(txop). * Put IEEE80211_RV(v) into ieee80211_proto.h and remove local RV(v) definitions. Submitted by: Andriy Voskoboinyk <s3erios@gmail.com> Differential Revision: https://reviews.freebsd.org/D3705
2015-09-22 02:44:59 +00:00
if (ac >= nitems(sc->sc_ac2q)) {
Make this amd64-clean. sizeof is long on amd64, so things that do a printf of a sizeof, need to use %z to get the correct type on all our platforms. Also, convert integers<->pointers via uintptr_t. (I think Sam's instructions were for me to commit this. If I misunderstood, then I apologize in advance.)
2004-12-15 02:25:21 +00:00
device_printf(sc->sc_dev, "AC %u out of range, max %zu!\n",
net80211 & wireless drivers: remove duplicate defines (noop) * IEEE80211_DIR_DSTODS(wh) -> IEEE80211_IS_DSTODS(wh). * N(a) -> nitems(a). * Remove LE_READ_2(p)/LE_READ_4(p) definitions (and include ieee80211_input.h instead). * <drvname>_TXOP_TO_US(txop) -> IEEE80211_TXOP_TO_US(txop). * Put IEEE80211_RV(v) into ieee80211_proto.h and remove local RV(v) definitions. Submitted by: Andriy Voskoboinyk <s3erios@gmail.com> Differential Revision: https://reviews.freebsd.org/D3705
2015-09-22 02:44:59 +00:00
ac, nitems(sc->sc_ac2q));
Update with last year of work.
2004-12-08 17:34:36 +00:00
return 0;
}
txq = ath_txq_setup(sc, HAL_TX_QUEUE_DATA, haltype);
if (txq != NULL) {
Hoist 802.11 encapsulation up into net80211: o call ieee80211_encap in ieee80211_start so frames passed down to drivers are already encapsulated o remove ieee80211_encap calls in drivers o fixup wi so it recreates the 802.3 head it requires from the 802.11 header contents o move fast-frame aggregation from ath to net80211 (conditional on IEEE80211_SUPPORT_SUPERG): - aggregation is now done in ieee80211_start; it is enabled when the packets/sec exceeds ieee80211_ffppsmin (net.wlan.ffppsmin) and frames are held on a staging queue according to ieee80211_ffagemax (net.wlan.ffagemax) to wait for a frame to combine with - drivers must call back to age/flush the staging queue (ath does this on tx done, at swba, and on rx according to the state of the tx queues and/or the contents of the staging queue) - remove fast-frame-related data structures from ath - add ieee80211_ff_node_init and ieee80211_ff_node_cleanup to handle per-node fast-frames state (we reuse 11n tx ampdu state) o change ieee80211_encap calling convention to include an explicit vap so frames coming through a WDS vap are recognized w/o setting M_WDS With these changes any device able to tx/rx 3Kbyte+ frames can use fast-frames. Reviewed by: thompsa, rpaulo, avatar, imp, sephe
2009-03-30 21:53:27 +00:00
txq->axq_ac = ac;
Update with last year of work.
2004-12-08 17:34:36 +00:00
sc->sc_ac2q[ac] = txq;
return 1;
} else
return 0;
}
/*
* Update WME parameters for a transmit queue.
*/
static int
ath_txq_update(struct ath_softc *sc, int ac)
{
#define ATH_EXPONENT_TO_VALUE(v) ((1<<v)-1)
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
struct ieee80211com *ic = &sc->sc_ic;
Update with last year of work.
2004-12-08 17:34:36 +00:00
struct ath_txq *txq = sc->sc_ac2q[ac];
[ath] Begin using the replacement EDCA functions. As part of ath10k and other chipset support, the EDCA stuff has to be moved to potentially be per-VAP. For hardware that doesn't support it (ie, everything that we currently support) it can just fetch the "current" global EDCA parameters for the NIC. This is one of those parameters that is linked to the currently active channel context / VAP in Linux mac80211 parlance. Tested: * ath(4), STA and AP modes
2017-10-12 21:58:51 +00:00
struct chanAccParams chp;
struct wmeParams *wmep;
Update with last year of work.
2004-12-08 17:34:36 +00:00
struct ath_hal *ah = sc->sc_ah;
HAL_TXQ_INFO qi;
[ath] Begin using the replacement EDCA functions. As part of ath10k and other chipset support, the EDCA stuff has to be moved to potentially be per-VAP. For hardware that doesn't support it (ie, everything that we currently support) it can just fetch the "current" global EDCA parameters for the NIC. This is one of those parameters that is linked to the currently active channel context / VAP in Linux mac80211 parlance. Tested: * ath(4), STA and AP modes
2017-10-12 21:58:51 +00:00
ieee80211_wme_ic_getparams(ic, &chp);
wmep = &chp.cap_wmeParams[ac];
Update with last year of work.
2004-12-08 17:34:36 +00:00
ath_hal_gettxqueueprops(ah, txq->axq_qnum, &qi);
Remove ATH_SUPPORT_TDMA and use IEEE80211_SUPPORT_TDMA instead. It doesn't make much sense to configure driver support w/o net80211. Note this means ath now depends on opt_wlan.h.
2009-03-30 19:23:49 +00:00
#ifdef IEEE80211_SUPPORT_TDMA
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
if (sc->sc_tdma) {
/*
* AIFS is zero so there's no pre-transmit wait. The
* burst time defines the slot duration and is configured
fix comment
2009-06-02 21:12:07 +00:00
* through net80211. The QCU is setup to not do post-xmit
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
* back off, lockout all lower-priority QCU's, and fire
* off the DMA beacon alert timer which is setup based
* on the slot configuration.
*/
qi.tqi_qflags = HAL_TXQ_TXOKINT_ENABLE
| HAL_TXQ_TXERRINT_ENABLE
| HAL_TXQ_TXURNINT_ENABLE
| HAL_TXQ_TXEOLINT_ENABLE
| HAL_TXQ_DBA_GATED
| HAL_TXQ_BACKOFF_DISABLE
| HAL_TXQ_ARB_LOCKOUT_GLOBAL
;
qi.tqi_aifs = 0;
/* XXX +dbaprep? */
qi.tqi_readyTime = sc->sc_tdmaslotlen;
qi.tqi_burstTime = qi.tqi_readyTime;
} else {
#endif
Some more various fixes, etc from my 11n branch. * When doing software TX queue handling and flush, it's possible that the deletion of a VAP (eg a STA shutdown) will queue a "STA Disassociate" frame whilst the interface is being deleted. The VAP is then deleted, and the frame ends up being queued to a node that is freed before it can be TX'ed. Things go awry at this point. There's no way at the present to avoid freeing the underlying node when the vap is being deleted. It's too late in the game. I suspect the real fix is to make sure the frame is software queued with no completion information somehow, so it doesn't link back to a node whose underlying VAP has been freed. For now, we'll just have to do this. * Add some comments showing what's going on. * Move an instance of the ATH_LOCK() around to protect the interrupt set. I'll worry about changing that to a PCU lock later on once the 11n code is in the tree. Sponsored by: Hobnob, Inc.
2011-11-08 19:18:34 +00:00
/*
* XXX shouldn't this just use the default flags
* used in the previous queue setup?
*/
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
qi.tqi_qflags = HAL_TXQ_TXOKINT_ENABLE
| HAL_TXQ_TXERRINT_ENABLE
| HAL_TXQ_TXDESCINT_ENABLE
| HAL_TXQ_TXURNINT_ENABLE
Make sure TXEOL is set on default queues. Otherwise we don't get an interrupt on the completion of a TX queue and this can cause TX hangs / timeout. Sponsored by: Hobnob, Inc.
2011-11-08 21:55:40 +00:00
| HAL_TXQ_TXEOLINT_ENABLE
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
;
qi.tqi_aifs = wmep->wmep_aifsn;
qi.tqi_cwmin = ATH_EXPONENT_TO_VALUE(wmep->wmep_logcwmin);
qi.tqi_cwmax = ATH_EXPONENT_TO_VALUE(wmep->wmep_logcwmax);
qi.tqi_readyTime = 0;
net80211 & wireless drivers: remove duplicate defines (noop) * IEEE80211_DIR_DSTODS(wh) -> IEEE80211_IS_DSTODS(wh). * N(a) -> nitems(a). * Remove LE_READ_2(p)/LE_READ_4(p) definitions (and include ieee80211_input.h instead). * <drvname>_TXOP_TO_US(txop) -> IEEE80211_TXOP_TO_US(txop). * Put IEEE80211_RV(v) into ieee80211_proto.h and remove local RV(v) definitions. Submitted by: Andriy Voskoboinyk <s3erios@gmail.com> Differential Revision: https://reviews.freebsd.org/D3705
2015-09-22 02:44:59 +00:00
qi.tqi_burstTime = IEEE80211_TXOP_TO_US(wmep->wmep_txopLimit);
Remove ATH_SUPPORT_TDMA and use IEEE80211_SUPPORT_TDMA instead. It doesn't make much sense to configure driver support w/o net80211. Note this means ath now depends on opt_wlan.h.
2009-03-30 19:23:49 +00:00
#ifdef IEEE80211_SUPPORT_TDMA
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
}
#endif
DPRINTF(sc, ATH_DEBUG_RESET,
"%s: Q%u qflags 0x%x aifs %u cwmin %u cwmax %u burstTime %u\n",
__func__, txq->axq_qnum, qi.tqi_qflags,
qi.tqi_aifs, qi.tqi_cwmin, qi.tqi_cwmax, qi.tqi_burstTime);
Update with last year of work.
2004-12-08 17:34:36 +00:00
if (!ath_hal_settxqueueprops(ah, txq->axq_qnum, &qi)) {
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
device_printf(sc->sc_dev, "unable to update hardware queue "
"parameters for %s traffic!\n", ieee80211_wme_acnames[ac]);
Update with last year of work.
2004-12-08 17:34:36 +00:00
return 0;
} else {
ath_hal_resettxqueue(ah, txq->axq_qnum); /* push to h/w */
return 1;
}
#undef ATH_EXPONENT_TO_VALUE
}
/*
* Callback from the 802.11 layer to update WME parameters.
*/
Migrate the TDMA management functions out of if_ath.c into if_ath_tdma.c. There's some TX path TDMA code in if_ath_tx.c which should be migrated out, but first I should likely try and verify/fix/repair the TDMA support in 9.x and -HEAD.
2012-05-20 02:49:42 +00:00
int
Update with last year of work.
2004-12-08 17:34:36 +00:00
ath_wme_update(struct ieee80211com *ic)
{
Remove most of the references of ifp->if_softc and replace with references to ic->ic_softc. This is in preparation for gleb's ifnet work. Tested: * ath(4), STA mode * ath(4), hostap mode * make universe
2015-08-17 02:04:11 +00:00
struct ath_softc *sc = ic->ic_softc;
Update with last year of work.
2004-12-08 17:34:36 +00:00
return !ath_txq_update(sc, WME_AC_BE) ||
!ath_txq_update(sc, WME_AC_BK) ||
!ath_txq_update(sc, WME_AC_VI) ||
!ath_txq_update(sc, WME_AC_VO) ? EIO : 0;
}
/*
* Reclaim resources for a setup queue.
*/
static void
ath_tx_cleanupq(struct ath_softc *sc, struct ath_txq *txq)
{
ath_hal_releasetxqueue(sc->sc_ah, txq->axq_qnum);
sc->sc_txqsetup &= ~(1<<txq->axq_qnum);
Overhaul the TXQ locking (again!) as part of some beacon/cabq timing related issues. Moving the TX locking under one lock made things easier to progress on but it had one important side-effect - it increased the latency when handling CABQ setup when sending beacons. This commit introduces a bunch of new changes and a few unrelated changs that are just easier to lump in here. The aim is to have the CABQ locking separate from other locking. The CABQ transmit path in the beacon process thus doesn't have to grab the general TX lock, reducing lock contention/latency and making it more likely that we'll make the beacon TX timing. The second half of this commit is the CABQ related setup changes needed for sane looking EDMA CABQ support. Right now the EDMA TX code naively assumes that only one frame (MPDU or A-MPDU) is being pushed into each FIFO slot. For the CABQ this isn't true - a whole list of frames is being pushed in - and thus CABQ handling breaks very quickly. The aim here is to setup the CABQ list and then push _that list_ to the hardware for transmission. I can then extend the EDMA TX code to stamp that list as being "one" FIFO entry (likely by tagging the last buffer in that list as "FIFO END") so the EDMA TX completion code correctly tracks things. Major: * Migrate the per-TXQ add/removal locking back to per-TXQ, rather than a single lock. * Leave the software queue side of things under the ATH_TX_LOCK lock, (continuing) to serialise things as they are. * Add a new function which is called whenever there's a beacon miss, to print out some debugging. This is primarily designed to help me figure out if the beacon miss events are due to a noisy environment, issues with the PHY/MAC, or other. * Move the CABQ setup/enable to occur _after_ all the VAPs have been looked at. This means that for multiple VAPS in bursted mode, the CABQ gets primed once all VAPs are checked, rather than being primed on the first VAP and then having frames appended after this. Minor: * Add a (disabled) twiddle to let me enable/disable cabq traffic. It's primarily there to let me easily debug what's going on with beacon and CABQ setup/traffic; there's some DMA engine hangs which I'm finally trying to trace down. * Clear bf_next when flushing frames; it should quieten some warnings that show up when a node goes away. Tested: * AR9280, STA/hostap, up to 4 vaps (staggered) * AR5416, STA/hostap, up to 4 vaps (staggered) TODO: * (Lots) more AR9380 and later testing, as I may have missed something here. * Leverage this to fix CABQ hanling for AR9380 and later chips. * Force bursted beaconing on the chips that default to staggered beacons and ensure the CABQ stuff is all sane (eg, the MORE bits that aren't being correctly set when chaining descriptors.)
2013-03-24 00:03:12 +00:00
ATH_TXQ_LOCK_DESTROY(txq);
Update with last year of work.
2004-12-08 17:34:36 +00:00
}
/*
* Reclaim all tx queue resources.
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
*/
Update with last year of work.
2004-12-08 17:34:36 +00:00
static void
ath_tx_cleanup(struct ath_softc *sc)
{
int i;
ATH_TXBUF_LOCK_DESTROY(sc);
for (i = 0; i < HAL_NUM_TX_QUEUES; i++)
if (ATH_TXQ_SETUP(sc, i))
ath_tx_cleanupq(sc, &sc->sc_txq[i]);
}
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
honor net80211 mcast tx rate MFC after: 2 weeks
2006-02-09 21:15:36 +00:00
/*
optimize ath_tx_findrix: there's no need to walk the rates table as sc_rixmap is an inverse map NB: could eliminate the check for an invalid rate by filling in 0 for invalid entries but the rate control modules use it to identify bogus rates so leave it for now
2009-05-07 00:35:32 +00:00
* Return h/w rate index for an IEEE rate (w/o basic rate bit)
* using the current rates in sc_rixmap.
honor net80211 mcast tx rate MFC after: 2 weeks
2006-02-09 21:15:36 +00:00
*/
Migrate the TX path code out of if_ath and into a separate source file. There's two reasons for this: * the raw and non-raw TX path shares a lot of duplicate code which should be refactored; * the 11n-ready chip TX path needs a little reworking.
2011-01-29 11:35:23 +00:00
int
optimize ath_tx_findrix: there's no need to walk the rates table as sc_rixmap is an inverse map NB: could eliminate the check for an invalid rate by filling in 0 for invalid entries but the rate control modules use it to identify bogus rates so leave it for now
2009-05-07 00:35:32 +00:00
ath_tx_findrix(const struct ath_softc *sc, uint8_t rate)
honor net80211 mcast tx rate MFC after: 2 weeks
2006-02-09 21:15:36 +00:00
{
optimize ath_tx_findrix: there's no need to walk the rates table as sc_rixmap is an inverse map NB: could eliminate the check for an invalid rate by filling in 0 for invalid entries but the rate control modules use it to identify bogus rates so leave it for now
2009-05-07 00:35:32 +00:00
int rix = sc->sc_rixmap[rate];
/* NB: return lowest rix for invalid rate */
return (rix == 0xff ? 0 : rix);
honor net80211 mcast tx rate MFC after: 2 weeks
2006-02-09 21:15:36 +00:00
}
Refactor out the TX buffer management and completion code in preparation for TX aggregation. * Add in logic which calls ath_buf bf->bf_comp if it's set. This allows for AMPDU (and RIFS, and FF, if someone desires) code to handle completion - which includes freeing subframes, retransmitting subframes, etc. * Break out the buffer free, buffer busy/unbusy default completion handler code into separate functions. This allows bf_comp methods to free and unbusy each subframe ath_buf as required. * Break out the statistics update code into a separate function, just to clean up the TX completion path a little. Sponsored by: Hobnob, Inc.
2011-11-08 21:49:33 +00:00
static void
ath_tx_update_stats(struct ath_softc *sc, struct ath_tx_status *ts,
struct ath_buf *bf)
{
struct ieee80211_node *ni = bf->bf_node;
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
struct ieee80211com *ic = &sc->sc_ic;
Refactor out the TX buffer management and completion code in preparation for TX aggregation. * Add in logic which calls ath_buf bf->bf_comp if it's set. This allows for AMPDU (and RIFS, and FF, if someone desires) code to handle completion - which includes freeing subframes, retransmitting subframes, etc. * Break out the buffer free, buffer busy/unbusy default completion handler code into separate functions. This allows bf_comp methods to free and unbusy each subframe ath_buf as required. * Break out the statistics update code into a separate function, just to clean up the TX completion path a little. Sponsored by: Hobnob, Inc.
2011-11-08 21:49:33 +00:00
int sr, lr, pri;
if (ts->ts_status == 0) {
u_int8_t txant = ts->ts_antenna;
sc->sc_stats.ast_ant_tx[txant]++;
sc->sc_ant_tx[txant]++;
if (ts->ts_finaltsi != 0)
sc->sc_stats.ast_tx_altrate++;
[ath] initial station side quiet IE support. This implements hardware assisted quiet IE support. Quiet time is an optional interval on DFS channels (but doesn't have to be DFS only channels! sigh) where the station and AP can be quiet in order to allow for channel utilisation measurements. Typically that's stuff like radar detection, spectral scan, other-BSS frame sniffing, checking how busy the air is, etc. The hardware implements it as one of the generic timers, which is supplied a period, offset from the trigger period and duration to stay quiet. The AP can announce quiet time configurations which change, and so this code also tracks that. Implementation details: * track the current quiet time IE * compare the new one against the previous one - if only the TBTT counter changes, don't update things * If tbttcount=1 then program it into the hardware - that is when it is easiest to program the correct starting offset (one TBTT + configured offset). * .. later on check to see if it can be done on any tbttcount * If the IE goes away then remove the quiet timer and clear the config * Upon reset, state change, new beacon - clear quiet time IE and just let it resync from the next beacon. History: This was work done initially by sibridgetech.com in 2011/2012/2013 as part of some FreeBSD wifi DFS contracting work they had for a third party. They implemented the net80211 quiet time IE pieces and had some test code for the station side which didn't entirely use the timers correctly. I figured out how to use the timers correctly without stopping/starting the transmit DMA engine each time. When done correctly, the timer just needs to be programmed once and left alone until the next configuration change. So, thanks to Himali Patel and Parthiv Shah for their work way back then. I finally figured it out and finished it! TODO: * Now, I'd rather net80211 did the quiet time IE tracking and parsing, pushing configurations into the driver is needed. I'll look at doing that in a subsequent update. * This doesn't handle multiple quiet time IEs, which will currently just mess things up. I'll look into supporting that in the future (at least by only obeying "one" of them, and then ignoring subsequent IEs in a beacon/probe frame.) * This also implements the STA side and not the AP side - the AP side will come later, and involves taking various other intervals into account (eg the beacon offset for multi-VAP modes, the SWBA time, etc, etc) as well as obtaining the configuration when a beacon is configured/generated rather than "hearing" an IE. * .. investigate supporting quiet IE in mesh, tdma, ibss modes * .. investigate supporting quiet IE for non-DFS channels (so this can be done for say, 2GHz channels.) * Chances are i should commit NULL methods for the ar5210, ar5211 HALs.. Tested: * AR9380, STA mode - announcing quiet, removing quiet, changing quite time config, whilst doing iperf testing; * AR9380, AP mode.
2017-02-09 23:15:11 +00:00
/* XXX TODO: should do per-pri conuters */
Refactor out the TX buffer management and completion code in preparation for TX aggregation. * Add in logic which calls ath_buf bf->bf_comp if it's set. This allows for AMPDU (and RIFS, and FF, if someone desires) code to handle completion - which includes freeing subframes, retransmitting subframes, etc. * Break out the buffer free, buffer busy/unbusy default completion handler code into separate functions. This allows bf_comp methods to free and unbusy each subframe ath_buf as required. * Break out the statistics update code into a separate function, just to clean up the TX completion path a little. Sponsored by: Hobnob, Inc.
2011-11-08 21:49:33 +00:00
pri = M_WME_GETAC(bf->bf_m);
if (pri >= WME_AC_VO)
ic->ic_wme.wme_hipri_traffic++;
[ath] initial station side quiet IE support. This implements hardware assisted quiet IE support. Quiet time is an optional interval on DFS channels (but doesn't have to be DFS only channels! sigh) where the station and AP can be quiet in order to allow for channel utilisation measurements. Typically that's stuff like radar detection, spectral scan, other-BSS frame sniffing, checking how busy the air is, etc. The hardware implements it as one of the generic timers, which is supplied a period, offset from the trigger period and duration to stay quiet. The AP can announce quiet time configurations which change, and so this code also tracks that. Implementation details: * track the current quiet time IE * compare the new one against the previous one - if only the TBTT counter changes, don't update things * If tbttcount=1 then program it into the hardware - that is when it is easiest to program the correct starting offset (one TBTT + configured offset). * .. later on check to see if it can be done on any tbttcount * If the IE goes away then remove the quiet timer and clear the config * Upon reset, state change, new beacon - clear quiet time IE and just let it resync from the next beacon. History: This was work done initially by sibridgetech.com in 2011/2012/2013 as part of some FreeBSD wifi DFS contracting work they had for a third party. They implemented the net80211 quiet time IE pieces and had some test code for the station side which didn't entirely use the timers correctly. I figured out how to use the timers correctly without stopping/starting the transmit DMA engine each time. When done correctly, the timer just needs to be programmed once and left alone until the next configuration change. So, thanks to Himali Patel and Parthiv Shah for their work way back then. I finally figured it out and finished it! TODO: * Now, I'd rather net80211 did the quiet time IE tracking and parsing, pushing configurations into the driver is needed. I'll look at doing that in a subsequent update. * This doesn't handle multiple quiet time IEs, which will currently just mess things up. I'll look into supporting that in the future (at least by only obeying "one" of them, and then ignoring subsequent IEs in a beacon/probe frame.) * This also implements the STA side and not the AP side - the AP side will come later, and involves taking various other intervals into account (eg the beacon offset for multi-VAP modes, the SWBA time, etc, etc) as well as obtaining the configuration when a beacon is configured/generated rather than "hearing" an IE. * .. investigate supporting quiet IE in mesh, tdma, ibss modes * .. investigate supporting quiet IE for non-DFS channels (so this can be done for say, 2GHz channels.) * Chances are i should commit NULL methods for the ar5210, ar5211 HALs.. Tested: * AR9380, STA mode - announcing quiet, removing quiet, changing quite time config, whilst doing iperf testing; * AR9380, AP mode.
2017-02-09 23:15:11 +00:00
Remove duplicate txflags field from ath_buf. rename bf_state.bfs_flags to bf_state.bfs_txflags, as that is what it effectively is.
2012-04-07 02:01:26 +00:00
if ((bf->bf_state.bfs_txflags & HAL_TXDESC_NOACK) == 0)
Refactor out the TX buffer management and completion code in preparation for TX aggregation. * Add in logic which calls ath_buf bf->bf_comp if it's set. This allows for AMPDU (and RIFS, and FF, if someone desires) code to handle completion - which includes freeing subframes, retransmitting subframes, etc. * Break out the buffer free, buffer busy/unbusy default completion handler code into separate functions. This allows bf_comp methods to free and unbusy each subframe ath_buf as required. * Break out the statistics update code into a separate function, just to clean up the TX completion path a little. Sponsored by: Hobnob, Inc.
2011-11-08 21:49:33 +00:00
ni->ni_inact = ni->ni_inact_reload;
} else {
if (ts->ts_status & HAL_TXERR_XRETRY)
sc->sc_stats.ast_tx_xretries++;
if (ts->ts_status & HAL_TXERR_FIFO)
sc->sc_stats.ast_tx_fifoerr++;
if (ts->ts_status & HAL_TXERR_FILT)
sc->sc_stats.ast_tx_filtered++;
if (ts->ts_status & HAL_TXERR_XTXOP)
sc->sc_stats.ast_tx_xtxop++;
if (ts->ts_status & HAL_TXERR_TIMER_EXPIRED)
sc->sc_stats.ast_tx_timerexpired++;
if (bf->bf_m->m_flags & M_FF)
sc->sc_stats.ast_ff_txerr++;
}
/* XXX when is this valid? */
CFG_ERR, DATA_UNDERRUN and DELIM_UNDERRUN are all flags, rather than part of ts_status. Thus: * make sure we decode them from ts_flags, rather than ts_status; * make sure we decode them regardless of whether there's an error or not. This correctly exposes descriptor configuration errors, TX delimiter underruns and TX data underruns.
2013-02-20 11:14:55 +00:00
if (ts->ts_flags & HAL_TX_DESC_CFG_ERR)
Refactor out the TX buffer management and completion code in preparation for TX aggregation. * Add in logic which calls ath_buf bf->bf_comp if it's set. This allows for AMPDU (and RIFS, and FF, if someone desires) code to handle completion - which includes freeing subframes, retransmitting subframes, etc. * Break out the buffer free, buffer busy/unbusy default completion handler code into separate functions. This allows bf_comp methods to free and unbusy each subframe ath_buf as required. * Break out the statistics update code into a separate function, just to clean up the TX completion path a little. Sponsored by: Hobnob, Inc.
2011-11-08 21:49:33 +00:00
sc->sc_stats.ast_tx_desccfgerr++;
CFG_ERR, DATA_UNDERRUN and DELIM_UNDERRUN are all flags, rather than part of ts_status. Thus: * make sure we decode them from ts_flags, rather than ts_status; * make sure we decode them regardless of whether there's an error or not. This correctly exposes descriptor configuration errors, TX delimiter underruns and TX data underruns.
2013-02-20 11:14:55 +00:00
/*
* This can be valid for successful frame transmission!
* If there's a TX FIFO underrun during aggregate transmission,
* the MAC will pad the rest of the aggregate with delimiters.
* If a BA is returned, the frame is marked as "OK" and it's up
* to the TX completion code to notice which frames weren't
* successfully transmitted.
*/
if (ts->ts_flags & HAL_TX_DATA_UNDERRUN)
sc->sc_stats.ast_tx_data_underrun++;
if (ts->ts_flags & HAL_TX_DELIM_UNDERRUN)
sc->sc_stats.ast_tx_delim_underrun++;
Refactor out the TX buffer management and completion code in preparation for TX aggregation. * Add in logic which calls ath_buf bf->bf_comp if it's set. This allows for AMPDU (and RIFS, and FF, if someone desires) code to handle completion - which includes freeing subframes, retransmitting subframes, etc. * Break out the buffer free, buffer busy/unbusy default completion handler code into separate functions. This allows bf_comp methods to free and unbusy each subframe ath_buf as required. * Break out the statistics update code into a separate function, just to clean up the TX completion path a little. Sponsored by: Hobnob, Inc.
2011-11-08 21:49:33 +00:00
sr = ts->ts_shortretry;
lr = ts->ts_longretry;
sc->sc_stats.ast_tx_shortretry += sr;
sc->sc_stats.ast_tx_longretry += lr;
}
/*
* The default completion. If fail is 1, this means
* "please don't retry the frame, and just return -1 status
* to the net80211 stack.
*/
void
ath_tx_default_comp(struct ath_softc *sc, struct ath_buf *bf, int fail)
{
struct ath_tx_status *ts = &bf->bf_status.ds_txstat;
int st;
if (fail == 1)
st = -1;
else
Remove duplicate txflags field from ath_buf. rename bf_state.bfs_flags to bf_state.bfs_txflags, as that is what it effectively is.
2012-04-07 02:01:26 +00:00
st = ((bf->bf_state.bfs_txflags & HAL_TXDESC_NOACK) == 0) ?
Refactor out the TX buffer management and completion code in preparation for TX aggregation. * Add in logic which calls ath_buf bf->bf_comp if it's set. This allows for AMPDU (and RIFS, and FF, if someone desires) code to handle completion - which includes freeing subframes, retransmitting subframes, etc. * Break out the buffer free, buffer busy/unbusy default completion handler code into separate functions. This allows bf_comp methods to free and unbusy each subframe ath_buf as required. * Break out the statistics update code into a separate function, just to clean up the TX completion path a little. Sponsored by: Hobnob, Inc.
2011-11-08 21:49:33 +00:00
ts->ts_status : HAL_TXERR_XRETRY;
Disable debugging entries about BAW issues. I haven't seen any issues to do with BAW tracking in the last 9 months or so.
2013-02-21 21:47:35 +00:00
#if 0
Refactor out the TX buffer management and completion code in preparation for TX aggregation. * Add in logic which calls ath_buf bf->bf_comp if it's set. This allows for AMPDU (and RIFS, and FF, if someone desires) code to handle completion - which includes freeing subframes, retransmitting subframes, etc. * Break out the buffer free, buffer busy/unbusy default completion handler code into separate functions. This allows bf_comp methods to free and unbusy each subframe ath_buf as required. * Break out the statistics update code into a separate function, just to clean up the TX completion path a little. Sponsored by: Hobnob, Inc.
2011-11-08 21:49:33 +00:00
if (bf->bf_state.bfs_dobaw)
device_printf(sc->sc_dev,
Fix a couple of debugging outputs. * printf -> device_printf * print the buffer pointer and sequence number for any buffer that wasn't correctly tidied up before it was freed. This is to aid in some current SMP TX debugging stalls. PR: kern/166190
2012-03-16 23:24:27 +00:00
"%s: bf %p: seqno %d: dobaw should've been cleared!\n",
__func__,
bf,
SEQNO(bf->bf_state.bfs_seqno));
Disable debugging entries about BAW issues. I haven't seen any issues to do with BAW tracking in the last 9 months or so.
2013-02-21 21:47:35 +00:00
#endif
Refactor out the TX buffer management and completion code in preparation for TX aggregation. * Add in logic which calls ath_buf bf->bf_comp if it's set. This allows for AMPDU (and RIFS, and FF, if someone desires) code to handle completion - which includes freeing subframes, retransmitting subframes, etc. * Break out the buffer free, buffer busy/unbusy default completion handler code into separate functions. This allows bf_comp methods to free and unbusy each subframe ath_buf as required. * Break out the statistics update code into a separate function, just to clean up the TX completion path a little. Sponsored by: Hobnob, Inc.
2011-11-08 21:49:33 +00:00
if (bf->bf_next != NULL)
device_printf(sc->sc_dev,
Fix a couple of debugging outputs. * printf -> device_printf * print the buffer pointer and sequence number for any buffer that wasn't correctly tidied up before it was freed. This is to aid in some current SMP TX debugging stalls. PR: kern/166190
2012-03-16 23:24:27 +00:00
"%s: bf %p: seqno %d: bf_next not NULL!\n",
__func__,
bf,
SEQNO(bf->bf_state.bfs_seqno));
Refactor out the TX buffer management and completion code in preparation for TX aggregation. * Add in logic which calls ath_buf bf->bf_comp if it's set. This allows for AMPDU (and RIFS, and FF, if someone desires) code to handle completion - which includes freeing subframes, retransmitting subframes, etc. * Break out the buffer free, buffer busy/unbusy default completion handler code into separate functions. This allows bf_comp methods to free and unbusy each subframe ath_buf as required. * Break out the statistics update code into a separate function, just to clean up the TX completion path a little. Sponsored by: Hobnob, Inc.
2011-11-08 21:49:33 +00:00
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
/*
* Check if the node software queue is empty; if so
* then clear the TIM.
*
* This needs to be done before the buffer is freed as
* otherwise the node reference will have been released
* and the node may not actually exist any longer.
*
* XXX I don't like this belonging here, but it's cleaner
* to do it here right now then all the other places
* where ath_tx_default_comp() is called.
*
* XXX TODO: during drain, ensure that the callback is
* being called so we get a chance to update the TIM.
*/
Begin tidying up the reassociation and node sleep/wakeup paths. * Move the node sleep/wake state under the TX lock rather than the node lock. Let's leave the node lock protecting rate control only for now. * When reassociating, various state needs to be cleared. For example, the aggregate session needs to be torn down, including any pending aggregation negotiation and BAR TX waiting. * .. and we need to do a "cleanup" pass since frames in the hardware TX queue need to be transmitted. Modify ath_tx_tid_cleanup() to be called with the TX lock held and push frames into a completion list. This allows for the cleanup to be done atomically for all TIDs in a node rather than grabbing and releasing the TX lock each time.
2013-05-13 18:56:04 +00:00
if (bf->bf_node) {
ATH_TX_LOCK(sc);
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
ath_tx_update_tim(sc, bf->bf_node, 0);
Begin tidying up the reassociation and node sleep/wakeup paths. * Move the node sleep/wake state under the TX lock rather than the node lock. Let's leave the node lock protecting rate control only for now. * When reassociating, various state needs to be cleared. For example, the aggregate session needs to be torn down, including any pending aggregation negotiation and BAR TX waiting. * .. and we need to do a "cleanup" pass since frames in the hardware TX queue need to be transmitted. Modify ath_tx_tid_cleanup() to be called with the TX lock held and push frames into a completion list. This allows for the cleanup to be done atomically for all TIDs in a node rather than grabbing and releasing the TX lock each time.
2013-05-13 18:56:04 +00:00
ATH_TX_UNLOCK(sc);
}
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
Refactor out the TX buffer management and completion code in preparation for TX aggregation. * Add in logic which calls ath_buf bf->bf_comp if it's set. This allows for AMPDU (and RIFS, and FF, if someone desires) code to handle completion - which includes freeing subframes, retransmitting subframes, etc. * Break out the buffer free, buffer busy/unbusy default completion handler code into separate functions. This allows bf_comp methods to free and unbusy each subframe ath_buf as required. * Break out the statistics update code into a separate function, just to clean up the TX completion path a little. Sponsored by: Hobnob, Inc.
2011-11-08 21:49:33 +00:00
/*
* Do any tx complete callback. Note this must
* be done before releasing the node reference.
* This will free the mbuf, release the net80211
* node and recycle the ath_buf.
*/
ath_tx_freebuf(sc, bf, st);
}
Introduce TX aggregation and software TX queue management for Atheros AR5416 and later wireless devices. This is a very large commit - the complete history can be found in the user/adrian/if_ath_tx branch. Legacy (ie, pre-AR5416) devices also use the per-software TXQ support and (in theory) can support non-aggregation ADDBA sessions. However, the net80211 stack doesn't currently support this. In summary: TX path: * queued frames normally go onto a per-TID, per-node queue * some special frames (eg ADDBA control frames) are thrown directly onto the relevant hardware queue so they can go out before any software queued frames are queued. * Add methods to create, suspend, resume and tear down an aggregation session. * Add in software retransmission of both normal and aggregate frames. * Add in completion handling of aggregate frames, including parsing the block ack bitmap provided by the hardware. * Write an aggregation function which can assemble frames into an aggregate based on the selected rate control and channel configuration. * The per-TID queues are locked based on their target hardware TX queue. This matches what ath9k/atheros does, and thus simplified porting over some of the aggregation logic. * When doing TX aggregation, stick the sequence number allocation in the TX path rather than net80211 TX path, and protect it by the TXQ lock. Rate control: * Delay rate control selection until the frame is about to be queued to the hardware, so retried frames can have their rate control choices changed. Frames with a static rate control selection have that applied before each TX, just to simplify the TX path (ie, not have "static" and "dynamic" rate control special cased.) * Teach ath_rate_sample about aggregates - both completion and errors. * Add an EWMA for tracking what the current "good" MCS rate is based on failure rates. Misc: * Introduce a bunch of dirty hacks and workarounds so TID mapping and net80211 frame inspection can be kept out of the net80211 layer. Because of the way this code works (and it's from Atheros and Linux ath9k), there is a consistent, 1:1 mapping between TID and AC. So we need to ensure that frames going to a specific TID will _always_ end up on the right AC, and vice versa, or the completion/locking will simply get very confused. I plan on addressing this mess in the future. Known issues: * There is no BAR frame transmission just yet. A whole lot of tidying up needs to occur before BAR frame TX can occur in the "correct" place - ie, once the TID TX queue has been drained. * Interface reset/purge/etc results in frames in the TX and RX queues being removed. This creates holes in the sequence numbers being assigned and the TX/RX AMPDU code (on either side) just hangs. * There's no filtered frame support at the present moment, so stations going into power saving mode will simply have a number of frames dropped - likely resulting in a traffic "hang". * Raw frame TX is going to just not function with 11n aggregation. Likely this needs to be modified to always override the sequence number if the frame is going into an aggregation session. However, general raw frame injection currently doesn't work in general in net80211, so let's just ignore this for now until this is sorted out. * HT protection is just not implemented and won't be until the above is sorted out. In addition, the AR5416 has issues RTS protecting large aggregates (anything >8k), so the work around needs to be ported and tested. Thus, this will be put on hold until the above work is complete. * The rate control module 'sample' is the only currently supported module; onoe/amrr haven't been tested and have likely bit rotted a little. I'll follow up with some commits to make them work again for non-11n rates, but they won't be updated to handle 11n and aggregation. If someone wishes to do so then they're welcome to send along patches. * .. and "sample" doesn't really do a good job of 11n TX. Specifically, the metrics used (packet TX time and failure/success rates) isn't as useful for 11n. It's likely that it should be extended to take into account the aggregate throughput possible and then choose a rate which maximises that. Ie, it may be acceptable for a higher MCS rate with a higher failure to be used if it gives a more acceptable throughput/latency then a lower MCS rate @ a lower error rate. Again, patches will be gratefully accepted. Because of this, ATH_ENABLE_11N is still not enabled by default. Sponsored by: Hobnob, Inc. Obtained from: Linux, Atheros
2011-11-08 22:43:13 +00:00
/*
* Update rate control with the given completion status.
*/
void
ath_tx_update_ratectrl(struct ath_softc *sc, struct ieee80211_node *ni,
struct ath_rc_series *rc, struct ath_tx_status *ts, int frmlen,
int nframes, int nbad)
{
struct ath_node *an;
/* Only for unicast frames */
if (ni == NULL)
return;
an = ATH_NODE(ni);
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
ATH_NODE_UNLOCK_ASSERT(an);
Introduce TX aggregation and software TX queue management for Atheros AR5416 and later wireless devices. This is a very large commit - the complete history can be found in the user/adrian/if_ath_tx branch. Legacy (ie, pre-AR5416) devices also use the per-software TXQ support and (in theory) can support non-aggregation ADDBA sessions. However, the net80211 stack doesn't currently support this. In summary: TX path: * queued frames normally go onto a per-TID, per-node queue * some special frames (eg ADDBA control frames) are thrown directly onto the relevant hardware queue so they can go out before any software queued frames are queued. * Add methods to create, suspend, resume and tear down an aggregation session. * Add in software retransmission of both normal and aggregate frames. * Add in completion handling of aggregate frames, including parsing the block ack bitmap provided by the hardware. * Write an aggregation function which can assemble frames into an aggregate based on the selected rate control and channel configuration. * The per-TID queues are locked based on their target hardware TX queue. This matches what ath9k/atheros does, and thus simplified porting over some of the aggregation logic. * When doing TX aggregation, stick the sequence number allocation in the TX path rather than net80211 TX path, and protect it by the TXQ lock. Rate control: * Delay rate control selection until the frame is about to be queued to the hardware, so retried frames can have their rate control choices changed. Frames with a static rate control selection have that applied before each TX, just to simplify the TX path (ie, not have "static" and "dynamic" rate control special cased.) * Teach ath_rate_sample about aggregates - both completion and errors. * Add an EWMA for tracking what the current "good" MCS rate is based on failure rates. Misc: * Introduce a bunch of dirty hacks and workarounds so TID mapping and net80211 frame inspection can be kept out of the net80211 layer. Because of the way this code works (and it's from Atheros and Linux ath9k), there is a consistent, 1:1 mapping between TID and AC. So we need to ensure that frames going to a specific TID will _always_ end up on the right AC, and vice versa, or the completion/locking will simply get very confused. I plan on addressing this mess in the future. Known issues: * There is no BAR frame transmission just yet. A whole lot of tidying up needs to occur before BAR frame TX can occur in the "correct" place - ie, once the TID TX queue has been drained. * Interface reset/purge/etc results in frames in the TX and RX queues being removed. This creates holes in the sequence numbers being assigned and the TX/RX AMPDU code (on either side) just hangs. * There's no filtered frame support at the present moment, so stations going into power saving mode will simply have a number of frames dropped - likely resulting in a traffic "hang". * Raw frame TX is going to just not function with 11n aggregation. Likely this needs to be modified to always override the sequence number if the frame is going into an aggregation session. However, general raw frame injection currently doesn't work in general in net80211, so let's just ignore this for now until this is sorted out. * HT protection is just not implemented and won't be until the above is sorted out. In addition, the AR5416 has issues RTS protecting large aggregates (anything >8k), so the work around needs to be ported and tested. Thus, this will be put on hold until the above work is complete. * The rate control module 'sample' is the only currently supported module; onoe/amrr haven't been tested and have likely bit rotted a little. I'll follow up with some commits to make them work again for non-11n rates, but they won't be updated to handle 11n and aggregation. If someone wishes to do so then they're welcome to send along patches. * .. and "sample" doesn't really do a good job of 11n TX. Specifically, the metrics used (packet TX time and failure/success rates) isn't as useful for 11n. It's likely that it should be extended to take into account the aggregate throughput possible and then choose a rate which maximises that. Ie, it may be acceptable for a higher MCS rate with a higher failure to be used if it gives a more acceptable throughput/latency then a lower MCS rate @ a lower error rate. Again, patches will be gratefully accepted. Because of this, ATH_ENABLE_11N is still not enabled by default. Sponsored by: Hobnob, Inc. Obtained from: Linux, Atheros
2011-11-08 22:43:13 +00:00
if ((ts->ts_status & HAL_TXERR_FILT) == 0) {
ATH_NODE_LOCK(an);
ath_rate_tx_complete(sc, an, rc, ts, frmlen, nframes, nbad);
ATH_NODE_UNLOCK(an);
}
}
Break out the TX completion code into a separate function, so it can be re-used by the upcoming EDMA TX completion code. Make ath_stoptxdma() public, again so the EDMA TX code can use it. Don't check for the TXQ bitmap in the ISR when doing EDMA work as it doesn't apply for EDMA.
2012-08-14 22:32:20 +00:00
/*
* Process the completion of the given buffer.
*
* This calls the rate control update and then the buffer completion.
* This will either free the buffer or requeue it. In any case, the
* bf pointer should be treated as invalid after this function is called.
*/
void
ath_tx_process_buf_completion(struct ath_softc *sc, struct ath_txq *txq,
struct ath_tx_status *ts, struct ath_buf *bf)
{
struct ieee80211_node *ni = bf->bf_node;
Delete the per-TXQ locks and replace them with a single TX lock. I couldn't think of a way to maintain the hardware TXQ locks _and_ layer on top of that per-TXQ software queuing and any other kind of fine-grained locks (eg per-TID, or per-node locks.) So for now, to facilitate some further code refactoring and development as part of the final push to get software queue ps-poll and u-apsd handling into this driver, just do away with them entirely. I may eventually bring them back at some point, when it looks slightly more architectually cleaner to do so. But as it stands at the present, it's not really buying us much: * in order to properly serialise things and not get bitten by scheduling and locking interactions with things higher up in the stack, we need to wrap the whole TX path in a long held lock. Otherwise we can end up being pre-empted during frame handling, resulting in some out of order frame handling between sequence number allocation and encryption handling (ie, the seqno and the CCMP IV get out of sequence); * .. so whilst that's the case, holding the lock for that long means that we're acquiring and releasing the TXQ lock _inside_ that context; * And we also acquire it per-frame during frame completion, but we currently can't hold the lock for the duration of the TX completion as we need to call net80211 layer things with the locks _unheld_ to avoid LOR. * .. the other places were grab that lock are reset/flush, which don't happen often. My eventual aim is to change the TX path so all rejected frame transmissions and all frame completions result in any ieee80211_free_node() calls to occur outside of the TX lock; then I can cut back on the amount of locking that goes on here. There may be some LORs that occur when ieee80211_free_node() is called when the TX queue path fails; I'll begin to address these in follow-up commits.
2012-12-02 06:24:08 +00:00
ATH_TX_UNLOCK_ASSERT(sc);
Fix the holding descriptor logic to actually be "right" (for values of "right".) Flip back on the "always continue TX DMA using the holding descriptor" code - by always setting ATH_BUF_BUSY and never setting axq_link to NULL. Since the holding descriptor is accessed via txq->axq_link and _that_ is done behind the TXQ lock rather than the TX path lock, the holding descriptor stuff itself needs to be behind the TXQ lock. So, do the mental gymnastics needed to do this. I've not seen any of the hardware failures that I was seeing when I last tried to do this. Tested: * AR5416, STA mode
2013-05-08 21:23:51 +00:00
ATH_TXQ_UNLOCK_ASSERT(txq);
Break out the TX completion code into a separate function, so it can be re-used by the upcoming EDMA TX completion code. Make ath_stoptxdma() public, again so the EDMA TX code can use it. Don't check for the TXQ bitmap in the ISR when doing EDMA work as it doesn't apply for EDMA.
2012-08-14 22:32:20 +00:00
/* If unicast frame, update general statistics */
if (ni != NULL) {
/* update statistics */
ath_tx_update_stats(sc, ts, bf);
}
/*
* Call the completion handler.
* The completion handler is responsible for
* calling the rate control code.
*
* Frames with no completion handler get the
* rate control code called here.
*/
if (bf->bf_comp == NULL) {
if ((ts->ts_status & HAL_TXERR_FILT) == 0 &&
(bf->bf_state.bfs_txflags & HAL_TXDESC_NOACK) == 0) {
/*
* XXX assume this isn't an aggregate
* frame.
*/
ath_tx_update_ratectrl(sc, ni,
bf->bf_state.bfs_rc, ts,
bf->bf_state.bfs_pktlen, 1,
(ts->ts_status == 0 ? 0 : 1));
}
ath_tx_default_comp(sc, bf, 0);
} else
bf->bf_comp(sc, bf, 0);
}
Update with last year of work.
2004-12-08 17:34:36 +00:00
/*
* Process completed xmit descriptors from the specified queue.
Introduce TX aggregation and software TX queue management for Atheros AR5416 and later wireless devices. This is a very large commit - the complete history can be found in the user/adrian/if_ath_tx branch. Legacy (ie, pre-AR5416) devices also use the per-software TXQ support and (in theory) can support non-aggregation ADDBA sessions. However, the net80211 stack doesn't currently support this. In summary: TX path: * queued frames normally go onto a per-TID, per-node queue * some special frames (eg ADDBA control frames) are thrown directly onto the relevant hardware queue so they can go out before any software queued frames are queued. * Add methods to create, suspend, resume and tear down an aggregation session. * Add in software retransmission of both normal and aggregate frames. * Add in completion handling of aggregate frames, including parsing the block ack bitmap provided by the hardware. * Write an aggregation function which can assemble frames into an aggregate based on the selected rate control and channel configuration. * The per-TID queues are locked based on their target hardware TX queue. This matches what ath9k/atheros does, and thus simplified porting over some of the aggregation logic. * When doing TX aggregation, stick the sequence number allocation in the TX path rather than net80211 TX path, and protect it by the TXQ lock. Rate control: * Delay rate control selection until the frame is about to be queued to the hardware, so retried frames can have their rate control choices changed. Frames with a static rate control selection have that applied before each TX, just to simplify the TX path (ie, not have "static" and "dynamic" rate control special cased.) * Teach ath_rate_sample about aggregates - both completion and errors. * Add an EWMA for tracking what the current "good" MCS rate is based on failure rates. Misc: * Introduce a bunch of dirty hacks and workarounds so TID mapping and net80211 frame inspection can be kept out of the net80211 layer. Because of the way this code works (and it's from Atheros and Linux ath9k), there is a consistent, 1:1 mapping between TID and AC. So we need to ensure that frames going to a specific TID will _always_ end up on the right AC, and vice versa, or the completion/locking will simply get very confused. I plan on addressing this mess in the future. Known issues: * There is no BAR frame transmission just yet. A whole lot of tidying up needs to occur before BAR frame TX can occur in the "correct" place - ie, once the TID TX queue has been drained. * Interface reset/purge/etc results in frames in the TX and RX queues being removed. This creates holes in the sequence numbers being assigned and the TX/RX AMPDU code (on either side) just hangs. * There's no filtered frame support at the present moment, so stations going into power saving mode will simply have a number of frames dropped - likely resulting in a traffic "hang". * Raw frame TX is going to just not function with 11n aggregation. Likely this needs to be modified to always override the sequence number if the frame is going into an aggregation session. However, general raw frame injection currently doesn't work in general in net80211, so let's just ignore this for now until this is sorted out. * HT protection is just not implemented and won't be until the above is sorted out. In addition, the AR5416 has issues RTS protecting large aggregates (anything >8k), so the work around needs to be ported and tested. Thus, this will be put on hold until the above work is complete. * The rate control module 'sample' is the only currently supported module; onoe/amrr haven't been tested and have likely bit rotted a little. I'll follow up with some commits to make them work again for non-11n rates, but they won't be updated to handle 11n and aggregation. If someone wishes to do so then they're welcome to send along patches. * .. and "sample" doesn't really do a good job of 11n TX. Specifically, the metrics used (packet TX time and failure/success rates) isn't as useful for 11n. It's likely that it should be extended to take into account the aggregate throughput possible and then choose a rate which maximises that. Ie, it may be acceptable for a higher MCS rate with a higher failure to be used if it gives a more acceptable throughput/latency then a lower MCS rate @ a lower error rate. Again, patches will be gratefully accepted. Because of this, ATH_ENABLE_11N is still not enabled by default. Sponsored by: Hobnob, Inc. Obtained from: Linux, Atheros
2011-11-08 22:43:13 +00:00
* Kick the packet scheduler if needed. This can occur from this
* particular task.
Update with last year of work.
2004-12-08 17:34:36 +00:00
*/
Break out ath_draintxq() into a method and un-methodize ath_tx_processq(). Now that I understand what's going on with this, I've realised that it's going to be quite difficult to implement a processq method in the EDMA case. Because there's a separate TX status FIFO, I can't just run processq() on each EDMA TXQ to see what's finished. i have to actually run the TX status queue and handle individual TXQs. So: * unmethodize ath_tx_processq(); * leave ath_tx_draintxq() as a method, as it only uses the completion status for debugging rather than actively completing the frames (ie, all frames here are failed); * Methodize ath_draintxq(). The EDMA ath_draintxq() will have to take care of running the TX completion FIFO before (potentially) freeing frames in the queue. The only two places where ath_tx_draintxq() (on a single TXQ) are used: * ath_draintxq(); and * the CABQ handling in the beacon setup code - it drains the CABQ before populating the CABQ with frames for a new beacon (when doing multi-VAP operation.) So it's quite possible that once I methodize the CABQ and beacon handling, I can just drop ath_tx_draintxq() in its entirety. Finally, it's also quite possible that I can remove ath_tx_draintxq() in the future and just "teach" it to not check the status when doing EDMA.
2012-08-12 00:37:29 +00:00
static int
ath_tx_processq(struct ath_softc *sc, struct ath_txq *txq, int dosched)
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
{
struct ath_hal *ah = sc->sc_ah;
Refactor out the TX buffer management and completion code in preparation for TX aggregation. * Add in logic which calls ath_buf bf->bf_comp if it's set. This allows for AMPDU (and RIFS, and FF, if someone desires) code to handle completion - which includes freeing subframes, retransmitting subframes, etc. * Break out the buffer free, buffer busy/unbusy default completion handler code into separate functions. This allows bf_comp methods to free and unbusy each subframe ath_buf as required. * Break out the statistics update code into a separate function, just to clean up the TX completion path a little. Sponsored by: Hobnob, Inc.
2011-11-08 21:49:33 +00:00
struct ath_buf *bf;
Change the descriptor logic to use bf_lastds to point to the last descriptor, rather than using the maths involving bf_desc[bf_nseg - 1]. When doing TX aggregation, the status will be updated in the -final- descriptor of the -final- subframe in an aggregate. Thus bf_lastds may point to the last descriptor in a completely different ath_buf. Sponsored by: Hobnob, Inc.
2011-11-08 21:25:36 +00:00
struct ath_desc *ds;
Track v0.9.20.3 hal: o no more ds_vdata in tx/rx descriptors o split h/w tx/rx descriptor from s/w status o as part of the descriptor split change the rate control module api so the ath_buf is passed in to the module so it can fetch both descriptor and status information as needed o add some const poisoning Also for sample rate control algorithm: o split debug msgs (node, rate, any) o uniformly bounds check rate indices (and in some cases correct checks) o move array index ops to after bounds checking o use final tsi from the status block instead of the h/w descriptor o replace h/w descriptor struct's with proper mask+shift defs (this doesn't belong here; everything is known by the driver and should just be sent down so there's no h/w-specific knowledge) MFC after: 1 month
2006-12-13 19:34:35 +00:00
struct ath_tx_status *ts;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
struct ieee80211_node *ni;
Fix the default, non-superg compile. Pointy-hat-to: adrian
2012-04-11 02:34:32 +00:00
#ifdef IEEE80211_SUPPORT_SUPERG
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
struct ieee80211com *ic = &sc->sc_ic;
Fix the default, non-superg compile. Pointy-hat-to: adrian
2012-04-11 02:34:32 +00:00
#endif /* IEEE80211_SUPPORT_SUPERG */
Refactor out the TX buffer management and completion code in preparation for TX aggregation. * Add in logic which calls ath_buf bf->bf_comp if it's set. This allows for AMPDU (and RIFS, and FF, if someone desires) code to handle completion - which includes freeing subframes, retransmitting subframes, etc. * Break out the buffer free, buffer busy/unbusy default completion handler code into separate functions. This allows bf_comp methods to free and unbusy each subframe ath_buf as required. * Break out the statistics update code into a separate function, just to clean up the TX completion path a little. Sponsored by: Hobnob, Inc.
2011-11-08 21:49:33 +00:00
int nacked;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
HAL_STATUS status;
Update with last year of work.
2004-12-08 17:34:36 +00:00
DPRINTF(sc, ATH_DEBUG_TX_PROC, "%s: tx queue %u head %p link %p\n",
__func__, txq->axq_qnum,
(caddr_t)(uintptr_t) ath_hal_gettxbuf(sc->sc_ah, txq->axq_qnum),
txq->axq_link);
Migrate the ath(4) KTR logging to use an ATH_KTR() macro. This should eventually be unified with ATH_DEBUG() so I can get both from one macro; that may take some time. Add some new probes for TX and TX completion.
2012-09-24 20:35:56 +00:00
ATH_KTR(sc, ATH_KTR_TXCOMP, 4,
"ath_tx_processq: txq=%u head %p link %p depth %p",
txq->axq_qnum,
(caddr_t)(uintptr_t) ath_hal_gettxbuf(sc->sc_ah, txq->axq_qnum),
txq->axq_link,
txq->axq_depth);
Phantom beacon miss workaround: track the tsf of the last received frame and if we get a beacon miss interrupt ignore it if we've received a frame within the beacon miss interval. This should never trigger and the handling at the net80211 layer should likewise deal with this but it doesn't hurt and can suppress extranous probe request frames. Note that we can legtimately get a bmiss when under heavy load. MFC after: 2 weeks
2006-02-09 22:03:26 +00:00
nacked = 0;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
for (;;) {
Overhaul the TXQ locking (again!) as part of some beacon/cabq timing related issues. Moving the TX locking under one lock made things easier to progress on but it had one important side-effect - it increased the latency when handling CABQ setup when sending beacons. This commit introduces a bunch of new changes and a few unrelated changs that are just easier to lump in here. The aim is to have the CABQ locking separate from other locking. The CABQ transmit path in the beacon process thus doesn't have to grab the general TX lock, reducing lock contention/latency and making it more likely that we'll make the beacon TX timing. The second half of this commit is the CABQ related setup changes needed for sane looking EDMA CABQ support. Right now the EDMA TX code naively assumes that only one frame (MPDU or A-MPDU) is being pushed into each FIFO slot. For the CABQ this isn't true - a whole list of frames is being pushed in - and thus CABQ handling breaks very quickly. The aim here is to setup the CABQ list and then push _that list_ to the hardware for transmission. I can then extend the EDMA TX code to stamp that list as being "one" FIFO entry (likely by tagging the last buffer in that list as "FIFO END") so the EDMA TX completion code correctly tracks things. Major: * Migrate the per-TXQ add/removal locking back to per-TXQ, rather than a single lock. * Leave the software queue side of things under the ATH_TX_LOCK lock, (continuing) to serialise things as they are. * Add a new function which is called whenever there's a beacon miss, to print out some debugging. This is primarily designed to help me figure out if the beacon miss events are due to a noisy environment, issues with the PHY/MAC, or other. * Move the CABQ setup/enable to occur _after_ all the VAPs have been looked at. This means that for multiple VAPS in bursted mode, the CABQ gets primed once all VAPs are checked, rather than being primed on the first VAP and then having frames appended after this. Minor: * Add a (disabled) twiddle to let me enable/disable cabq traffic. It's primarily there to let me easily debug what's going on with beacon and CABQ setup/traffic; there's some DMA engine hangs which I'm finally trying to trace down. * Clear bf_next when flushing frames; it should quieten some warnings that show up when a node goes away. Tested: * AR9280, STA/hostap, up to 4 vaps (staggered) * AR5416, STA/hostap, up to 4 vaps (staggered) TODO: * (Lots) more AR9380 and later testing, as I may have missed something here. * Leverage this to fix CABQ hanling for AR9380 and later chips. * Force bursted beaconing on the chips that default to staggered beacons and ensure the CABQ stuff is all sane (eg, the MORE bits that aren't being correctly set when chaining descriptors.)
2013-03-24 00:03:12 +00:00
ATH_TXQ_LOCK(txq);
Update with last year of work.
2004-12-08 17:34:36 +00:00
txq->axq_intrcnt = 0; /* reset periodic desc intr count */
Migrate the STAILQ lists to TAILQs. A bunch of the 11n TX aggregation logic wants to traverse lists of buffers in various ways. In order to provide O(1) behaviour in this instance, use TAILQs. This does blow out the memory footprint and CPU cycles slightly for some of these operations. I may convert some of these back to STAILQs once the rest of the software transmit queue handling has been stabilised. Sponsored by: Hobnob, Inc.
2011-11-08 17:08:12 +00:00
bf = TAILQ_FIRST(&txq->axq_q);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
if (bf == NULL) {
Overhaul the TXQ locking (again!) as part of some beacon/cabq timing related issues. Moving the TX locking under one lock made things easier to progress on but it had one important side-effect - it increased the latency when handling CABQ setup when sending beacons. This commit introduces a bunch of new changes and a few unrelated changs that are just easier to lump in here. The aim is to have the CABQ locking separate from other locking. The CABQ transmit path in the beacon process thus doesn't have to grab the general TX lock, reducing lock contention/latency and making it more likely that we'll make the beacon TX timing. The second half of this commit is the CABQ related setup changes needed for sane looking EDMA CABQ support. Right now the EDMA TX code naively assumes that only one frame (MPDU or A-MPDU) is being pushed into each FIFO slot. For the CABQ this isn't true - a whole list of frames is being pushed in - and thus CABQ handling breaks very quickly. The aim here is to setup the CABQ list and then push _that list_ to the hardware for transmission. I can then extend the EDMA TX code to stamp that list as being "one" FIFO entry (likely by tagging the last buffer in that list as "FIFO END") so the EDMA TX completion code correctly tracks things. Major: * Migrate the per-TXQ add/removal locking back to per-TXQ, rather than a single lock. * Leave the software queue side of things under the ATH_TX_LOCK lock, (continuing) to serialise things as they are. * Add a new function which is called whenever there's a beacon miss, to print out some debugging. This is primarily designed to help me figure out if the beacon miss events are due to a noisy environment, issues with the PHY/MAC, or other. * Move the CABQ setup/enable to occur _after_ all the VAPs have been looked at. This means that for multiple VAPS in bursted mode, the CABQ gets primed once all VAPs are checked, rather than being primed on the first VAP and then having frames appended after this. Minor: * Add a (disabled) twiddle to let me enable/disable cabq traffic. It's primarily there to let me easily debug what's going on with beacon and CABQ setup/traffic; there's some DMA engine hangs which I'm finally trying to trace down. * Clear bf_next when flushing frames; it should quieten some warnings that show up when a node goes away. Tested: * AR9280, STA/hostap, up to 4 vaps (staggered) * AR5416, STA/hostap, up to 4 vaps (staggered) TODO: * (Lots) more AR9380 and later testing, as I may have missed something here. * Leverage this to fix CABQ hanling for AR9380 and later chips. * Force bursted beaconing on the chips that default to staggered beacons and ensure the CABQ stuff is all sane (eg, the MORE bits that aren't being correctly set when chaining descriptors.)
2013-03-24 00:03:12 +00:00
ATH_TXQ_UNLOCK(txq);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
break;
}
Change the descriptor logic to use bf_lastds to point to the last descriptor, rather than using the maths involving bf_desc[bf_nseg - 1]. When doing TX aggregation, the status will be updated in the -final- descriptor of the -final- subframe in an aggregate. Thus bf_lastds may point to the last descriptor in a completely different ath_buf. Sponsored by: Hobnob, Inc.
2011-11-08 21:25:36 +00:00
ds = bf->bf_lastds; /* XXX must be setup correctly! */
Track v0.9.20.3 hal: o no more ds_vdata in tx/rx descriptors o split h/w tx/rx descriptor from s/w status o as part of the descriptor split change the rate control module api so the ath_buf is passed in to the module so it can fetch both descriptor and status information as needed o add some const poisoning Also for sample rate control algorithm: o split debug msgs (node, rate, any) o uniformly bounds check rate indices (and in some cases correct checks) o move array index ops to after bounds checking o use final tsi from the status block instead of the h/w descriptor o replace h/w descriptor struct's with proper mask+shift defs (this doesn't belong here; everything is known by the driver and should just be sent down so there's no h/w-specific knowledge) MFC after: 1 month
2006-12-13 19:34:35 +00:00
ts = &bf->bf_status.ds_txstat;
Migrate the ath(4) KTR logging to use an ATH_KTR() macro. This should eventually be unified with ATH_DEBUG() so I can get both from one macro; that may take some time. Add some new probes for TX and TX completion.
2012-09-24 20:35:56 +00:00
Track v0.9.20.3 hal: o no more ds_vdata in tx/rx descriptors o split h/w tx/rx descriptor from s/w status o as part of the descriptor split change the rate control module api so the ath_buf is passed in to the module so it can fetch both descriptor and status information as needed o add some const poisoning Also for sample rate control algorithm: o split debug msgs (node, rate, any) o uniformly bounds check rate indices (and in some cases correct checks) o move array index ops to after bounds checking o use final tsi from the status block instead of the h/w descriptor o replace h/w descriptor struct's with proper mask+shift defs (this doesn't belong here; everything is known by the driver and should just be sent down so there's no h/w-specific knowledge) MFC after: 1 month
2006-12-13 19:34:35 +00:00
status = ath_hal_txprocdesc(ah, ds, ts);
o add opt_ath.h enable tweaking various config parameters for the driver without modifying the source code o default debug msgs and diag support to off MFC after: 3 days
2006-04-03 18:14:02 +00:00
#ifdef ATH_DEBUG
Update with last year of work.
2004-12-08 17:34:36 +00:00
if (sc->sc_debug & ATH_DEBUG_XMIT_DESC)
print the extended tx/rx descriptor for 5416 and later parts
2008-11-24 01:34:56 +00:00
ath_printtxbuf(sc, bf, txq->axq_qnum, 0,
status == HAL_OK);
Migrate the ath(4) KTR logging to use an ATH_KTR() macro. This should eventually be unified with ATH_DEBUG() so I can get both from one macro; that may take some time. Add some new probes for TX and TX completion.
2012-09-24 20:35:56 +00:00
else if ((sc->sc_debug & ATH_DEBUG_RESET) && (dosched == 0))
Disable the HWQ contents upon a TX queue reset, rather than a TX queue flush. This is designed to assist in figuring out what the hardware state is when something like a queue hang has occured.
2012-04-04 22:24:11 +00:00
ath_printtxbuf(sc, bf, txq->axq_qnum, 0,
status == HAL_OK);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
#endif
ALQ logging enhancements: * upon setup, tell the alq code what the chip information is. * add TX/RX path logging for legacy chips. * populate the tx/rx descriptor length fields with a best-estimate. It's overly big (96 bytes when AH_SUPPORT_AR5416 is enabled) but it'll do for now. Whilst I'm here, add CURVNET_RESTORE() here during probe/attach as a partial solution to fixing crashes during attach when the attach fails. There are other attach failures that I have to deal with; those'll come later.
2012-11-16 19:57:16 +00:00
#ifdef ATH_DEBUG_ALQ
if (if_ath_alq_checkdebug(&sc->sc_alq,
ATH_ALQ_EDMA_TXSTATUS)) {
if_ath_alq_post(&sc->sc_alq, ATH_ALQ_EDMA_TXSTATUS,
sc->sc_tx_statuslen,
(char *) ds);
}
#endif
Migrate the ath(4) KTR logging to use an ATH_KTR() macro. This should eventually be unified with ATH_DEBUG() so I can get both from one macro; that may take some time. Add some new probes for TX and TX completion.
2012-09-24 20:35:56 +00:00
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
if (status == HAL_EINPROGRESS) {
Migrate the ath(4) KTR logging to use an ATH_KTR() macro. This should eventually be unified with ATH_DEBUG() so I can get both from one macro; that may take some time. Add some new probes for TX and TX completion.
2012-09-24 20:35:56 +00:00
ATH_KTR(sc, ATH_KTR_TXCOMP, 3,
"ath_tx_processq: txq=%u, bf=%p ds=%p, HAL_EINPROGRESS",
txq->axq_qnum, bf, ds);
Overhaul the TXQ locking (again!) as part of some beacon/cabq timing related issues. Moving the TX locking under one lock made things easier to progress on but it had one important side-effect - it increased the latency when handling CABQ setup when sending beacons. This commit introduces a bunch of new changes and a few unrelated changs that are just easier to lump in here. The aim is to have the CABQ locking separate from other locking. The CABQ transmit path in the beacon process thus doesn't have to grab the general TX lock, reducing lock contention/latency and making it more likely that we'll make the beacon TX timing. The second half of this commit is the CABQ related setup changes needed for sane looking EDMA CABQ support. Right now the EDMA TX code naively assumes that only one frame (MPDU or A-MPDU) is being pushed into each FIFO slot. For the CABQ this isn't true - a whole list of frames is being pushed in - and thus CABQ handling breaks very quickly. The aim here is to setup the CABQ list and then push _that list_ to the hardware for transmission. I can then extend the EDMA TX code to stamp that list as being "one" FIFO entry (likely by tagging the last buffer in that list as "FIFO END") so the EDMA TX completion code correctly tracks things. Major: * Migrate the per-TXQ add/removal locking back to per-TXQ, rather than a single lock. * Leave the software queue side of things under the ATH_TX_LOCK lock, (continuing) to serialise things as they are. * Add a new function which is called whenever there's a beacon miss, to print out some debugging. This is primarily designed to help me figure out if the beacon miss events are due to a noisy environment, issues with the PHY/MAC, or other. * Move the CABQ setup/enable to occur _after_ all the VAPs have been looked at. This means that for multiple VAPS in bursted mode, the CABQ gets primed once all VAPs are checked, rather than being primed on the first VAP and then having frames appended after this. Minor: * Add a (disabled) twiddle to let me enable/disable cabq traffic. It's primarily there to let me easily debug what's going on with beacon and CABQ setup/traffic; there's some DMA engine hangs which I'm finally trying to trace down. * Clear bf_next when flushing frames; it should quieten some warnings that show up when a node goes away. Tested: * AR9280, STA/hostap, up to 4 vaps (staggered) * AR5416, STA/hostap, up to 4 vaps (staggered) TODO: * (Lots) more AR9380 and later testing, as I may have missed something here. * Leverage this to fix CABQ hanling for AR9380 and later chips. * Force bursted beaconing on the chips that default to staggered beacons and ensure the CABQ stuff is all sane (eg, the MORE bits that aren't being correctly set when chaining descriptors.)
2013-03-24 00:03:12 +00:00
ATH_TXQ_UNLOCK(txq);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
break;
}
Migrate the STAILQ lists to TAILQs. A bunch of the 11n TX aggregation logic wants to traverse lists of buffers in various ways. In order to provide O(1) behaviour in this instance, use TAILQs. This does blow out the memory footprint and CPU cycles slightly for some of these operations. I may convert some of these back to STAILQs once the rest of the software transmit queue handling has been stabilised. Sponsored by: Hobnob, Inc.
2011-11-08 17:08:12 +00:00
ATH_TXQ_REMOVE(txq, bf, bf_list);
Fix the holding descriptor logic to actually be "right" (for values of "right".) Flip back on the "always continue TX DMA using the holding descriptor" code - by always setting ATH_BUF_BUSY and never setting axq_link to NULL. Since the holding descriptor is accessed via txq->axq_link and _that_ is done behind the TXQ lock rather than the TX path lock, the holding descriptor stuff itself needs to be behind the TXQ lock. So, do the mental gymnastics needed to do this. I've not seen any of the hardware failures that I was seeing when I last tried to do this. Tested: * AR5416, STA mode
2013-05-08 21:23:51 +00:00
/*
* Sanity check.
*/
if (txq->axq_qnum != bf->bf_state.bfs_tx_queue) {
device_printf(sc->sc_dev,
"%s: TXQ=%d: bf=%p, bfs_tx_queue=%d\n",
__func__,
txq->axq_qnum,
bf,
bf->bf_state.bfs_tx_queue);
}
if (txq->axq_qnum != bf->bf_last->bf_state.bfs_tx_queue) {
device_printf(sc->sc_dev,
"%s: TXQ=%d: bf_last=%p, bfs_tx_queue=%d\n",
__func__,
txq->axq_qnum,
bf->bf_last,
bf->bf_last->bf_state.bfs_tx_queue);
}
#if 0
Revert a previous commit - this is causing hardware errors. I'm not sure why this is failing. The holding descriptor should be being re-read when starting DMA of the next frame. Obviously something here isn't totally correct. I'll review the TX queue handling and see if I can figure out why this is failing. I'll then re-revert this patch out and use the holding descriptor again.
2013-05-08 07:30:33 +00:00
if (txq->axq_depth > 0) {
/*
* More frames follow. Mark the buffer busy
* so it's not re-used while the hardware may
* still re-read the link field in the descriptor.
*
* Use the last buffer in an aggregate as that
* is where the hardware may be - intermediate
* descriptors won't be "busy".
*/
bf->bf_last->bf_flags |= ATH_BUF_BUSY;
} else
txq->axq_link = NULL;
Fix the holding descriptor logic to actually be "right" (for values of "right".) Flip back on the "always continue TX DMA using the holding descriptor" code - by always setting ATH_BUF_BUSY and never setting axq_link to NULL. Since the holding descriptor is accessed via txq->axq_link and _that_ is done behind the TXQ lock rather than the TX path lock, the holding descriptor stuff itself needs to be behind the TXQ lock. So, do the mental gymnastics needed to do this. I've not seen any of the hardware failures that I was seeing when I last tried to do this. Tested: * AR5416, STA mode
2013-05-08 21:23:51 +00:00
#else
bf->bf_last->bf_flags |= ATH_BUF_BUSY;
#endif
Change the descriptor logic to use bf_lastds to point to the last descriptor, rather than using the maths involving bf_desc[bf_nseg - 1]. When doing TX aggregation, the status will be updated in the -final- descriptor of the -final- subframe in an aggregate. Thus bf_lastds may point to the last descriptor in a completely different ath_buf. Sponsored by: Hobnob, Inc.
2011-11-08 21:25:36 +00:00
if (bf->bf_state.bfs_aggr)
txq->axq_aggr_depth--;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
ni = bf->bf_node;
Migrate the ath(4) KTR logging to use an ATH_KTR() macro. This should eventually be unified with ATH_DEBUG() so I can get both from one macro; that may take some time. Add some new probes for TX and TX completion.
2012-09-24 20:35:56 +00:00
ATH_KTR(sc, ATH_KTR_TXCOMP, 5,
"ath_tx_processq: txq=%u, bf=%p, ds=%p, ni=%p, ts_status=0x%08x",
txq->axq_qnum, bf, ds, ni, ts->ts_status);
Refactor out the TX buffer management and completion code in preparation for TX aggregation. * Add in logic which calls ath_buf bf->bf_comp if it's set. This allows for AMPDU (and RIFS, and FF, if someone desires) code to handle completion - which includes freeing subframes, retransmitting subframes, etc. * Break out the buffer free, buffer busy/unbusy default completion handler code into separate functions. This allows bf_comp methods to free and unbusy each subframe ath_buf as required. * Break out the statistics update code into a separate function, just to clean up the TX completion path a little. Sponsored by: Hobnob, Inc.
2011-11-08 21:49:33 +00:00
/*
* If unicast frame was ack'd update RSSI,
* including the last rx time used to
* workaround phantom bmiss interrupts.
*/
if (ni != NULL && ts->ts_status == 0 &&
Remove duplicate txflags field from ath_buf. rename bf_state.bfs_flags to bf_state.bfs_txflags, as that is what it effectively is.
2012-04-07 02:01:26 +00:00
((bf->bf_state.bfs_txflags & HAL_TXDESC_NOACK) == 0)) {
Refactor out the TX buffer management and completion code in preparation for TX aggregation. * Add in logic which calls ath_buf bf->bf_comp if it's set. This allows for AMPDU (and RIFS, and FF, if someone desires) code to handle completion - which includes freeing subframes, retransmitting subframes, etc. * Break out the buffer free, buffer busy/unbusy default completion handler code into separate functions. This allows bf_comp methods to free and unbusy each subframe ath_buf as required. * Break out the statistics update code into a separate function, just to clean up the TX completion path a little. Sponsored by: Hobnob, Inc.
2011-11-08 21:49:33 +00:00
nacked++;
sc->sc_stats.ast_tx_rssi = ts->ts_rssi;
ATH_RSSI_LPF(sc->sc_halstats.ns_avgtxrssi,
ts->ts_rssi);
[ath] [ath_rate] Fix ANI calibration during non-ACTIVE states; start poking at rate control These are some fun issues I've found with my upstairs wifi link at such a ridiculous low signal level (like, < 5dB.) * Add per-station tx/rx rssi statistics, in potential preparation to use that in the RX rate control. * Call the rate control on each received frame to let it potentially use it as a hint for what rates to potentially use. It's a no-op right now. * Do ANI calibration during scan as well. The ath_newstate() call was disabling the ANI timer and only re-enabling it during transitions to _RUN. This has the unfortunate side-effect that if ANI deafened the NIC because of interference and it disassociated, it wouldn't be reset and the scan would never hear beacons. The ANI configuration is stored at least globally on some HALs and per-channel on others. Because of this a NIC reset wouldn't help; the ANI parameters would simply be programmed back in. Now, I have a feeling I also need to do this during AUTH/ASSOC too and maybe, if I'm feeling clever, I need to reset the ANI parameters on a given channel during a transition through INIT or if the VAP is destroyed/re-created. However for now this gets me out of the immediate weeds with connectivity upstairs (and thus I /can/ commit); I'll keep chipping away at tidying this stuff up in subsequent commits. Tested: * AR9344 (Wasp), 2G STA mode
2019-05-05 04:56:37 +00:00
ATH_RSSI_LPF(ATH_NODE(ni)->an_node_stats.ns_avgtxrssi,
ts->ts_rssi);
Refactor out the TX buffer management and completion code in preparation for TX aggregation. * Add in logic which calls ath_buf bf->bf_comp if it's set. This allows for AMPDU (and RIFS, and FF, if someone desires) code to handle completion - which includes freeing subframes, retransmitting subframes, etc. * Break out the buffer free, buffer busy/unbusy default completion handler code into separate functions. This allows bf_comp methods to free and unbusy each subframe ath_buf as required. * Break out the statistics update code into a separate function, just to clean up the TX completion path a little. Sponsored by: Hobnob, Inc.
2011-11-08 21:49:33 +00:00
}
Overhaul the TXQ locking (again!) as part of some beacon/cabq timing related issues. Moving the TX locking under one lock made things easier to progress on but it had one important side-effect - it increased the latency when handling CABQ setup when sending beacons. This commit introduces a bunch of new changes and a few unrelated changs that are just easier to lump in here. The aim is to have the CABQ locking separate from other locking. The CABQ transmit path in the beacon process thus doesn't have to grab the general TX lock, reducing lock contention/latency and making it more likely that we'll make the beacon TX timing. The second half of this commit is the CABQ related setup changes needed for sane looking EDMA CABQ support. Right now the EDMA TX code naively assumes that only one frame (MPDU or A-MPDU) is being pushed into each FIFO slot. For the CABQ this isn't true - a whole list of frames is being pushed in - and thus CABQ handling breaks very quickly. The aim here is to setup the CABQ list and then push _that list_ to the hardware for transmission. I can then extend the EDMA TX code to stamp that list as being "one" FIFO entry (likely by tagging the last buffer in that list as "FIFO END") so the EDMA TX completion code correctly tracks things. Major: * Migrate the per-TXQ add/removal locking back to per-TXQ, rather than a single lock. * Leave the software queue side of things under the ATH_TX_LOCK lock, (continuing) to serialise things as they are. * Add a new function which is called whenever there's a beacon miss, to print out some debugging. This is primarily designed to help me figure out if the beacon miss events are due to a noisy environment, issues with the PHY/MAC, or other. * Move the CABQ setup/enable to occur _after_ all the VAPs have been looked at. This means that for multiple VAPS in bursted mode, the CABQ gets primed once all VAPs are checked, rather than being primed on the first VAP and then having frames appended after this. Minor: * Add a (disabled) twiddle to let me enable/disable cabq traffic. It's primarily there to let me easily debug what's going on with beacon and CABQ setup/traffic; there's some DMA engine hangs which I'm finally trying to trace down. * Clear bf_next when flushing frames; it should quieten some warnings that show up when a node goes away. Tested: * AR9280, STA/hostap, up to 4 vaps (staggered) * AR5416, STA/hostap, up to 4 vaps (staggered) TODO: * (Lots) more AR9380 and later testing, as I may have missed something here. * Leverage this to fix CABQ hanling for AR9380 and later chips. * Force bursted beaconing on the chips that default to staggered beacons and ensure the CABQ stuff is all sane (eg, the MORE bits that aren't being correctly set when chaining descriptors.)
2013-03-24 00:03:12 +00:00
ATH_TXQ_UNLOCK(txq);
Refactor out the TX buffer management and completion code in preparation for TX aggregation. * Add in logic which calls ath_buf bf->bf_comp if it's set. This allows for AMPDU (and RIFS, and FF, if someone desires) code to handle completion - which includes freeing subframes, retransmitting subframes, etc. * Break out the buffer free, buffer busy/unbusy default completion handler code into separate functions. This allows bf_comp methods to free and unbusy each subframe ath_buf as required. * Break out the statistics update code into a separate function, just to clean up the TX completion path a little. Sponsored by: Hobnob, Inc.
2011-11-08 21:49:33 +00:00
/*
Break out the TX completion code into a separate function, so it can be re-used by the upcoming EDMA TX completion code. Make ath_stoptxdma() public, again so the EDMA TX code can use it. Don't check for the TXQ bitmap in the ISR when doing EDMA work as it doesn't apply for EDMA.
2012-08-14 22:32:20 +00:00
* Update statistics and call completion
Refactor out the TX buffer management and completion code in preparation for TX aggregation. * Add in logic which calls ath_buf bf->bf_comp if it's set. This allows for AMPDU (and RIFS, and FF, if someone desires) code to handle completion - which includes freeing subframes, retransmitting subframes, etc. * Break out the buffer free, buffer busy/unbusy default completion handler code into separate functions. This allows bf_comp methods to free and unbusy each subframe ath_buf as required. * Break out the statistics update code into a separate function, just to clean up the TX completion path a little. Sponsored by: Hobnob, Inc.
2011-11-08 21:49:33 +00:00
*/
Break out the TX completion code into a separate function, so it can be re-used by the upcoming EDMA TX completion code. Make ath_stoptxdma() public, again so the EDMA TX code can use it. Don't check for the TXQ bitmap in the ISR when doing EDMA work as it doesn't apply for EDMA.
2012-08-14 22:32:20 +00:00
ath_tx_process_buf_completion(sc, txq, ts, bf);
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
/* XXX at this point, bf and ni may be totally invalid */
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
Hoist 802.11 encapsulation up into net80211: o call ieee80211_encap in ieee80211_start so frames passed down to drivers are already encapsulated o remove ieee80211_encap calls in drivers o fixup wi so it recreates the 802.3 head it requires from the 802.11 header contents o move fast-frame aggregation from ath to net80211 (conditional on IEEE80211_SUPPORT_SUPERG): - aggregation is now done in ieee80211_start; it is enabled when the packets/sec exceeds ieee80211_ffppsmin (net.wlan.ffppsmin) and frames are held on a staging queue according to ieee80211_ffagemax (net.wlan.ffagemax) to wait for a frame to combine with - drivers must call back to age/flush the staging queue (ath does this on tx done, at swba, and on rx according to the state of the tx queues and/or the contents of the staging queue) - remove fast-frame-related data structures from ath - add ieee80211_ff_node_init and ieee80211_ff_node_cleanup to handle per-node fast-frames state (we reuse 11n tx ampdu state) o change ieee80211_encap calling convention to include an explicit vap so frames coming through a WDS vap are recognized w/o setting M_WDS With these changes any device able to tx/rx 3Kbyte+ frames can use fast-frames. Reviewed by: thompsa, rpaulo, avatar, imp, sephe
2009-03-30 21:53:27 +00:00
#ifdef IEEE80211_SUPPORT_SUPERG
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
/*
* Flush fast-frame staging queue when traffic slows.
*/
if (txq->axq_depth <= 1)
make superg/fast-frames state dynamically-allocated (and indirect off the com structure instead of embedded); this reduces the overhead when not configured and reduces visibility of the contents
2009-05-02 20:16:55 +00:00
ieee80211_ff_flush(ic, txq->axq_ac);
Hoist 802.11 encapsulation up into net80211: o call ieee80211_encap in ieee80211_start so frames passed down to drivers are already encapsulated o remove ieee80211_encap calls in drivers o fixup wi so it recreates the 802.3 head it requires from the 802.11 header contents o move fast-frame aggregation from ath to net80211 (conditional on IEEE80211_SUPPORT_SUPERG): - aggregation is now done in ieee80211_start; it is enabled when the packets/sec exceeds ieee80211_ffppsmin (net.wlan.ffppsmin) and frames are held on a staging queue according to ieee80211_ffagemax (net.wlan.ffagemax) to wait for a frame to combine with - drivers must call back to age/flush the staging queue (ath does this on tx done, at swba, and on rx according to the state of the tx queues and/or the contents of the staging queue) - remove fast-frame-related data structures from ath - add ieee80211_ff_node_init and ieee80211_ff_node_cleanup to handle per-node fast-frames state (we reuse 11n tx ampdu state) o change ieee80211_encap calling convention to include an explicit vap so frames coming through a WDS vap are recognized w/o setting M_WDS With these changes any device able to tx/rx 3Kbyte+ frames can use fast-frames. Reviewed by: thompsa, rpaulo, avatar, imp, sephe
2009-03-30 21:53:27 +00:00
#endif
Introduce TX aggregation and software TX queue management for Atheros AR5416 and later wireless devices. This is a very large commit - the complete history can be found in the user/adrian/if_ath_tx branch. Legacy (ie, pre-AR5416) devices also use the per-software TXQ support and (in theory) can support non-aggregation ADDBA sessions. However, the net80211 stack doesn't currently support this. In summary: TX path: * queued frames normally go onto a per-TID, per-node queue * some special frames (eg ADDBA control frames) are thrown directly onto the relevant hardware queue so they can go out before any software queued frames are queued. * Add methods to create, suspend, resume and tear down an aggregation session. * Add in software retransmission of both normal and aggregate frames. * Add in completion handling of aggregate frames, including parsing the block ack bitmap provided by the hardware. * Write an aggregation function which can assemble frames into an aggregate based on the selected rate control and channel configuration. * The per-TID queues are locked based on their target hardware TX queue. This matches what ath9k/atheros does, and thus simplified porting over some of the aggregation logic. * When doing TX aggregation, stick the sequence number allocation in the TX path rather than net80211 TX path, and protect it by the TXQ lock. Rate control: * Delay rate control selection until the frame is about to be queued to the hardware, so retried frames can have their rate control choices changed. Frames with a static rate control selection have that applied before each TX, just to simplify the TX path (ie, not have "static" and "dynamic" rate control special cased.) * Teach ath_rate_sample about aggregates - both completion and errors. * Add an EWMA for tracking what the current "good" MCS rate is based on failure rates. Misc: * Introduce a bunch of dirty hacks and workarounds so TID mapping and net80211 frame inspection can be kept out of the net80211 layer. Because of the way this code works (and it's from Atheros and Linux ath9k), there is a consistent, 1:1 mapping between TID and AC. So we need to ensure that frames going to a specific TID will _always_ end up on the right AC, and vice versa, or the completion/locking will simply get very confused. I plan on addressing this mess in the future. Known issues: * There is no BAR frame transmission just yet. A whole lot of tidying up needs to occur before BAR frame TX can occur in the "correct" place - ie, once the TID TX queue has been drained. * Interface reset/purge/etc results in frames in the TX and RX queues being removed. This creates holes in the sequence numbers being assigned and the TX/RX AMPDU code (on either side) just hangs. * There's no filtered frame support at the present moment, so stations going into power saving mode will simply have a number of frames dropped - likely resulting in a traffic "hang". * Raw frame TX is going to just not function with 11n aggregation. Likely this needs to be modified to always override the sequence number if the frame is going into an aggregation session. However, general raw frame injection currently doesn't work in general in net80211, so let's just ignore this for now until this is sorted out. * HT protection is just not implemented and won't be until the above is sorted out. In addition, the AR5416 has issues RTS protecting large aggregates (anything >8k), so the work around needs to be ported and tested. Thus, this will be put on hold until the above work is complete. * The rate control module 'sample' is the only currently supported module; onoe/amrr haven't been tested and have likely bit rotted a little. I'll follow up with some commits to make them work again for non-11n rates, but they won't be updated to handle 11n and aggregation. If someone wishes to do so then they're welcome to send along patches. * .. and "sample" doesn't really do a good job of 11n TX. Specifically, the metrics used (packet TX time and failure/success rates) isn't as useful for 11n. It's likely that it should be extended to take into account the aggregate throughput possible and then choose a rate which maximises that. Ie, it may be acceptable for a higher MCS rate with a higher failure to be used if it gives a more acceptable throughput/latency then a lower MCS rate @ a lower error rate. Again, patches will be gratefully accepted. Because of this, ATH_ENABLE_11N is still not enabled by default. Sponsored by: Hobnob, Inc. Obtained from: Linux, Atheros
2011-11-08 22:43:13 +00:00
Methodize the process of adding the software TX queue to the taskqueue. Move it (for now) to the TX taskqueue.
2013-02-07 02:15:25 +00:00
/* Kick the software TXQ scheduler */
Introduce TX aggregation and software TX queue management for Atheros AR5416 and later wireless devices. This is a very large commit - the complete history can be found in the user/adrian/if_ath_tx branch. Legacy (ie, pre-AR5416) devices also use the per-software TXQ support and (in theory) can support non-aggregation ADDBA sessions. However, the net80211 stack doesn't currently support this. In summary: TX path: * queued frames normally go onto a per-TID, per-node queue * some special frames (eg ADDBA control frames) are thrown directly onto the relevant hardware queue so they can go out before any software queued frames are queued. * Add methods to create, suspend, resume and tear down an aggregation session. * Add in software retransmission of both normal and aggregate frames. * Add in completion handling of aggregate frames, including parsing the block ack bitmap provided by the hardware. * Write an aggregation function which can assemble frames into an aggregate based on the selected rate control and channel configuration. * The per-TID queues are locked based on their target hardware TX queue. This matches what ath9k/atheros does, and thus simplified porting over some of the aggregation logic. * When doing TX aggregation, stick the sequence number allocation in the TX path rather than net80211 TX path, and protect it by the TXQ lock. Rate control: * Delay rate control selection until the frame is about to be queued to the hardware, so retried frames can have their rate control choices changed. Frames with a static rate control selection have that applied before each TX, just to simplify the TX path (ie, not have "static" and "dynamic" rate control special cased.) * Teach ath_rate_sample about aggregates - both completion and errors. * Add an EWMA for tracking what the current "good" MCS rate is based on failure rates. Misc: * Introduce a bunch of dirty hacks and workarounds so TID mapping and net80211 frame inspection can be kept out of the net80211 layer. Because of the way this code works (and it's from Atheros and Linux ath9k), there is a consistent, 1:1 mapping between TID and AC. So we need to ensure that frames going to a specific TID will _always_ end up on the right AC, and vice versa, or the completion/locking will simply get very confused. I plan on addressing this mess in the future. Known issues: * There is no BAR frame transmission just yet. A whole lot of tidying up needs to occur before BAR frame TX can occur in the "correct" place - ie, once the TID TX queue has been drained. * Interface reset/purge/etc results in frames in the TX and RX queues being removed. This creates holes in the sequence numbers being assigned and the TX/RX AMPDU code (on either side) just hangs. * There's no filtered frame support at the present moment, so stations going into power saving mode will simply have a number of frames dropped - likely resulting in a traffic "hang". * Raw frame TX is going to just not function with 11n aggregation. Likely this needs to be modified to always override the sequence number if the frame is going into an aggregation session. However, general raw frame injection currently doesn't work in general in net80211, so let's just ignore this for now until this is sorted out. * HT protection is just not implemented and won't be until the above is sorted out. In addition, the AR5416 has issues RTS protecting large aggregates (anything >8k), so the work around needs to be ported and tested. Thus, this will be put on hold until the above work is complete. * The rate control module 'sample' is the only currently supported module; onoe/amrr haven't been tested and have likely bit rotted a little. I'll follow up with some commits to make them work again for non-11n rates, but they won't be updated to handle 11n and aggregation. If someone wishes to do so then they're welcome to send along patches. * .. and "sample" doesn't really do a good job of 11n TX. Specifically, the metrics used (packet TX time and failure/success rates) isn't as useful for 11n. It's likely that it should be extended to take into account the aggregate throughput possible and then choose a rate which maximises that. Ie, it may be acceptable for a higher MCS rate with a higher failure to be used if it gives a more acceptable throughput/latency then a lower MCS rate @ a lower error rate. Again, patches will be gratefully accepted. Because of this, ATH_ENABLE_11N is still not enabled by default. Sponsored by: Hobnob, Inc. Obtained from: Linux, Atheros
2011-11-08 22:43:13 +00:00
if (dosched) {
Go back to direct-dispatch of the software queue and frame TX paths when they're being called from the TX completion handler. Going (back) through the taskqueue is just adding extra locking and latency to packet operations. This improves performance a little bit on most NICs. It still hasn't restored the original performance of the AR5416 NIC but the AR9160, AR9280 and later NICs behave very well with this. Tested: * AR5416 STA (still tops out at ~ 70mbit TCP, rather than 150mbit TCP..) * AR9160 hostap (good for both TX and RX) * AR9280 hostap (good for both TX and RX)
2013-02-11 07:48:26 +00:00
ATH_TX_LOCK(sc);
ath_txq_sched(sc, txq);
ATH_TX_UNLOCK(sc);
Introduce TX aggregation and software TX queue management for Atheros AR5416 and later wireless devices. This is a very large commit - the complete history can be found in the user/adrian/if_ath_tx branch. Legacy (ie, pre-AR5416) devices also use the per-software TXQ support and (in theory) can support non-aggregation ADDBA sessions. However, the net80211 stack doesn't currently support this. In summary: TX path: * queued frames normally go onto a per-TID, per-node queue * some special frames (eg ADDBA control frames) are thrown directly onto the relevant hardware queue so they can go out before any software queued frames are queued. * Add methods to create, suspend, resume and tear down an aggregation session. * Add in software retransmission of both normal and aggregate frames. * Add in completion handling of aggregate frames, including parsing the block ack bitmap provided by the hardware. * Write an aggregation function which can assemble frames into an aggregate based on the selected rate control and channel configuration. * The per-TID queues are locked based on their target hardware TX queue. This matches what ath9k/atheros does, and thus simplified porting over some of the aggregation logic. * When doing TX aggregation, stick the sequence number allocation in the TX path rather than net80211 TX path, and protect it by the TXQ lock. Rate control: * Delay rate control selection until the frame is about to be queued to the hardware, so retried frames can have their rate control choices changed. Frames with a static rate control selection have that applied before each TX, just to simplify the TX path (ie, not have "static" and "dynamic" rate control special cased.) * Teach ath_rate_sample about aggregates - both completion and errors. * Add an EWMA for tracking what the current "good" MCS rate is based on failure rates. Misc: * Introduce a bunch of dirty hacks and workarounds so TID mapping and net80211 frame inspection can be kept out of the net80211 layer. Because of the way this code works (and it's from Atheros and Linux ath9k), there is a consistent, 1:1 mapping between TID and AC. So we need to ensure that frames going to a specific TID will _always_ end up on the right AC, and vice versa, or the completion/locking will simply get very confused. I plan on addressing this mess in the future. Known issues: * There is no BAR frame transmission just yet. A whole lot of tidying up needs to occur before BAR frame TX can occur in the "correct" place - ie, once the TID TX queue has been drained. * Interface reset/purge/etc results in frames in the TX and RX queues being removed. This creates holes in the sequence numbers being assigned and the TX/RX AMPDU code (on either side) just hangs. * There's no filtered frame support at the present moment, so stations going into power saving mode will simply have a number of frames dropped - likely resulting in a traffic "hang". * Raw frame TX is going to just not function with 11n aggregation. Likely this needs to be modified to always override the sequence number if the frame is going into an aggregation session. However, general raw frame injection currently doesn't work in general in net80211, so let's just ignore this for now until this is sorted out. * HT protection is just not implemented and won't be until the above is sorted out. In addition, the AR5416 has issues RTS protecting large aggregates (anything >8k), so the work around needs to be ported and tested. Thus, this will be put on hold until the above work is complete. * The rate control module 'sample' is the only currently supported module; onoe/amrr haven't been tested and have likely bit rotted a little. I'll follow up with some commits to make them work again for non-11n rates, but they won't be updated to handle 11n and aggregation. If someone wishes to do so then they're welcome to send along patches. * .. and "sample" doesn't really do a good job of 11n TX. Specifically, the metrics used (packet TX time and failure/success rates) isn't as useful for 11n. It's likely that it should be extended to take into account the aggregate throughput possible and then choose a rate which maximises that. Ie, it may be acceptable for a higher MCS rate with a higher failure to be used if it gives a more acceptable throughput/latency then a lower MCS rate @ a lower error rate. Again, patches will be gratefully accepted. Because of this, ATH_ENABLE_11N is still not enabled by default. Sponsored by: Hobnob, Inc. Obtained from: Linux, Atheros
2011-11-08 22:43:13 +00:00
}
Migrate the ath(4) KTR logging to use an ATH_KTR() macro. This should eventually be unified with ATH_DEBUG() so I can get both from one macro; that may take some time. Add some new probes for TX and TX completion.
2012-09-24 20:35:56 +00:00
ATH_KTR(sc, ATH_KTR_TXCOMP, 1,
"ath_tx_processq: txq=%u: done",
txq->axq_qnum);
Phantom beacon miss workaround: track the tsf of the last received frame and if we get a beacon miss interrupt ignore it if we've received a frame within the beacon miss interval. This should never trigger and the handling at the net80211 layer should likewise deal with this but it doesn't hurt and can suppress extranous probe request frames. Note that we can legtimately get a bmiss when under heavy load. MFC after: 2 weeks
2006-02-09 22:03:26 +00:00
return nacked;
}
Merge in some fixes from the if_ath_tx branch. * Close down some of the kickpcu races, where the interrupt handler can and will run concurrently with the taskqueue. * Close down the TXQ active/completed race between the interrupt handler and the concurrently running tx completion taskqueue function. * Add some tx and rx interrupt count tracking, for debugging. * Fix the kickpcu logic in ath_rx_proc() to not simply drain and restart the TX queue - instead, assume the hardware isn't (too) confused and just restart RX DMA. This may break on previous chipsets, so if it does I'll add a HAL flag and conditionally handle this (ie, for broken chipsets, I'll just restore the "stop PCU / flush things / restart PCU" logic.) * Misc stuff Sponsored by: Hobnob, Inc.
2011-11-08 18:10:04 +00:00
#define TXQACTIVE(t, q) ( (t) & (1 << (q)))
Update with last year of work.
2004-12-08 17:34:36 +00:00
/*
* Deferred processing of transmit interrupt; special-cased
* for a single hardware transmit queue (e.g. 5210 and 5211).
*/
static void
ath_tx_proc_q0(void *arg, int npending)
{
struct ath_softc *sc = arg;
Merge in some fixes from the if_ath_tx branch. * Close down some of the kickpcu races, where the interrupt handler can and will run concurrently with the taskqueue. * Close down the TXQ active/completed race between the interrupt handler and the concurrently running tx completion taskqueue function. * Add some tx and rx interrupt count tracking, for debugging. * Fix the kickpcu logic in ath_rx_proc() to not simply drain and restart the TX queue - instead, assume the hardware isn't (too) confused and just restart RX DMA. This may break on previous chipsets, so if it does I'll add a HAL flag and conditionally handle this (ie, for broken chipsets, I'll just restore the "stop PCU / flush things / restart PCU" logic.) * Misc stuff Sponsored by: Hobnob, Inc.
2011-11-08 18:10:04 +00:00
uint32_t txqs;
Update with last year of work.
2004-12-08 17:34:36 +00:00
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
ATH_PCU_LOCK(sc);
sc->sc_txproc_cnt++;
Merge in some fixes from the if_ath_tx branch. * Close down some of the kickpcu races, where the interrupt handler can and will run concurrently with the taskqueue. * Close down the TXQ active/completed race between the interrupt handler and the concurrently running tx completion taskqueue function. * Add some tx and rx interrupt count tracking, for debugging. * Fix the kickpcu logic in ath_rx_proc() to not simply drain and restart the TX queue - instead, assume the hardware isn't (too) confused and just restart RX DMA. This may break on previous chipsets, so if it does I'll add a HAL flag and conditionally handle this (ie, for broken chipsets, I'll just restore the "stop PCU / flush things / restart PCU" logic.) * Misc stuff Sponsored by: Hobnob, Inc.
2011-11-08 18:10:04 +00:00
txqs = sc->sc_txq_active;
sc->sc_txq_active &= ~txqs;
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
ATH_PCU_UNLOCK(sc);
Merge in some fixes from the if_ath_tx branch. * Close down some of the kickpcu races, where the interrupt handler can and will run concurrently with the taskqueue. * Close down the TXQ active/completed race between the interrupt handler and the concurrently running tx completion taskqueue function. * Add some tx and rx interrupt count tracking, for debugging. * Fix the kickpcu logic in ath_rx_proc() to not simply drain and restart the TX queue - instead, assume the hardware isn't (too) confused and just restart RX DMA. This may break on previous chipsets, so if it does I'll add a HAL flag and conditionally handle this (ie, for broken chipsets, I'll just restore the "stop PCU / flush things / restart PCU" logic.) * Misc stuff Sponsored by: Hobnob, Inc.
2011-11-08 18:10:04 +00:00
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ATH_LOCK(sc);
ath_power_set_power_state(sc, HAL_PM_AWAKE);
ATH_UNLOCK(sc);
Migrate the ath(4) KTR logging to use an ATH_KTR() macro. This should eventually be unified with ATH_DEBUG() so I can get both from one macro; that may take some time. Add some new probes for TX and TX completion.
2012-09-24 20:35:56 +00:00
ATH_KTR(sc, ATH_KTR_TXCOMP, 1,
"ath_tx_proc_q0: txqs=0x%08x", txqs);
Preparation for correct 802.11n tx/rx handling. * Change ath_rx_proc() to ath_rx_tasklet(); make that the taskqueue function. This way (eventually) ath_rx_proc() can be called from elsewhere in the packet reset/processing queue so frames aren't just "flushed" during interface resets/reconfigure. This breaks 802.11n RX aggregation tracking. * Extend ath_tx_proc() to take a 'resched' flag, which marks whether to reschedule further RX PCU reads or not. * Change ath_tx_processq() to take a "dosched" flag, which will eventually be used to indicate whether to reschedule the software TX scheduler. Sponsored by: Hobnob, Inc.
2011-11-08 18:45:15 +00:00
if (TXQACTIVE(txqs, 0) && ath_tx_processq(sc, &sc->sc_txq[0], 1))
Merge in some fixes from the if_ath_tx branch. * Close down some of the kickpcu races, where the interrupt handler can and will run concurrently with the taskqueue. * Close down the TXQ active/completed race between the interrupt handler and the concurrently running tx completion taskqueue function. * Add some tx and rx interrupt count tracking, for debugging. * Fix the kickpcu logic in ath_rx_proc() to not simply drain and restart the TX queue - instead, assume the hardware isn't (too) confused and just restart RX DMA. This may break on previous chipsets, so if it does I'll add a HAL flag and conditionally handle this (ie, for broken chipsets, I'll just restore the "stop PCU / flush things / restart PCU" logic.) * Misc stuff Sponsored by: Hobnob, Inc.
2011-11-08 18:10:04 +00:00
/* XXX why is lastrx updated in tx code? */
Phantom beacon miss workaround: track the tsf of the last received frame and if we get a beacon miss interrupt ignore it if we've received a frame within the beacon miss interval. This should never trigger and the handling at the net80211 layer should likewise deal with this but it doesn't hurt and can suppress extranous probe request frames. Note that we can legtimately get a bmiss when under heavy load. MFC after: 2 weeks
2006-02-09 22:03:26 +00:00
sc->sc_lastrx = ath_hal_gettsf64(sc->sc_ah);
Merge in some fixes from the if_ath_tx branch. * Close down some of the kickpcu races, where the interrupt handler can and will run concurrently with the taskqueue. * Close down the TXQ active/completed race between the interrupt handler and the concurrently running tx completion taskqueue function. * Add some tx and rx interrupt count tracking, for debugging. * Fix the kickpcu logic in ath_rx_proc() to not simply drain and restart the TX queue - instead, assume the hardware isn't (too) confused and just restart RX DMA. This may break on previous chipsets, so if it does I'll add a HAL flag and conditionally handle this (ie, for broken chipsets, I'll just restore the "stop PCU / flush things / restart PCU" logic.) * Misc stuff Sponsored by: Hobnob, Inc.
2011-11-08 18:10:04 +00:00
if (TXQACTIVE(txqs, sc->sc_cabq->axq_qnum))
Preparation for correct 802.11n tx/rx handling. * Change ath_rx_proc() to ath_rx_tasklet(); make that the taskqueue function. This way (eventually) ath_rx_proc() can be called from elsewhere in the packet reset/processing queue so frames aren't just "flushed" during interface resets/reconfigure. This breaks 802.11n RX aggregation tracking. * Extend ath_tx_proc() to take a 'resched' flag, which marks whether to reschedule further RX PCU reads or not. * Change ath_tx_processq() to take a "dosched" flag, which will eventually be used to indicate whether to reschedule the software TX scheduler. Sponsored by: Hobnob, Inc.
2011-11-08 18:45:15 +00:00
ath_tx_processq(sc, sc->sc_cabq, 1);
replace if_watchdog w/ private callout; probably can merge this with the calibration work sometime in the future
2009-03-09 23:10:19 +00:00
sc->sc_wd_timer = 0;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
better led blinking
2005-01-18 19:03:04 +00:00
if (sc->sc_softled)
o With the addition of HT rates the set of h/w codes has a much wider range making the use of sc_hwmap to do direct mapping impractical. Switch to indexing by the rate index instead of the rate code and adjust associated state and logic appropriately. This has several benefits including simplification of the led code. o fix radiotap capture of HT rates o fix conditional compilation of HT radiotap support to be based on the hal having 5416 support; not the ABI version as hal builds may or may not include 5416 support
2008-10-27 18:22:44 +00:00
ath_led_event(sc, sc->sc_txrix);
better led blinking
2005-01-18 19:03:04 +00:00
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
ATH_PCU_LOCK(sc);
sc->sc_txproc_cnt--;
ATH_PCU_UNLOCK(sc);
Pull out the if_transmit() work and revert back to ath_start(). My changed had some rather significant behavioural changes to throughput. The two issues I noticed: * With if_start and the ifnet mbuf queue, any temporary latency would get eaten up by some mbufs being queued. With ath_transmit() queuing things to ath_buf's, I'd only get 512 TX buffers before I couldn't queue any further frames. * There's also some non-zero latency involved with TX being pushed into a taskqueue via direct dispatch. Any time the scheduler didn't immediately schedule the ath TX task would cause extra latency. Various 1ge/10ge drivers implement both direct dispatch (if the TX lock can be acquired) and deferred task transmission (if the TX lock can't be acquired), with frames being pushed into a drbd queue. I'll have to do this at some point, but until I figure out how to deal with 802.11 fragments, I'll have to wait a while longer. So what I saw: * lots of extra latency, specially under load - if the taskqueue wasn't immediately scheduled, things went pear shaped; * any extra latency would result in TX ath_buf's taking their sweet time being replenished, so any further calls to ath_transmit() would drop mbufs. * .. yes, there's no explicit backpressure here - things are just dropped. Eek. With this, the general performance has gone up, but those subtle if_start() related race conditions are back. For some reason, this is doubly-obvious with the AR5416 NIC and I don't quite understand why yet. There's an unrelated issue with AR5416 performance in STA mode (it's fine in AP mode when bridging frames, weirdly..) that requires a little further investigation. Specifically - it works fine on a Lenovo T40 (single core CPU) running a March 2012 9-STABLE kernel, but a Lenovo T60 (dual core) running an early November 2012 kernel behaves very poorly. The same hardware with an AR9160 or AR9280 behaves perfectly.
2013-02-13 05:32:19 +00:00
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ATH_LOCK(sc);
ath_power_restore_power_state(sc);
ATH_UNLOCK(sc);
Pull out the if_transmit() work and revert back to ath_start(). My changed had some rather significant behavioural changes to throughput. The two issues I noticed: * With if_start and the ifnet mbuf queue, any temporary latency would get eaten up by some mbufs being queued. With ath_transmit() queuing things to ath_buf's, I'd only get 512 TX buffers before I couldn't queue any further frames. * There's also some non-zero latency involved with TX being pushed into a taskqueue via direct dispatch. Any time the scheduler didn't immediately schedule the ath TX task would cause extra latency. Various 1ge/10ge drivers implement both direct dispatch (if the TX lock can be acquired) and deferred task transmission (if the TX lock can't be acquired), with frames being pushed into a drbd queue. I'll have to do this at some point, but until I figure out how to deal with 802.11 fragments, I'll have to wait a while longer. So what I saw: * lots of extra latency, specially under load - if the taskqueue wasn't immediately scheduled, things went pear shaped; * any extra latency would result in TX ath_buf's taking their sweet time being replenished, so any further calls to ath_transmit() would drop mbufs. * .. yes, there's no explicit backpressure here - things are just dropped. Eek. With this, the general performance has gone up, but those subtle if_start() related race conditions are back. For some reason, this is doubly-obvious with the AR5416 NIC and I don't quite understand why yet. There's an unrelated issue with AR5416 performance in STA mode (it's fine in AP mode when bridging frames, weirdly..) that requires a little further investigation. Specifically - it works fine on a Lenovo T40 (single core CPU) running a March 2012 9-STABLE kernel, but a Lenovo T60 (dual core) running an early November 2012 kernel behaves very poorly. The same hardware with an AR9160 or AR9280 behaves perfectly.
2013-02-13 05:32:19 +00:00
ath_tx_kick(sc);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
/*
Update with last year of work.
2004-12-08 17:34:36 +00:00
* Deferred processing of transmit interrupt; special-cased
* for four hardware queues, 0-3 (e.g. 5212 w/ WME support).
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
*/
static void
Update with last year of work.
2004-12-08 17:34:36 +00:00
ath_tx_proc_q0123(void *arg, int npending)
{
struct ath_softc *sc = arg;
Phantom beacon miss workaround: track the tsf of the last received frame and if we get a beacon miss interrupt ignore it if we've received a frame within the beacon miss interval. This should never trigger and the handling at the net80211 layer should likewise deal with this but it doesn't hurt and can suppress extranous probe request frames. Note that we can legtimately get a bmiss when under heavy load. MFC after: 2 weeks
2006-02-09 22:03:26 +00:00
int nacked;
Merge in some fixes from the if_ath_tx branch. * Close down some of the kickpcu races, where the interrupt handler can and will run concurrently with the taskqueue. * Close down the TXQ active/completed race between the interrupt handler and the concurrently running tx completion taskqueue function. * Add some tx and rx interrupt count tracking, for debugging. * Fix the kickpcu logic in ath_rx_proc() to not simply drain and restart the TX queue - instead, assume the hardware isn't (too) confused and just restart RX DMA. This may break on previous chipsets, so if it does I'll add a HAL flag and conditionally handle this (ie, for broken chipsets, I'll just restore the "stop PCU / flush things / restart PCU" logic.) * Misc stuff Sponsored by: Hobnob, Inc.
2011-11-08 18:10:04 +00:00
uint32_t txqs;
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
ATH_PCU_LOCK(sc);
sc->sc_txproc_cnt++;
Merge in some fixes from the if_ath_tx branch. * Close down some of the kickpcu races, where the interrupt handler can and will run concurrently with the taskqueue. * Close down the TXQ active/completed race between the interrupt handler and the concurrently running tx completion taskqueue function. * Add some tx and rx interrupt count tracking, for debugging. * Fix the kickpcu logic in ath_rx_proc() to not simply drain and restart the TX queue - instead, assume the hardware isn't (too) confused and just restart RX DMA. This may break on previous chipsets, so if it does I'll add a HAL flag and conditionally handle this (ie, for broken chipsets, I'll just restore the "stop PCU / flush things / restart PCU" logic.) * Misc stuff Sponsored by: Hobnob, Inc.
2011-11-08 18:10:04 +00:00
txqs = sc->sc_txq_active;
sc->sc_txq_active &= ~txqs;
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
ATH_PCU_UNLOCK(sc);
Update with last year of work.
2004-12-08 17:34:36 +00:00
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ATH_LOCK(sc);
ath_power_set_power_state(sc, HAL_PM_AWAKE);
ATH_UNLOCK(sc);
Migrate the ath(4) KTR logging to use an ATH_KTR() macro. This should eventually be unified with ATH_DEBUG() so I can get both from one macro; that may take some time. Add some new probes for TX and TX completion.
2012-09-24 20:35:56 +00:00
ATH_KTR(sc, ATH_KTR_TXCOMP, 1,
"ath_tx_proc_q0123: txqs=0x%08x", txqs);
Update with last year of work.
2004-12-08 17:34:36 +00:00
/*
* Process each active queue.
*/
Phantom beacon miss workaround: track the tsf of the last received frame and if we get a beacon miss interrupt ignore it if we've received a frame within the beacon miss interval. This should never trigger and the handling at the net80211 layer should likewise deal with this but it doesn't hurt and can suppress extranous probe request frames. Note that we can legtimately get a bmiss when under heavy load. MFC after: 2 weeks
2006-02-09 22:03:26 +00:00
nacked = 0;
Merge in some fixes from the if_ath_tx branch. * Close down some of the kickpcu races, where the interrupt handler can and will run concurrently with the taskqueue. * Close down the TXQ active/completed race between the interrupt handler and the concurrently running tx completion taskqueue function. * Add some tx and rx interrupt count tracking, for debugging. * Fix the kickpcu logic in ath_rx_proc() to not simply drain and restart the TX queue - instead, assume the hardware isn't (too) confused and just restart RX DMA. This may break on previous chipsets, so if it does I'll add a HAL flag and conditionally handle this (ie, for broken chipsets, I'll just restore the "stop PCU / flush things / restart PCU" logic.) * Misc stuff Sponsored by: Hobnob, Inc.
2011-11-08 18:10:04 +00:00
if (TXQACTIVE(txqs, 0))
Preparation for correct 802.11n tx/rx handling. * Change ath_rx_proc() to ath_rx_tasklet(); make that the taskqueue function. This way (eventually) ath_rx_proc() can be called from elsewhere in the packet reset/processing queue so frames aren't just "flushed" during interface resets/reconfigure. This breaks 802.11n RX aggregation tracking. * Extend ath_tx_proc() to take a 'resched' flag, which marks whether to reschedule further RX PCU reads or not. * Change ath_tx_processq() to take a "dosched" flag, which will eventually be used to indicate whether to reschedule the software TX scheduler. Sponsored by: Hobnob, Inc.
2011-11-08 18:45:15 +00:00
nacked += ath_tx_processq(sc, &sc->sc_txq[0], 1);
Merge in some fixes from the if_ath_tx branch. * Close down some of the kickpcu races, where the interrupt handler can and will run concurrently with the taskqueue. * Close down the TXQ active/completed race between the interrupt handler and the concurrently running tx completion taskqueue function. * Add some tx and rx interrupt count tracking, for debugging. * Fix the kickpcu logic in ath_rx_proc() to not simply drain and restart the TX queue - instead, assume the hardware isn't (too) confused and just restart RX DMA. This may break on previous chipsets, so if it does I'll add a HAL flag and conditionally handle this (ie, for broken chipsets, I'll just restore the "stop PCU / flush things / restart PCU" logic.) * Misc stuff Sponsored by: Hobnob, Inc.
2011-11-08 18:10:04 +00:00
if (TXQACTIVE(txqs, 1))
Preparation for correct 802.11n tx/rx handling. * Change ath_rx_proc() to ath_rx_tasklet(); make that the taskqueue function. This way (eventually) ath_rx_proc() can be called from elsewhere in the packet reset/processing queue so frames aren't just "flushed" during interface resets/reconfigure. This breaks 802.11n RX aggregation tracking. * Extend ath_tx_proc() to take a 'resched' flag, which marks whether to reschedule further RX PCU reads or not. * Change ath_tx_processq() to take a "dosched" flag, which will eventually be used to indicate whether to reschedule the software TX scheduler. Sponsored by: Hobnob, Inc.
2011-11-08 18:45:15 +00:00
nacked += ath_tx_processq(sc, &sc->sc_txq[1], 1);
Merge in some fixes from the if_ath_tx branch. * Close down some of the kickpcu races, where the interrupt handler can and will run concurrently with the taskqueue. * Close down the TXQ active/completed race between the interrupt handler and the concurrently running tx completion taskqueue function. * Add some tx and rx interrupt count tracking, for debugging. * Fix the kickpcu logic in ath_rx_proc() to not simply drain and restart the TX queue - instead, assume the hardware isn't (too) confused and just restart RX DMA. This may break on previous chipsets, so if it does I'll add a HAL flag and conditionally handle this (ie, for broken chipsets, I'll just restore the "stop PCU / flush things / restart PCU" logic.) * Misc stuff Sponsored by: Hobnob, Inc.
2011-11-08 18:10:04 +00:00
if (TXQACTIVE(txqs, 2))
Preparation for correct 802.11n tx/rx handling. * Change ath_rx_proc() to ath_rx_tasklet(); make that the taskqueue function. This way (eventually) ath_rx_proc() can be called from elsewhere in the packet reset/processing queue so frames aren't just "flushed" during interface resets/reconfigure. This breaks 802.11n RX aggregation tracking. * Extend ath_tx_proc() to take a 'resched' flag, which marks whether to reschedule further RX PCU reads or not. * Change ath_tx_processq() to take a "dosched" flag, which will eventually be used to indicate whether to reschedule the software TX scheduler. Sponsored by: Hobnob, Inc.
2011-11-08 18:45:15 +00:00
nacked += ath_tx_processq(sc, &sc->sc_txq[2], 1);
Merge in some fixes from the if_ath_tx branch. * Close down some of the kickpcu races, where the interrupt handler can and will run concurrently with the taskqueue. * Close down the TXQ active/completed race between the interrupt handler and the concurrently running tx completion taskqueue function. * Add some tx and rx interrupt count tracking, for debugging. * Fix the kickpcu logic in ath_rx_proc() to not simply drain and restart the TX queue - instead, assume the hardware isn't (too) confused and just restart RX DMA. This may break on previous chipsets, so if it does I'll add a HAL flag and conditionally handle this (ie, for broken chipsets, I'll just restore the "stop PCU / flush things / restart PCU" logic.) * Misc stuff Sponsored by: Hobnob, Inc.
2011-11-08 18:10:04 +00:00
if (TXQACTIVE(txqs, 3))
Preparation for correct 802.11n tx/rx handling. * Change ath_rx_proc() to ath_rx_tasklet(); make that the taskqueue function. This way (eventually) ath_rx_proc() can be called from elsewhere in the packet reset/processing queue so frames aren't just "flushed" during interface resets/reconfigure. This breaks 802.11n RX aggregation tracking. * Extend ath_tx_proc() to take a 'resched' flag, which marks whether to reschedule further RX PCU reads or not. * Change ath_tx_processq() to take a "dosched" flag, which will eventually be used to indicate whether to reschedule the software TX scheduler. Sponsored by: Hobnob, Inc.
2011-11-08 18:45:15 +00:00
nacked += ath_tx_processq(sc, &sc->sc_txq[3], 1);
Merge in some fixes from the if_ath_tx branch. * Close down some of the kickpcu races, where the interrupt handler can and will run concurrently with the taskqueue. * Close down the TXQ active/completed race between the interrupt handler and the concurrently running tx completion taskqueue function. * Add some tx and rx interrupt count tracking, for debugging. * Fix the kickpcu logic in ath_rx_proc() to not simply drain and restart the TX queue - instead, assume the hardware isn't (too) confused and just restart RX DMA. This may break on previous chipsets, so if it does I'll add a HAL flag and conditionally handle this (ie, for broken chipsets, I'll just restore the "stop PCU / flush things / restart PCU" logic.) * Misc stuff Sponsored by: Hobnob, Inc.
2011-11-08 18:10:04 +00:00
if (TXQACTIVE(txqs, sc->sc_cabq->axq_qnum))
Preparation for correct 802.11n tx/rx handling. * Change ath_rx_proc() to ath_rx_tasklet(); make that the taskqueue function. This way (eventually) ath_rx_proc() can be called from elsewhere in the packet reset/processing queue so frames aren't just "flushed" during interface resets/reconfigure. This breaks 802.11n RX aggregation tracking. * Extend ath_tx_proc() to take a 'resched' flag, which marks whether to reschedule further RX PCU reads or not. * Change ath_tx_processq() to take a "dosched" flag, which will eventually be used to indicate whether to reschedule the software TX scheduler. Sponsored by: Hobnob, Inc.
2011-11-08 18:45:15 +00:00
ath_tx_processq(sc, sc->sc_cabq, 1);
Phantom beacon miss workaround: track the tsf of the last received frame and if we get a beacon miss interrupt ignore it if we've received a frame within the beacon miss interval. This should never trigger and the handling at the net80211 layer should likewise deal with this but it doesn't hurt and can suppress extranous probe request frames. Note that we can legtimately get a bmiss when under heavy load. MFC after: 2 weeks
2006-02-09 22:03:26 +00:00
if (nacked)
sc->sc_lastrx = ath_hal_gettsf64(sc->sc_ah);
Update with last year of work.
2004-12-08 17:34:36 +00:00
replace if_watchdog w/ private callout; probably can merge this with the calibration work sometime in the future
2009-03-09 23:10:19 +00:00
sc->sc_wd_timer = 0;
Update with last year of work.
2004-12-08 17:34:36 +00:00
better led blinking
2005-01-18 19:03:04 +00:00
if (sc->sc_softled)
o With the addition of HT rates the set of h/w codes has a much wider range making the use of sc_hwmap to do direct mapping impractical. Switch to indexing by the rate index instead of the rate code and adjust associated state and logic appropriately. This has several benefits including simplification of the led code. o fix radiotap capture of HT rates o fix conditional compilation of HT radiotap support to be based on the hal having 5416 support; not the ABI version as hal builds may or may not include 5416 support
2008-10-27 18:22:44 +00:00
ath_led_event(sc, sc->sc_txrix);
better led blinking
2005-01-18 19:03:04 +00:00
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
ATH_PCU_LOCK(sc);
sc->sc_txproc_cnt--;
ATH_PCU_UNLOCK(sc);
Pull out the if_transmit() work and revert back to ath_start(). My changed had some rather significant behavioural changes to throughput. The two issues I noticed: * With if_start and the ifnet mbuf queue, any temporary latency would get eaten up by some mbufs being queued. With ath_transmit() queuing things to ath_buf's, I'd only get 512 TX buffers before I couldn't queue any further frames. * There's also some non-zero latency involved with TX being pushed into a taskqueue via direct dispatch. Any time the scheduler didn't immediately schedule the ath TX task would cause extra latency. Various 1ge/10ge drivers implement both direct dispatch (if the TX lock can be acquired) and deferred task transmission (if the TX lock can't be acquired), with frames being pushed into a drbd queue. I'll have to do this at some point, but until I figure out how to deal with 802.11 fragments, I'll have to wait a while longer. So what I saw: * lots of extra latency, specially under load - if the taskqueue wasn't immediately scheduled, things went pear shaped; * any extra latency would result in TX ath_buf's taking their sweet time being replenished, so any further calls to ath_transmit() would drop mbufs. * .. yes, there's no explicit backpressure here - things are just dropped. Eek. With this, the general performance has gone up, but those subtle if_start() related race conditions are back. For some reason, this is doubly-obvious with the AR5416 NIC and I don't quite understand why yet. There's an unrelated issue with AR5416 performance in STA mode (it's fine in AP mode when bridging frames, weirdly..) that requires a little further investigation. Specifically - it works fine on a Lenovo T40 (single core CPU) running a March 2012 9-STABLE kernel, but a Lenovo T60 (dual core) running an early November 2012 kernel behaves very poorly. The same hardware with an AR9160 or AR9280 behaves perfectly.
2013-02-13 05:32:19 +00:00
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ATH_LOCK(sc);
ath_power_restore_power_state(sc);
ATH_UNLOCK(sc);
Pull out the if_transmit() work and revert back to ath_start(). My changed had some rather significant behavioural changes to throughput. The two issues I noticed: * With if_start and the ifnet mbuf queue, any temporary latency would get eaten up by some mbufs being queued. With ath_transmit() queuing things to ath_buf's, I'd only get 512 TX buffers before I couldn't queue any further frames. * There's also some non-zero latency involved with TX being pushed into a taskqueue via direct dispatch. Any time the scheduler didn't immediately schedule the ath TX task would cause extra latency. Various 1ge/10ge drivers implement both direct dispatch (if the TX lock can be acquired) and deferred task transmission (if the TX lock can't be acquired), with frames being pushed into a drbd queue. I'll have to do this at some point, but until I figure out how to deal with 802.11 fragments, I'll have to wait a while longer. So what I saw: * lots of extra latency, specially under load - if the taskqueue wasn't immediately scheduled, things went pear shaped; * any extra latency would result in TX ath_buf's taking their sweet time being replenished, so any further calls to ath_transmit() would drop mbufs. * .. yes, there's no explicit backpressure here - things are just dropped. Eek. With this, the general performance has gone up, but those subtle if_start() related race conditions are back. For some reason, this is doubly-obvious with the AR5416 NIC and I don't quite understand why yet. There's an unrelated issue with AR5416 performance in STA mode (it's fine in AP mode when bridging frames, weirdly..) that requires a little further investigation. Specifically - it works fine on a Lenovo T40 (single core CPU) running a March 2012 9-STABLE kernel, but a Lenovo T60 (dual core) running an early November 2012 kernel behaves very poorly. The same hardware with an AR9160 or AR9280 behaves perfectly.
2013-02-13 05:32:19 +00:00
ath_tx_kick(sc);
Update with last year of work.
2004-12-08 17:34:36 +00:00
}
/*
* Deferred processing of transmit interrupt.
*/
static void
ath_tx_proc(void *arg, int npending)
{
struct ath_softc *sc = arg;
Phantom beacon miss workaround: track the tsf of the last received frame and if we get a beacon miss interrupt ignore it if we've received a frame within the beacon miss interval. This should never trigger and the handling at the net80211 layer should likewise deal with this but it doesn't hurt and can suppress extranous probe request frames. Note that we can legtimately get a bmiss when under heavy load. MFC after: 2 weeks
2006-02-09 22:03:26 +00:00
int i, nacked;
Merge in some fixes from the if_ath_tx branch. * Close down some of the kickpcu races, where the interrupt handler can and will run concurrently with the taskqueue. * Close down the TXQ active/completed race between the interrupt handler and the concurrently running tx completion taskqueue function. * Add some tx and rx interrupt count tracking, for debugging. * Fix the kickpcu logic in ath_rx_proc() to not simply drain and restart the TX queue - instead, assume the hardware isn't (too) confused and just restart RX DMA. This may break on previous chipsets, so if it does I'll add a HAL flag and conditionally handle this (ie, for broken chipsets, I'll just restore the "stop PCU / flush things / restart PCU" logic.) * Misc stuff Sponsored by: Hobnob, Inc.
2011-11-08 18:10:04 +00:00
uint32_t txqs;
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
ATH_PCU_LOCK(sc);
sc->sc_txproc_cnt++;
Merge in some fixes from the if_ath_tx branch. * Close down some of the kickpcu races, where the interrupt handler can and will run concurrently with the taskqueue. * Close down the TXQ active/completed race between the interrupt handler and the concurrently running tx completion taskqueue function. * Add some tx and rx interrupt count tracking, for debugging. * Fix the kickpcu logic in ath_rx_proc() to not simply drain and restart the TX queue - instead, assume the hardware isn't (too) confused and just restart RX DMA. This may break on previous chipsets, so if it does I'll add a HAL flag and conditionally handle this (ie, for broken chipsets, I'll just restore the "stop PCU / flush things / restart PCU" logic.) * Misc stuff Sponsored by: Hobnob, Inc.
2011-11-08 18:10:04 +00:00
txqs = sc->sc_txq_active;
sc->sc_txq_active &= ~txqs;
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
ATH_PCU_UNLOCK(sc);
Update with last year of work.
2004-12-08 17:34:36 +00:00
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ATH_LOCK(sc);
ath_power_set_power_state(sc, HAL_PM_AWAKE);
ATH_UNLOCK(sc);
Migrate the ath(4) KTR logging to use an ATH_KTR() macro. This should eventually be unified with ATH_DEBUG() so I can get both from one macro; that may take some time. Add some new probes for TX and TX completion.
2012-09-24 20:35:56 +00:00
ATH_KTR(sc, ATH_KTR_TXCOMP, 1, "ath_tx_proc: txqs=0x%08x", txqs);
Update with last year of work.
2004-12-08 17:34:36 +00:00
/*
* Process each active queue.
*/
Phantom beacon miss workaround: track the tsf of the last received frame and if we get a beacon miss interrupt ignore it if we've received a frame within the beacon miss interval. This should never trigger and the handling at the net80211 layer should likewise deal with this but it doesn't hurt and can suppress extranous probe request frames. Note that we can legtimately get a bmiss when under heavy load. MFC after: 2 weeks
2006-02-09 22:03:26 +00:00
nacked = 0;
Update with last year of work.
2004-12-08 17:34:36 +00:00
for (i = 0; i < HAL_NUM_TX_QUEUES; i++)
Merge in some fixes from the if_ath_tx branch. * Close down some of the kickpcu races, where the interrupt handler can and will run concurrently with the taskqueue. * Close down the TXQ active/completed race between the interrupt handler and the concurrently running tx completion taskqueue function. * Add some tx and rx interrupt count tracking, for debugging. * Fix the kickpcu logic in ath_rx_proc() to not simply drain and restart the TX queue - instead, assume the hardware isn't (too) confused and just restart RX DMA. This may break on previous chipsets, so if it does I'll add a HAL flag and conditionally handle this (ie, for broken chipsets, I'll just restore the "stop PCU / flush things / restart PCU" logic.) * Misc stuff Sponsored by: Hobnob, Inc.
2011-11-08 18:10:04 +00:00
if (ATH_TXQ_SETUP(sc, i) && TXQACTIVE(txqs, i))
Preparation for correct 802.11n tx/rx handling. * Change ath_rx_proc() to ath_rx_tasklet(); make that the taskqueue function. This way (eventually) ath_rx_proc() can be called from elsewhere in the packet reset/processing queue so frames aren't just "flushed" during interface resets/reconfigure. This breaks 802.11n RX aggregation tracking. * Extend ath_tx_proc() to take a 'resched' flag, which marks whether to reschedule further RX PCU reads or not. * Change ath_tx_processq() to take a "dosched" flag, which will eventually be used to indicate whether to reschedule the software TX scheduler. Sponsored by: Hobnob, Inc.
2011-11-08 18:45:15 +00:00
nacked += ath_tx_processq(sc, &sc->sc_txq[i], 1);
Phantom beacon miss workaround: track the tsf of the last received frame and if we get a beacon miss interrupt ignore it if we've received a frame within the beacon miss interval. This should never trigger and the handling at the net80211 layer should likewise deal with this but it doesn't hurt and can suppress extranous probe request frames. Note that we can legtimately get a bmiss when under heavy load. MFC after: 2 weeks
2006-02-09 22:03:26 +00:00
if (nacked)
sc->sc_lastrx = ath_hal_gettsf64(sc->sc_ah);
Update with last year of work.
2004-12-08 17:34:36 +00:00
replace if_watchdog w/ private callout; probably can merge this with the calibration work sometime in the future
2009-03-09 23:10:19 +00:00
sc->sc_wd_timer = 0;
Update with last year of work.
2004-12-08 17:34:36 +00:00
better led blinking
2005-01-18 19:03:04 +00:00
if (sc->sc_softled)
o With the addition of HT rates the set of h/w codes has a much wider range making the use of sc_hwmap to do direct mapping impractical. Switch to indexing by the rate index instead of the rate code and adjust associated state and logic appropriately. This has several benefits including simplification of the led code. o fix radiotap capture of HT rates o fix conditional compilation of HT radiotap support to be based on the hal having 5416 support; not the ABI version as hal builds may or may not include 5416 support
2008-10-27 18:22:44 +00:00
ath_led_event(sc, sc->sc_txrix);
better led blinking
2005-01-18 19:03:04 +00:00
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
ATH_PCU_LOCK(sc);
sc->sc_txproc_cnt--;
ATH_PCU_UNLOCK(sc);
Pull out the if_transmit() work and revert back to ath_start(). My changed had some rather significant behavioural changes to throughput. The two issues I noticed: * With if_start and the ifnet mbuf queue, any temporary latency would get eaten up by some mbufs being queued. With ath_transmit() queuing things to ath_buf's, I'd only get 512 TX buffers before I couldn't queue any further frames. * There's also some non-zero latency involved with TX being pushed into a taskqueue via direct dispatch. Any time the scheduler didn't immediately schedule the ath TX task would cause extra latency. Various 1ge/10ge drivers implement both direct dispatch (if the TX lock can be acquired) and deferred task transmission (if the TX lock can't be acquired), with frames being pushed into a drbd queue. I'll have to do this at some point, but until I figure out how to deal with 802.11 fragments, I'll have to wait a while longer. So what I saw: * lots of extra latency, specially under load - if the taskqueue wasn't immediately scheduled, things went pear shaped; * any extra latency would result in TX ath_buf's taking their sweet time being replenished, so any further calls to ath_transmit() would drop mbufs. * .. yes, there's no explicit backpressure here - things are just dropped. Eek. With this, the general performance has gone up, but those subtle if_start() related race conditions are back. For some reason, this is doubly-obvious with the AR5416 NIC and I don't quite understand why yet. There's an unrelated issue with AR5416 performance in STA mode (it's fine in AP mode when bridging frames, weirdly..) that requires a little further investigation. Specifically - it works fine on a Lenovo T40 (single core CPU) running a March 2012 9-STABLE kernel, but a Lenovo T60 (dual core) running an early November 2012 kernel behaves very poorly. The same hardware with an AR9160 or AR9280 behaves perfectly.
2013-02-13 05:32:19 +00:00
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ATH_LOCK(sc);
ath_power_restore_power_state(sc);
ATH_UNLOCK(sc);
Pull out the if_transmit() work and revert back to ath_start(). My changed had some rather significant behavioural changes to throughput. The two issues I noticed: * With if_start and the ifnet mbuf queue, any temporary latency would get eaten up by some mbufs being queued. With ath_transmit() queuing things to ath_buf's, I'd only get 512 TX buffers before I couldn't queue any further frames. * There's also some non-zero latency involved with TX being pushed into a taskqueue via direct dispatch. Any time the scheduler didn't immediately schedule the ath TX task would cause extra latency. Various 1ge/10ge drivers implement both direct dispatch (if the TX lock can be acquired) and deferred task transmission (if the TX lock can't be acquired), with frames being pushed into a drbd queue. I'll have to do this at some point, but until I figure out how to deal with 802.11 fragments, I'll have to wait a while longer. So what I saw: * lots of extra latency, specially under load - if the taskqueue wasn't immediately scheduled, things went pear shaped; * any extra latency would result in TX ath_buf's taking their sweet time being replenished, so any further calls to ath_transmit() would drop mbufs. * .. yes, there's no explicit backpressure here - things are just dropped. Eek. With this, the general performance has gone up, but those subtle if_start() related race conditions are back. For some reason, this is doubly-obvious with the AR5416 NIC and I don't quite understand why yet. There's an unrelated issue with AR5416 performance in STA mode (it's fine in AP mode when bridging frames, weirdly..) that requires a little further investigation. Specifically - it works fine on a Lenovo T40 (single core CPU) running a March 2012 9-STABLE kernel, but a Lenovo T60 (dual core) running an early November 2012 kernel behaves very poorly. The same hardware with an AR9160 or AR9280 behaves perfectly.
2013-02-13 05:32:19 +00:00
ath_tx_kick(sc);
Update with last year of work.
2004-12-08 17:34:36 +00:00
}
Some more various fixes, etc from my 11n branch. * When doing software TX queue handling and flush, it's possible that the deletion of a VAP (eg a STA shutdown) will queue a "STA Disassociate" frame whilst the interface is being deleted. The VAP is then deleted, and the frame ends up being queued to a node that is freed before it can be TX'ed. Things go awry at this point. There's no way at the present to avoid freeing the underlying node when the vap is being deleted. It's too late in the game. I suspect the real fix is to make sure the frame is software queued with no completion information somehow, so it doesn't link back to a node whose underlying VAP has been freed. For now, we'll just have to do this. * Add some comments showing what's going on. * Move an instance of the ATH_LOCK() around to protect the interrupt set. I'll worry about changing that to a PCU lock later on once the 11n code is in the tree. Sponsored by: Hobnob, Inc.
2011-11-08 19:18:34 +00:00
#undef TXQACTIVE
Update with last year of work.
2004-12-08 17:34:36 +00:00
Defer the rescheduling of TID -> TXQ frames in some instances. Right now ath_txq_sched() is mainly called from the TX ath_tx_processq() routine, which is (mostly) done as part of the taskqueue. It shouldn't be called outside the taskqueue. But now that I'm about to flip back on BAR TX, I'm going to start stressing the ath_tx_tid_pause() and ath_tx_tid_resume() paths. What I don't want to have happen is a reschedule of the TID traffic _during_ the completion of TX frames. Ideally I'd like to have a way to flag back up to the processing code that the current hardware queue should be rechecked for software TID queue frames. But for now, this should suffice for the BAR TX case. I may eventually delete this code once I've brought some further sanity to the general TX queue/completion path.
2012-03-29 17:39:18 +00:00
/*
* Deferred processing of TXQ rescheduling.
*/
static void
ath_txq_sched_tasklet(void *arg, int npending)
{
struct ath_softc *sc = arg;
int i;
/* XXX is skipping ok? */
ATH_PCU_LOCK(sc);
#if 0
if (sc->sc_inreset_cnt > 0) {
device_printf(sc->sc_dev,
"%s: sc_inreset_cnt > 0; skipping\n", __func__);
ATH_PCU_UNLOCK(sc);
return;
}
#endif
sc->sc_txproc_cnt++;
ATH_PCU_UNLOCK(sc);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ATH_LOCK(sc);
ath_power_set_power_state(sc, HAL_PM_AWAKE);
ATH_UNLOCK(sc);
Delete the per-TXQ locks and replace them with a single TX lock. I couldn't think of a way to maintain the hardware TXQ locks _and_ layer on top of that per-TXQ software queuing and any other kind of fine-grained locks (eg per-TID, or per-node locks.) So for now, to facilitate some further code refactoring and development as part of the final push to get software queue ps-poll and u-apsd handling into this driver, just do away with them entirely. I may eventually bring them back at some point, when it looks slightly more architectually cleaner to do so. But as it stands at the present, it's not really buying us much: * in order to properly serialise things and not get bitten by scheduling and locking interactions with things higher up in the stack, we need to wrap the whole TX path in a long held lock. Otherwise we can end up being pre-empted during frame handling, resulting in some out of order frame handling between sequence number allocation and encryption handling (ie, the seqno and the CCMP IV get out of sequence); * .. so whilst that's the case, holding the lock for that long means that we're acquiring and releasing the TXQ lock _inside_ that context; * And we also acquire it per-frame during frame completion, but we currently can't hold the lock for the duration of the TX completion as we need to call net80211 layer things with the locks _unheld_ to avoid LOR. * .. the other places were grab that lock are reset/flush, which don't happen often. My eventual aim is to change the TX path so all rejected frame transmissions and all frame completions result in any ieee80211_free_node() calls to occur outside of the TX lock; then I can cut back on the amount of locking that goes on here. There may be some LORs that occur when ieee80211_free_node() is called when the TX queue path fails; I'll begin to address these in follow-up commits.
2012-12-02 06:24:08 +00:00
ATH_TX_LOCK(sc);
Defer the rescheduling of TID -> TXQ frames in some instances. Right now ath_txq_sched() is mainly called from the TX ath_tx_processq() routine, which is (mostly) done as part of the taskqueue. It shouldn't be called outside the taskqueue. But now that I'm about to flip back on BAR TX, I'm going to start stressing the ath_tx_tid_pause() and ath_tx_tid_resume() paths. What I don't want to have happen is a reschedule of the TID traffic _during_ the completion of TX frames. Ideally I'd like to have a way to flag back up to the processing code that the current hardware queue should be rechecked for software TID queue frames. But for now, this should suffice for the BAR TX case. I may eventually delete this code once I've brought some further sanity to the general TX queue/completion path.
2012-03-29 17:39:18 +00:00
for (i = 0; i < HAL_NUM_TX_QUEUES; i++) {
oops, add a missing lock.
2012-03-29 21:54:19 +00:00
if (ATH_TXQ_SETUP(sc, i)) {
Defer the rescheduling of TID -> TXQ frames in some instances. Right now ath_txq_sched() is mainly called from the TX ath_tx_processq() routine, which is (mostly) done as part of the taskqueue. It shouldn't be called outside the taskqueue. But now that I'm about to flip back on BAR TX, I'm going to start stressing the ath_tx_tid_pause() and ath_tx_tid_resume() paths. What I don't want to have happen is a reschedule of the TID traffic _during_ the completion of TX frames. Ideally I'd like to have a way to flag back up to the processing code that the current hardware queue should be rechecked for software TID queue frames. But for now, this should suffice for the BAR TX case. I may eventually delete this code once I've brought some further sanity to the general TX queue/completion path.
2012-03-29 17:39:18 +00:00
ath_txq_sched(sc, &sc->sc_txq[i]);
oops, add a missing lock.
2012-03-29 21:54:19 +00:00
}
Defer the rescheduling of TID -> TXQ frames in some instances. Right now ath_txq_sched() is mainly called from the TX ath_tx_processq() routine, which is (mostly) done as part of the taskqueue. It shouldn't be called outside the taskqueue. But now that I'm about to flip back on BAR TX, I'm going to start stressing the ath_tx_tid_pause() and ath_tx_tid_resume() paths. What I don't want to have happen is a reschedule of the TID traffic _during_ the completion of TX frames. Ideally I'd like to have a way to flag back up to the processing code that the current hardware queue should be rechecked for software TID queue frames. But for now, this should suffice for the BAR TX case. I may eventually delete this code once I've brought some further sanity to the general TX queue/completion path.
2012-03-29 17:39:18 +00:00
}
Delete the per-TXQ locks and replace them with a single TX lock. I couldn't think of a way to maintain the hardware TXQ locks _and_ layer on top of that per-TXQ software queuing and any other kind of fine-grained locks (eg per-TID, or per-node locks.) So for now, to facilitate some further code refactoring and development as part of the final push to get software queue ps-poll and u-apsd handling into this driver, just do away with them entirely. I may eventually bring them back at some point, when it looks slightly more architectually cleaner to do so. But as it stands at the present, it's not really buying us much: * in order to properly serialise things and not get bitten by scheduling and locking interactions with things higher up in the stack, we need to wrap the whole TX path in a long held lock. Otherwise we can end up being pre-empted during frame handling, resulting in some out of order frame handling between sequence number allocation and encryption handling (ie, the seqno and the CCMP IV get out of sequence); * .. so whilst that's the case, holding the lock for that long means that we're acquiring and releasing the TXQ lock _inside_ that context; * And we also acquire it per-frame during frame completion, but we currently can't hold the lock for the duration of the TX completion as we need to call net80211 layer things with the locks _unheld_ to avoid LOR. * .. the other places were grab that lock are reset/flush, which don't happen often. My eventual aim is to change the TX path so all rejected frame transmissions and all frame completions result in any ieee80211_free_node() calls to occur outside of the TX lock; then I can cut back on the amount of locking that goes on here. There may be some LORs that occur when ieee80211_free_node() is called when the TX queue path fails; I'll begin to address these in follow-up commits.
2012-12-02 06:24:08 +00:00
ATH_TX_UNLOCK(sc);
Defer the rescheduling of TID -> TXQ frames in some instances. Right now ath_txq_sched() is mainly called from the TX ath_tx_processq() routine, which is (mostly) done as part of the taskqueue. It shouldn't be called outside the taskqueue. But now that I'm about to flip back on BAR TX, I'm going to start stressing the ath_tx_tid_pause() and ath_tx_tid_resume() paths. What I don't want to have happen is a reschedule of the TID traffic _during_ the completion of TX frames. Ideally I'd like to have a way to flag back up to the processing code that the current hardware queue should be rechecked for software TID queue frames. But for now, this should suffice for the BAR TX case. I may eventually delete this code once I've brought some further sanity to the general TX queue/completion path.
2012-03-29 17:39:18 +00:00
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ATH_LOCK(sc);
ath_power_restore_power_state(sc);
ATH_UNLOCK(sc);
Defer the rescheduling of TID -> TXQ frames in some instances. Right now ath_txq_sched() is mainly called from the TX ath_tx_processq() routine, which is (mostly) done as part of the taskqueue. It shouldn't be called outside the taskqueue. But now that I'm about to flip back on BAR TX, I'm going to start stressing the ath_tx_tid_pause() and ath_tx_tid_resume() paths. What I don't want to have happen is a reschedule of the TID traffic _during_ the completion of TX frames. Ideally I'd like to have a way to flag back up to the processing code that the current hardware queue should be rechecked for software TID queue frames. But for now, this should suffice for the BAR TX case. I may eventually delete this code once I've brought some further sanity to the general TX queue/completion path.
2012-03-29 17:39:18 +00:00
ATH_PCU_LOCK(sc);
sc->sc_txproc_cnt--;
ATH_PCU_UNLOCK(sc);
}
Replace the direct sc_txbuf manipulation with a pair of functions. This is preparation work for having a separate ath_buf queue for management traffic. PR: kern/168170
2012-06-13 05:39:16 +00:00
void
ath_returnbuf_tail(struct ath_softc *sc, struct ath_buf *bf)
{
ATH_TXBUF_LOCK_ASSERT(sc);
Implement a separate, smaller pool of ath_buf entries for use by management traffic. * Create sc_mgmt_txbuf and sc_mgmt_txdesc, initialise/free them appropriately. * Create an enum to represent buffer types in the API. * Extend ath_getbuf() and _ath_getbuf_locked() to take the above enum. * Right now anything sent via ic_raw_xmit() allocates via ATH_BUFTYPE_MGMT. This may not be very useful. * Add ATH_BUF_MGMT flag (ath_buf.bf_flags) which indicates the current buffer is a mgmt buffer and should go back onto the mgmt free list. * Extend 'txagg' to include debugging output for both normal and mgmt txbufs. * When checking/clearing ATH_BUF_BUSY, do it on both TX pools. Tested: * STA mode, with heavy UDP injection via iperf. This filled the TX queue however BARs were still going out successfully. TODO: * Initialise the mgmt buffers with ATH_BUF_MGMT and then ensure the right type is being allocated and freed on the appropriate list. That'd save a write operation (to bf->bf_flags) on each buffer alloc/free. * Test on AP mode, ensure that BAR TX and probe responses go out nicely when the main TX queue is filled (eg with paused traffic to a TID, awaiting a BAR to complete.) PR: kern/168170
2012-06-13 06:57:55 +00:00
if (bf->bf_flags & ATH_BUF_MGMT)
TAILQ_INSERT_TAIL(&sc->sc_txbuf_mgmt, bf, bf_list);
Implement a global (all non-mgmt traffic) TX ath_buf limitation when ath_start() is called. This (defaults to 10 frames) gives for a little headway in the TX ath_buf allocation, so buffer cloning is still possible. This requires a lot omre experimenting and tuning. It also doesn't stop a node/TID from consuming all of the available ath_buf's, especially when the node is going through high packet loss or only talking at a low TX rate. It also doesn't stop a paused TID from taking all of the ath_bufs. I'll look at fixing that up in subsequent commits. PR: kern/168170
2012-06-14 00:51:53 +00:00
else {
Implement a separate, smaller pool of ath_buf entries for use by management traffic. * Create sc_mgmt_txbuf and sc_mgmt_txdesc, initialise/free them appropriately. * Create an enum to represent buffer types in the API. * Extend ath_getbuf() and _ath_getbuf_locked() to take the above enum. * Right now anything sent via ic_raw_xmit() allocates via ATH_BUFTYPE_MGMT. This may not be very useful. * Add ATH_BUF_MGMT flag (ath_buf.bf_flags) which indicates the current buffer is a mgmt buffer and should go back onto the mgmt free list. * Extend 'txagg' to include debugging output for both normal and mgmt txbufs. * When checking/clearing ATH_BUF_BUSY, do it on both TX pools. Tested: * STA mode, with heavy UDP injection via iperf. This filled the TX queue however BARs were still going out successfully. TODO: * Initialise the mgmt buffers with ATH_BUF_MGMT and then ensure the right type is being allocated and freed on the appropriate list. That'd save a write operation (to bf->bf_flags) on each buffer alloc/free. * Test on AP mode, ensure that BAR TX and probe responses go out nicely when the main TX queue is filled (eg with paused traffic to a TID, awaiting a BAR to complete.) PR: kern/168170
2012-06-13 06:57:55 +00:00
TAILQ_INSERT_TAIL(&sc->sc_txbuf, bf, bf_list);
Implement a global (all non-mgmt traffic) TX ath_buf limitation when ath_start() is called. This (defaults to 10 frames) gives for a little headway in the TX ath_buf allocation, so buffer cloning is still possible. This requires a lot omre experimenting and tuning. It also doesn't stop a node/TID from consuming all of the available ath_buf's, especially when the node is going through high packet loss or only talking at a low TX rate. It also doesn't stop a paused TID from taking all of the ath_bufs. I'll look at fixing that up in subsequent commits. PR: kern/168170
2012-06-14 00:51:53 +00:00
sc->sc_txbuf_cnt++;
if (sc->sc_txbuf_cnt > ath_txbuf) {
device_printf(sc->sc_dev,
"%s: sc_txbuf_cnt > %d?\n",
__func__,
ath_txbuf);
sc->sc_txbuf_cnt = ath_txbuf;
}
}
Replace the direct sc_txbuf manipulation with a pair of functions. This is preparation work for having a separate ath_buf queue for management traffic. PR: kern/168170
2012-06-13 05:39:16 +00:00
}
void
ath_returnbuf_head(struct ath_softc *sc, struct ath_buf *bf)
{
ATH_TXBUF_LOCK_ASSERT(sc);
Implement a separate, smaller pool of ath_buf entries for use by management traffic. * Create sc_mgmt_txbuf and sc_mgmt_txdesc, initialise/free them appropriately. * Create an enum to represent buffer types in the API. * Extend ath_getbuf() and _ath_getbuf_locked() to take the above enum. * Right now anything sent via ic_raw_xmit() allocates via ATH_BUFTYPE_MGMT. This may not be very useful. * Add ATH_BUF_MGMT flag (ath_buf.bf_flags) which indicates the current buffer is a mgmt buffer and should go back onto the mgmt free list. * Extend 'txagg' to include debugging output for both normal and mgmt txbufs. * When checking/clearing ATH_BUF_BUSY, do it on both TX pools. Tested: * STA mode, with heavy UDP injection via iperf. This filled the TX queue however BARs were still going out successfully. TODO: * Initialise the mgmt buffers with ATH_BUF_MGMT and then ensure the right type is being allocated and freed on the appropriate list. That'd save a write operation (to bf->bf_flags) on each buffer alloc/free. * Test on AP mode, ensure that BAR TX and probe responses go out nicely when the main TX queue is filled (eg with paused traffic to a TID, awaiting a BAR to complete.) PR: kern/168170
2012-06-13 06:57:55 +00:00
if (bf->bf_flags & ATH_BUF_MGMT)
TAILQ_INSERT_HEAD(&sc->sc_txbuf_mgmt, bf, bf_list);
Implement a global (all non-mgmt traffic) TX ath_buf limitation when ath_start() is called. This (defaults to 10 frames) gives for a little headway in the TX ath_buf allocation, so buffer cloning is still possible. This requires a lot omre experimenting and tuning. It also doesn't stop a node/TID from consuming all of the available ath_buf's, especially when the node is going through high packet loss or only talking at a low TX rate. It also doesn't stop a paused TID from taking all of the ath_bufs. I'll look at fixing that up in subsequent commits. PR: kern/168170
2012-06-14 00:51:53 +00:00
else {
Implement a separate, smaller pool of ath_buf entries for use by management traffic. * Create sc_mgmt_txbuf and sc_mgmt_txdesc, initialise/free them appropriately. * Create an enum to represent buffer types in the API. * Extend ath_getbuf() and _ath_getbuf_locked() to take the above enum. * Right now anything sent via ic_raw_xmit() allocates via ATH_BUFTYPE_MGMT. This may not be very useful. * Add ATH_BUF_MGMT flag (ath_buf.bf_flags) which indicates the current buffer is a mgmt buffer and should go back onto the mgmt free list. * Extend 'txagg' to include debugging output for both normal and mgmt txbufs. * When checking/clearing ATH_BUF_BUSY, do it on both TX pools. Tested: * STA mode, with heavy UDP injection via iperf. This filled the TX queue however BARs were still going out successfully. TODO: * Initialise the mgmt buffers with ATH_BUF_MGMT and then ensure the right type is being allocated and freed on the appropriate list. That'd save a write operation (to bf->bf_flags) on each buffer alloc/free. * Test on AP mode, ensure that BAR TX and probe responses go out nicely when the main TX queue is filled (eg with paused traffic to a TID, awaiting a BAR to complete.) PR: kern/168170
2012-06-13 06:57:55 +00:00
TAILQ_INSERT_HEAD(&sc->sc_txbuf, bf, bf_list);
Implement a global (all non-mgmt traffic) TX ath_buf limitation when ath_start() is called. This (defaults to 10 frames) gives for a little headway in the TX ath_buf allocation, so buffer cloning is still possible. This requires a lot omre experimenting and tuning. It also doesn't stop a node/TID from consuming all of the available ath_buf's, especially when the node is going through high packet loss or only talking at a low TX rate. It also doesn't stop a paused TID from taking all of the ath_bufs. I'll look at fixing that up in subsequent commits. PR: kern/168170
2012-06-14 00:51:53 +00:00
sc->sc_txbuf_cnt++;
if (sc->sc_txbuf_cnt > ATH_TXBUF) {
device_printf(sc->sc_dev,
"%s: sc_txbuf_cnt > %d?\n",
__func__,
ATH_TXBUF);
sc->sc_txbuf_cnt = ATH_TXBUF;
}
}
Replace the direct sc_txbuf manipulation with a pair of functions. This is preparation work for having a separate ath_buf queue for management traffic. PR: kern/168170
2012-06-13 05:39:16 +00:00
}
Implement "holding buffers" per TX queue rather than globally. When working on TDMA, Sam Leffler found that the MAC DMA hardware would re-read the last TX descriptor when getting ready to transmit the next one. Thus the whole ATH_BUF_BUSY came into existance - the descriptor must be left alone (very specifically the link pointer must be maintained) until the hardware has moved onto the next frame. He saw this in TDMA because the MAC would be frequently stopping during active transmit (ie, when it wasn't its turn to transmit.) Fast-forward to today. It turns out that this is a problem not with a single MAC DMA instance, but with each QCU (from 0->9). They each maintain separate descriptor pointers and will re-read the last descriptor when starting to transmit the next. So when your AP is busy transmitting from multiple TX queues, you'll (more) frequently see one QCU stopped, waiting for a higher-priority QCU to finsh transmitting, before it'll go ahead and continue. If you mess up the descriptor (ie by freeing it) then you're short of luck. Thanks to rpaulo for sticking with me whilst I diagnosed this issue that he was quite reliably triggering in his environment. This is a reimplementation; it doesn't have anything in common with the ath9k or the Qualcomm Atheros reference driver. Now - it in theory doesn't apply on the EDMA chips, as long as you push one complete frame into the FIFO at a time. But the MAC can DMA from a list of frames pushed into the hardware queue (ie, you concat 'n' frames together with link pointers, and then push the head pointer into the TXQ FIFO.) Since that's likely how I'm going to implement CABQ handling in hostap mode, it's likely that I will end up teaching the EDMA TX completion code about busy buffers, just to be "sure" this doesn't creep up. Tested - iperf ap->sta and sta->ap (with both sides running this code): * AR5416 STA * AR9160/AR9220 hostap To validate that it doesn't break the EDMA (FIFO) chips: * AR9380, AR9485, AR9462 STA Using iperf with the -S <tos byte decimal value> to set the TCP client side DSCP bits, mapping to different TIDs and thus different TX queues. TODO: * Make this work on the EDMA chips, if we end up pushing lists of frames to the hardware (eg how we eventually will handle cabq in hostap/ibss mode.)
2013-03-14 06:20:02 +00:00
/*
* Free the holding buffer if it exists
*/
Add per-TXQ EDMA FIFO staging queue support. Each set of frames pushed into a FIFO is represented by a list of ath_bufs - the first ath_buf in the FIFO list is marked with ATH_BUF_FIFOPTR; the last ath_buf in the FIFO list is marked with ATH_BUF_FIFOEND. Multiple lists of frames are just glued together in the TAILQ as per normal - except that at the end of a FIFO list, the descriptor link pointer will be NULL and it'll be tagged with ATH_BUF_FIFOEND. For non-EDMA chipsets this is a no-op - the ath_txq frame list (axq_q) stays the same and is treated the same. For EDMA chipsets the frames are pushed into axq_q and then when the FIFO is to be (re) filled, frames will be moved onto the FIFO queue and then pushed into the FIFO. So: * Add a new queue in each hardware TXQ (ath_txq) for staging FIFO frame lists. It's a TAILQ (like the normal hardware frame queue) rather than the ath9k list-of-lists to represent FIFO entries. * Add new ath_buf flags - ATH_TX_FIFOPTR and ATH_TX_FIFOEND. * When allocating ath_buf entries, clear out the flag value before returning it or it'll end up having stale flags. * When cloning ath_buf entries, only clone ATH_BUF_MGMT. Don't clone the FIFO related flags. * Extend ath_tx_draintxq() to first drain the FIFO staging queue, _then_ drain the normal hardware queue. Tested: * AR9280, hostap * AR9280, STA * AR9380/AR9580 - hostap TODO: * Test on other chipsets, just to be thorough.
2013-03-26 19:46:51 +00:00
void
Implement "holding buffers" per TX queue rather than globally. When working on TDMA, Sam Leffler found that the MAC DMA hardware would re-read the last TX descriptor when getting ready to transmit the next one. Thus the whole ATH_BUF_BUSY came into existance - the descriptor must be left alone (very specifically the link pointer must be maintained) until the hardware has moved onto the next frame. He saw this in TDMA because the MAC would be frequently stopping during active transmit (ie, when it wasn't its turn to transmit.) Fast-forward to today. It turns out that this is a problem not with a single MAC DMA instance, but with each QCU (from 0->9). They each maintain separate descriptor pointers and will re-read the last descriptor when starting to transmit the next. So when your AP is busy transmitting from multiple TX queues, you'll (more) frequently see one QCU stopped, waiting for a higher-priority QCU to finsh transmitting, before it'll go ahead and continue. If you mess up the descriptor (ie by freeing it) then you're short of luck. Thanks to rpaulo for sticking with me whilst I diagnosed this issue that he was quite reliably triggering in his environment. This is a reimplementation; it doesn't have anything in common with the ath9k or the Qualcomm Atheros reference driver. Now - it in theory doesn't apply on the EDMA chips, as long as you push one complete frame into the FIFO at a time. But the MAC can DMA from a list of frames pushed into the hardware queue (ie, you concat 'n' frames together with link pointers, and then push the head pointer into the TXQ FIFO.) Since that's likely how I'm going to implement CABQ handling in hostap mode, it's likely that I will end up teaching the EDMA TX completion code about busy buffers, just to be "sure" this doesn't creep up. Tested - iperf ap->sta and sta->ap (with both sides running this code): * AR5416 STA * AR9160/AR9220 hostap To validate that it doesn't break the EDMA (FIFO) chips: * AR9380, AR9485, AR9462 STA Using iperf with the -S <tos byte decimal value> to set the TCP client side DSCP bits, mapping to different TIDs and thus different TX queues. TODO: * Make this work on the EDMA chips, if we end up pushing lists of frames to the hardware (eg how we eventually will handle cabq in hostap/ibss mode.)
2013-03-14 06:20:02 +00:00
ath_txq_freeholdingbuf(struct ath_softc *sc, struct ath_txq *txq)
{
Fix the holding descriptor logic to actually be "right" (for values of "right".) Flip back on the "always continue TX DMA using the holding descriptor" code - by always setting ATH_BUF_BUSY and never setting axq_link to NULL. Since the holding descriptor is accessed via txq->axq_link and _that_ is done behind the TXQ lock rather than the TX path lock, the holding descriptor stuff itself needs to be behind the TXQ lock. So, do the mental gymnastics needed to do this. I've not seen any of the hardware failures that I was seeing when I last tried to do this. Tested: * AR5416, STA mode
2013-05-08 21:23:51 +00:00
ATH_TXBUF_UNLOCK_ASSERT(sc);
ATH_TXQ_LOCK_ASSERT(txq);
Implement "holding buffers" per TX queue rather than globally. When working on TDMA, Sam Leffler found that the MAC DMA hardware would re-read the last TX descriptor when getting ready to transmit the next one. Thus the whole ATH_BUF_BUSY came into existance - the descriptor must be left alone (very specifically the link pointer must be maintained) until the hardware has moved onto the next frame. He saw this in TDMA because the MAC would be frequently stopping during active transmit (ie, when it wasn't its turn to transmit.) Fast-forward to today. It turns out that this is a problem not with a single MAC DMA instance, but with each QCU (from 0->9). They each maintain separate descriptor pointers and will re-read the last descriptor when starting to transmit the next. So when your AP is busy transmitting from multiple TX queues, you'll (more) frequently see one QCU stopped, waiting for a higher-priority QCU to finsh transmitting, before it'll go ahead and continue. If you mess up the descriptor (ie by freeing it) then you're short of luck. Thanks to rpaulo for sticking with me whilst I diagnosed this issue that he was quite reliably triggering in his environment. This is a reimplementation; it doesn't have anything in common with the ath9k or the Qualcomm Atheros reference driver. Now - it in theory doesn't apply on the EDMA chips, as long as you push one complete frame into the FIFO at a time. But the MAC can DMA from a list of frames pushed into the hardware queue (ie, you concat 'n' frames together with link pointers, and then push the head pointer into the TXQ FIFO.) Since that's likely how I'm going to implement CABQ handling in hostap mode, it's likely that I will end up teaching the EDMA TX completion code about busy buffers, just to be "sure" this doesn't creep up. Tested - iperf ap->sta and sta->ap (with both sides running this code): * AR5416 STA * AR9160/AR9220 hostap To validate that it doesn't break the EDMA (FIFO) chips: * AR9380, AR9485, AR9462 STA Using iperf with the -S <tos byte decimal value> to set the TCP client side DSCP bits, mapping to different TIDs and thus different TX queues. TODO: * Make this work on the EDMA chips, if we end up pushing lists of frames to the hardware (eg how we eventually will handle cabq in hostap/ibss mode.)
2013-03-14 06:20:02 +00:00
if (txq->axq_holdingbf == NULL)
return;
txq->axq_holdingbf->bf_flags &= ~ATH_BUF_BUSY;
Fix the holding descriptor logic to actually be "right" (for values of "right".) Flip back on the "always continue TX DMA using the holding descriptor" code - by always setting ATH_BUF_BUSY and never setting axq_link to NULL. Since the holding descriptor is accessed via txq->axq_link and _that_ is done behind the TXQ lock rather than the TX path lock, the holding descriptor stuff itself needs to be behind the TXQ lock. So, do the mental gymnastics needed to do this. I've not seen any of the hardware failures that I was seeing when I last tried to do this. Tested: * AR5416, STA mode
2013-05-08 21:23:51 +00:00
ATH_TXBUF_LOCK(sc);
Implement "holding buffers" per TX queue rather than globally. When working on TDMA, Sam Leffler found that the MAC DMA hardware would re-read the last TX descriptor when getting ready to transmit the next one. Thus the whole ATH_BUF_BUSY came into existance - the descriptor must be left alone (very specifically the link pointer must be maintained) until the hardware has moved onto the next frame. He saw this in TDMA because the MAC would be frequently stopping during active transmit (ie, when it wasn't its turn to transmit.) Fast-forward to today. It turns out that this is a problem not with a single MAC DMA instance, but with each QCU (from 0->9). They each maintain separate descriptor pointers and will re-read the last descriptor when starting to transmit the next. So when your AP is busy transmitting from multiple TX queues, you'll (more) frequently see one QCU stopped, waiting for a higher-priority QCU to finsh transmitting, before it'll go ahead and continue. If you mess up the descriptor (ie by freeing it) then you're short of luck. Thanks to rpaulo for sticking with me whilst I diagnosed this issue that he was quite reliably triggering in his environment. This is a reimplementation; it doesn't have anything in common with the ath9k or the Qualcomm Atheros reference driver. Now - it in theory doesn't apply on the EDMA chips, as long as you push one complete frame into the FIFO at a time. But the MAC can DMA from a list of frames pushed into the hardware queue (ie, you concat 'n' frames together with link pointers, and then push the head pointer into the TXQ FIFO.) Since that's likely how I'm going to implement CABQ handling in hostap mode, it's likely that I will end up teaching the EDMA TX completion code about busy buffers, just to be "sure" this doesn't creep up. Tested - iperf ap->sta and sta->ap (with both sides running this code): * AR5416 STA * AR9160/AR9220 hostap To validate that it doesn't break the EDMA (FIFO) chips: * AR9380, AR9485, AR9462 STA Using iperf with the -S <tos byte decimal value> to set the TCP client side DSCP bits, mapping to different TIDs and thus different TX queues. TODO: * Make this work on the EDMA chips, if we end up pushing lists of frames to the hardware (eg how we eventually will handle cabq in hostap/ibss mode.)
2013-03-14 06:20:02 +00:00
ath_returnbuf_tail(sc, txq->axq_holdingbf);
Fix the holding descriptor logic to actually be "right" (for values of "right".) Flip back on the "always continue TX DMA using the holding descriptor" code - by always setting ATH_BUF_BUSY and never setting axq_link to NULL. Since the holding descriptor is accessed via txq->axq_link and _that_ is done behind the TXQ lock rather than the TX path lock, the holding descriptor stuff itself needs to be behind the TXQ lock. So, do the mental gymnastics needed to do this. I've not seen any of the hardware failures that I was seeing when I last tried to do this. Tested: * AR5416, STA mode
2013-05-08 21:23:51 +00:00
ATH_TXBUF_UNLOCK(sc);
Implement "holding buffers" per TX queue rather than globally. When working on TDMA, Sam Leffler found that the MAC DMA hardware would re-read the last TX descriptor when getting ready to transmit the next one. Thus the whole ATH_BUF_BUSY came into existance - the descriptor must be left alone (very specifically the link pointer must be maintained) until the hardware has moved onto the next frame. He saw this in TDMA because the MAC would be frequently stopping during active transmit (ie, when it wasn't its turn to transmit.) Fast-forward to today. It turns out that this is a problem not with a single MAC DMA instance, but with each QCU (from 0->9). They each maintain separate descriptor pointers and will re-read the last descriptor when starting to transmit the next. So when your AP is busy transmitting from multiple TX queues, you'll (more) frequently see one QCU stopped, waiting for a higher-priority QCU to finsh transmitting, before it'll go ahead and continue. If you mess up the descriptor (ie by freeing it) then you're short of luck. Thanks to rpaulo for sticking with me whilst I diagnosed this issue that he was quite reliably triggering in his environment. This is a reimplementation; it doesn't have anything in common with the ath9k or the Qualcomm Atheros reference driver. Now - it in theory doesn't apply on the EDMA chips, as long as you push one complete frame into the FIFO at a time. But the MAC can DMA from a list of frames pushed into the hardware queue (ie, you concat 'n' frames together with link pointers, and then push the head pointer into the TXQ FIFO.) Since that's likely how I'm going to implement CABQ handling in hostap mode, it's likely that I will end up teaching the EDMA TX completion code about busy buffers, just to be "sure" this doesn't creep up. Tested - iperf ap->sta and sta->ap (with both sides running this code): * AR5416 STA * AR9160/AR9220 hostap To validate that it doesn't break the EDMA (FIFO) chips: * AR9380, AR9485, AR9462 STA Using iperf with the -S <tos byte decimal value> to set the TCP client side DSCP bits, mapping to different TIDs and thus different TX queues. TODO: * Make this work on the EDMA chips, if we end up pushing lists of frames to the hardware (eg how we eventually will handle cabq in hostap/ibss mode.)
2013-03-14 06:20:02 +00:00
txq->axq_holdingbf = NULL;
}
/*
* Add this buffer to the holding queue, freeing the previous
* one if it exists.
*/
static void
ath_txq_addholdingbuf(struct ath_softc *sc, struct ath_buf *bf)
{
struct ath_txq *txq;
Fix the holding descriptor logic to actually be "right" (for values of "right".) Flip back on the "always continue TX DMA using the holding descriptor" code - by always setting ATH_BUF_BUSY and never setting axq_link to NULL. Since the holding descriptor is accessed via txq->axq_link and _that_ is done behind the TXQ lock rather than the TX path lock, the holding descriptor stuff itself needs to be behind the TXQ lock. So, do the mental gymnastics needed to do this. I've not seen any of the hardware failures that I was seeing when I last tried to do this. Tested: * AR5416, STA mode
2013-05-08 21:23:51 +00:00
txq = &sc->sc_txq[bf->bf_state.bfs_tx_queue];
ATH_TXBUF_UNLOCK_ASSERT(sc);
ATH_TXQ_LOCK_ASSERT(txq);
Add locking around the new holdingbf code. Since this is being done during buffer free, it's a crap shoot whether the TX path lock is held or not. I tried putting the ath_freebuf() code inside the TX lock and I got all kinds of locking issues - it turns out that the buffer free path sometimes is called with the lock held and sometimes isn't. So I'll go and fix that soon. Hence for now the holdingbf buffers are protected by the TXBUF lock.
2013-03-15 02:52:37 +00:00
Implement "holding buffers" per TX queue rather than globally. When working on TDMA, Sam Leffler found that the MAC DMA hardware would re-read the last TX descriptor when getting ready to transmit the next one. Thus the whole ATH_BUF_BUSY came into existance - the descriptor must be left alone (very specifically the link pointer must be maintained) until the hardware has moved onto the next frame. He saw this in TDMA because the MAC would be frequently stopping during active transmit (ie, when it wasn't its turn to transmit.) Fast-forward to today. It turns out that this is a problem not with a single MAC DMA instance, but with each QCU (from 0->9). They each maintain separate descriptor pointers and will re-read the last descriptor when starting to transmit the next. So when your AP is busy transmitting from multiple TX queues, you'll (more) frequently see one QCU stopped, waiting for a higher-priority QCU to finsh transmitting, before it'll go ahead and continue. If you mess up the descriptor (ie by freeing it) then you're short of luck. Thanks to rpaulo for sticking with me whilst I diagnosed this issue that he was quite reliably triggering in his environment. This is a reimplementation; it doesn't have anything in common with the ath9k or the Qualcomm Atheros reference driver. Now - it in theory doesn't apply on the EDMA chips, as long as you push one complete frame into the FIFO at a time. But the MAC can DMA from a list of frames pushed into the hardware queue (ie, you concat 'n' frames together with link pointers, and then push the head pointer into the TXQ FIFO.) Since that's likely how I'm going to implement CABQ handling in hostap mode, it's likely that I will end up teaching the EDMA TX completion code about busy buffers, just to be "sure" this doesn't creep up. Tested - iperf ap->sta and sta->ap (with both sides running this code): * AR5416 STA * AR9160/AR9220 hostap To validate that it doesn't break the EDMA (FIFO) chips: * AR9380, AR9485, AR9462 STA Using iperf with the -S <tos byte decimal value> to set the TCP client side DSCP bits, mapping to different TIDs and thus different TX queues. TODO: * Make this work on the EDMA chips, if we end up pushing lists of frames to the hardware (eg how we eventually will handle cabq in hostap/ibss mode.)
2013-03-14 06:20:02 +00:00
/* XXX assert ATH_BUF_BUSY is set */
/* XXX assert the tx queue is under the max number */
if (bf->bf_state.bfs_tx_queue > HAL_NUM_TX_QUEUES) {
device_printf(sc->sc_dev, "%s: bf=%p: invalid tx queue (%d)\n",
__func__,
bf,
bf->bf_state.bfs_tx_queue);
bf->bf_flags &= ~ATH_BUF_BUSY;
ath_returnbuf_tail(sc, bf);
return;
}
ath_txq_freeholdingbuf(sc, txq);
txq->axq_holdingbf = bf;
}
Refactor out the TX buffer management and completion code in preparation for TX aggregation. * Add in logic which calls ath_buf bf->bf_comp if it's set. This allows for AMPDU (and RIFS, and FF, if someone desires) code to handle completion - which includes freeing subframes, retransmitting subframes, etc. * Break out the buffer free, buffer busy/unbusy default completion handler code into separate functions. This allows bf_comp methods to free and unbusy each subframe ath_buf as required. * Break out the statistics update code into a separate function, just to clean up the TX completion path a little. Sponsored by: Hobnob, Inc.
2011-11-08 21:49:33 +00:00
/*
* Return a buffer to the pool and update the 'busy' flag on the
* previous 'tail' entry.
*
* This _must_ only be called when the buffer is involved in a completed
* TX. The logic is that if it was part of an active TX, the previous
* buffer on the list is now not involved in a halted TX DMA queue, waiting
* for restart (eg for TDMA.)
*
* The caller must free the mbuf and recycle the node reference.
Fix the holding descriptor logic to actually be "right" (for values of "right".) Flip back on the "always continue TX DMA using the holding descriptor" code - by always setting ATH_BUF_BUSY and never setting axq_link to NULL. Since the holding descriptor is accessed via txq->axq_link and _that_ is done behind the TXQ lock rather than the TX path lock, the holding descriptor stuff itself needs to be behind the TXQ lock. So, do the mental gymnastics needed to do this. I've not seen any of the hardware failures that I was seeing when I last tried to do this. Tested: * AR5416, STA mode
2013-05-08 21:23:51 +00:00
*
* XXX This method of handling busy / holding buffers is insanely stupid.
* It requires bf_state.bfs_tx_queue to be correctly assigned. It would
* be much nicer if buffers in the processq() methods would instead be
* always completed there (pushed onto a txq or ath_bufhead) so we knew
* exactly what hardware queue they came from in the first place.
Refactor out the TX buffer management and completion code in preparation for TX aggregation. * Add in logic which calls ath_buf bf->bf_comp if it's set. This allows for AMPDU (and RIFS, and FF, if someone desires) code to handle completion - which includes freeing subframes, retransmitting subframes, etc. * Break out the buffer free, buffer busy/unbusy default completion handler code into separate functions. This allows bf_comp methods to free and unbusy each subframe ath_buf as required. * Break out the statistics update code into a separate function, just to clean up the TX completion path a little. Sponsored by: Hobnob, Inc.
2011-11-08 21:49:33 +00:00
*/
void
ath_freebuf(struct ath_softc *sc, struct ath_buf *bf)
{
Fix the holding descriptor logic to actually be "right" (for values of "right".) Flip back on the "always continue TX DMA using the holding descriptor" code - by always setting ATH_BUF_BUSY and never setting axq_link to NULL. Since the holding descriptor is accessed via txq->axq_link and _that_ is done behind the TXQ lock rather than the TX path lock, the holding descriptor stuff itself needs to be behind the TXQ lock. So, do the mental gymnastics needed to do this. I've not seen any of the hardware failures that I was seeing when I last tried to do this. Tested: * AR5416, STA mode
2013-05-08 21:23:51 +00:00
struct ath_txq *txq;
txq = &sc->sc_txq[bf->bf_state.bfs_tx_queue];
Refactor out the TX buffer management and completion code in preparation for TX aggregation. * Add in logic which calls ath_buf bf->bf_comp if it's set. This allows for AMPDU (and RIFS, and FF, if someone desires) code to handle completion - which includes freeing subframes, retransmitting subframes, etc. * Break out the buffer free, buffer busy/unbusy default completion handler code into separate functions. This allows bf_comp methods to free and unbusy each subframe ath_buf as required. * Break out the statistics update code into a separate function, just to clean up the TX completion path a little. Sponsored by: Hobnob, Inc.
2011-11-08 21:49:33 +00:00
KASSERT((bf->bf_node == NULL), ("%s: bf->bf_node != NULL\n", __func__));
KASSERT((bf->bf_m == NULL), ("%s: bf->bf_m != NULL\n", __func__));
Implement "holding buffers" per TX queue rather than globally. When working on TDMA, Sam Leffler found that the MAC DMA hardware would re-read the last TX descriptor when getting ready to transmit the next one. Thus the whole ATH_BUF_BUSY came into existance - the descriptor must be left alone (very specifically the link pointer must be maintained) until the hardware has moved onto the next frame. He saw this in TDMA because the MAC would be frequently stopping during active transmit (ie, when it wasn't its turn to transmit.) Fast-forward to today. It turns out that this is a problem not with a single MAC DMA instance, but with each QCU (from 0->9). They each maintain separate descriptor pointers and will re-read the last descriptor when starting to transmit the next. So when your AP is busy transmitting from multiple TX queues, you'll (more) frequently see one QCU stopped, waiting for a higher-priority QCU to finsh transmitting, before it'll go ahead and continue. If you mess up the descriptor (ie by freeing it) then you're short of luck. Thanks to rpaulo for sticking with me whilst I diagnosed this issue that he was quite reliably triggering in his environment. This is a reimplementation; it doesn't have anything in common with the ath9k or the Qualcomm Atheros reference driver. Now - it in theory doesn't apply on the EDMA chips, as long as you push one complete frame into the FIFO at a time. But the MAC can DMA from a list of frames pushed into the hardware queue (ie, you concat 'n' frames together with link pointers, and then push the head pointer into the TXQ FIFO.) Since that's likely how I'm going to implement CABQ handling in hostap mode, it's likely that I will end up teaching the EDMA TX completion code about busy buffers, just to be "sure" this doesn't creep up. Tested - iperf ap->sta and sta->ap (with both sides running this code): * AR5416 STA * AR9160/AR9220 hostap To validate that it doesn't break the EDMA (FIFO) chips: * AR9380, AR9485, AR9462 STA Using iperf with the -S <tos byte decimal value> to set the TCP client side DSCP bits, mapping to different TIDs and thus different TX queues. TODO: * Make this work on the EDMA chips, if we end up pushing lists of frames to the hardware (eg how we eventually will handle cabq in hostap/ibss mode.)
2013-03-14 06:20:02 +00:00
/*
Fix the holding descriptor logic to actually be "right" (for values of "right".) Flip back on the "always continue TX DMA using the holding descriptor" code - by always setting ATH_BUF_BUSY and never setting axq_link to NULL. Since the holding descriptor is accessed via txq->axq_link and _that_ is done behind the TXQ lock rather than the TX path lock, the holding descriptor stuff itself needs to be behind the TXQ lock. So, do the mental gymnastics needed to do this. I've not seen any of the hardware failures that I was seeing when I last tried to do this. Tested: * AR5416, STA mode
2013-05-08 21:23:51 +00:00
* If this buffer is busy, push it onto the holding queue.
Implement "holding buffers" per TX queue rather than globally. When working on TDMA, Sam Leffler found that the MAC DMA hardware would re-read the last TX descriptor when getting ready to transmit the next one. Thus the whole ATH_BUF_BUSY came into existance - the descriptor must be left alone (very specifically the link pointer must be maintained) until the hardware has moved onto the next frame. He saw this in TDMA because the MAC would be frequently stopping during active transmit (ie, when it wasn't its turn to transmit.) Fast-forward to today. It turns out that this is a problem not with a single MAC DMA instance, but with each QCU (from 0->9). They each maintain separate descriptor pointers and will re-read the last descriptor when starting to transmit the next. So when your AP is busy transmitting from multiple TX queues, you'll (more) frequently see one QCU stopped, waiting for a higher-priority QCU to finsh transmitting, before it'll go ahead and continue. If you mess up the descriptor (ie by freeing it) then you're short of luck. Thanks to rpaulo for sticking with me whilst I diagnosed this issue that he was quite reliably triggering in his environment. This is a reimplementation; it doesn't have anything in common with the ath9k or the Qualcomm Atheros reference driver. Now - it in theory doesn't apply on the EDMA chips, as long as you push one complete frame into the FIFO at a time. But the MAC can DMA from a list of frames pushed into the hardware queue (ie, you concat 'n' frames together with link pointers, and then push the head pointer into the TXQ FIFO.) Since that's likely how I'm going to implement CABQ handling in hostap mode, it's likely that I will end up teaching the EDMA TX completion code about busy buffers, just to be "sure" this doesn't creep up. Tested - iperf ap->sta and sta->ap (with both sides running this code): * AR5416 STA * AR9160/AR9220 hostap To validate that it doesn't break the EDMA (FIFO) chips: * AR9380, AR9485, AR9462 STA Using iperf with the -S <tos byte decimal value> to set the TCP client side DSCP bits, mapping to different TIDs and thus different TX queues. TODO: * Make this work on the EDMA chips, if we end up pushing lists of frames to the hardware (eg how we eventually will handle cabq in hostap/ibss mode.)
2013-03-14 06:20:02 +00:00
*/
if (bf->bf_flags & ATH_BUF_BUSY) {
Fix the holding descriptor logic to actually be "right" (for values of "right".) Flip back on the "always continue TX DMA using the holding descriptor" code - by always setting ATH_BUF_BUSY and never setting axq_link to NULL. Since the holding descriptor is accessed via txq->axq_link and _that_ is done behind the TXQ lock rather than the TX path lock, the holding descriptor stuff itself needs to be behind the TXQ lock. So, do the mental gymnastics needed to do this. I've not seen any of the hardware failures that I was seeing when I last tried to do this. Tested: * AR5416, STA mode
2013-05-08 21:23:51 +00:00
ATH_TXQ_LOCK(txq);
Implement "holding buffers" per TX queue rather than globally. When working on TDMA, Sam Leffler found that the MAC DMA hardware would re-read the last TX descriptor when getting ready to transmit the next one. Thus the whole ATH_BUF_BUSY came into existance - the descriptor must be left alone (very specifically the link pointer must be maintained) until the hardware has moved onto the next frame. He saw this in TDMA because the MAC would be frequently stopping during active transmit (ie, when it wasn't its turn to transmit.) Fast-forward to today. It turns out that this is a problem not with a single MAC DMA instance, but with each QCU (from 0->9). They each maintain separate descriptor pointers and will re-read the last descriptor when starting to transmit the next. So when your AP is busy transmitting from multiple TX queues, you'll (more) frequently see one QCU stopped, waiting for a higher-priority QCU to finsh transmitting, before it'll go ahead and continue. If you mess up the descriptor (ie by freeing it) then you're short of luck. Thanks to rpaulo for sticking with me whilst I diagnosed this issue that he was quite reliably triggering in his environment. This is a reimplementation; it doesn't have anything in common with the ath9k or the Qualcomm Atheros reference driver. Now - it in theory doesn't apply on the EDMA chips, as long as you push one complete frame into the FIFO at a time. But the MAC can DMA from a list of frames pushed into the hardware queue (ie, you concat 'n' frames together with link pointers, and then push the head pointer into the TXQ FIFO.) Since that's likely how I'm going to implement CABQ handling in hostap mode, it's likely that I will end up teaching the EDMA TX completion code about busy buffers, just to be "sure" this doesn't creep up. Tested - iperf ap->sta and sta->ap (with both sides running this code): * AR5416 STA * AR9160/AR9220 hostap To validate that it doesn't break the EDMA (FIFO) chips: * AR9380, AR9485, AR9462 STA Using iperf with the -S <tos byte decimal value> to set the TCP client side DSCP bits, mapping to different TIDs and thus different TX queues. TODO: * Make this work on the EDMA chips, if we end up pushing lists of frames to the hardware (eg how we eventually will handle cabq in hostap/ibss mode.)
2013-03-14 06:20:02 +00:00
ath_txq_addholdingbuf(sc, bf);
Fix the holding descriptor logic to actually be "right" (for values of "right".) Flip back on the "always continue TX DMA using the holding descriptor" code - by always setting ATH_BUF_BUSY and never setting axq_link to NULL. Since the holding descriptor is accessed via txq->axq_link and _that_ is done behind the TXQ lock rather than the TX path lock, the holding descriptor stuff itself needs to be behind the TXQ lock. So, do the mental gymnastics needed to do this. I've not seen any of the hardware failures that I was seeing when I last tried to do this. Tested: * AR5416, STA mode
2013-05-08 21:23:51 +00:00
ATH_TXQ_UNLOCK(txq);
Implement "holding buffers" per TX queue rather than globally. When working on TDMA, Sam Leffler found that the MAC DMA hardware would re-read the last TX descriptor when getting ready to transmit the next one. Thus the whole ATH_BUF_BUSY came into existance - the descriptor must be left alone (very specifically the link pointer must be maintained) until the hardware has moved onto the next frame. He saw this in TDMA because the MAC would be frequently stopping during active transmit (ie, when it wasn't its turn to transmit.) Fast-forward to today. It turns out that this is a problem not with a single MAC DMA instance, but with each QCU (from 0->9). They each maintain separate descriptor pointers and will re-read the last descriptor when starting to transmit the next. So when your AP is busy transmitting from multiple TX queues, you'll (more) frequently see one QCU stopped, waiting for a higher-priority QCU to finsh transmitting, before it'll go ahead and continue. If you mess up the descriptor (ie by freeing it) then you're short of luck. Thanks to rpaulo for sticking with me whilst I diagnosed this issue that he was quite reliably triggering in his environment. This is a reimplementation; it doesn't have anything in common with the ath9k or the Qualcomm Atheros reference driver. Now - it in theory doesn't apply on the EDMA chips, as long as you push one complete frame into the FIFO at a time. But the MAC can DMA from a list of frames pushed into the hardware queue (ie, you concat 'n' frames together with link pointers, and then push the head pointer into the TXQ FIFO.) Since that's likely how I'm going to implement CABQ handling in hostap mode, it's likely that I will end up teaching the EDMA TX completion code about busy buffers, just to be "sure" this doesn't creep up. Tested - iperf ap->sta and sta->ap (with both sides running this code): * AR5416 STA * AR9160/AR9220 hostap To validate that it doesn't break the EDMA (FIFO) chips: * AR9380, AR9485, AR9462 STA Using iperf with the -S <tos byte decimal value> to set the TCP client side DSCP bits, mapping to different TIDs and thus different TX queues. TODO: * Make this work on the EDMA chips, if we end up pushing lists of frames to the hardware (eg how we eventually will handle cabq in hostap/ibss mode.)
2013-03-14 06:20:02 +00:00
return;
}
/*
* Not a busy buffer, so free normally
*/
Refactor out the TX buffer management and completion code in preparation for TX aggregation. * Add in logic which calls ath_buf bf->bf_comp if it's set. This allows for AMPDU (and RIFS, and FF, if someone desires) code to handle completion - which includes freeing subframes, retransmitting subframes, etc. * Break out the buffer free, buffer busy/unbusy default completion handler code into separate functions. This allows bf_comp methods to free and unbusy each subframe ath_buf as required. * Break out the statistics update code into a separate function, just to clean up the TX completion path a little. Sponsored by: Hobnob, Inc.
2011-11-08 21:49:33 +00:00
ATH_TXBUF_LOCK(sc);
Replace the direct sc_txbuf manipulation with a pair of functions. This is preparation work for having a separate ath_buf queue for management traffic. PR: kern/168170
2012-06-13 05:39:16 +00:00
ath_returnbuf_tail(sc, bf);
Refactor out the TX buffer management and completion code in preparation for TX aggregation. * Add in logic which calls ath_buf bf->bf_comp if it's set. This allows for AMPDU (and RIFS, and FF, if someone desires) code to handle completion - which includes freeing subframes, retransmitting subframes, etc. * Break out the buffer free, buffer busy/unbusy default completion handler code into separate functions. This allows bf_comp methods to free and unbusy each subframe ath_buf as required. * Break out the statistics update code into a separate function, just to clean up the TX completion path a little. Sponsored by: Hobnob, Inc.
2011-11-08 21:49:33 +00:00
ATH_TXBUF_UNLOCK(sc);
}
/*
* This is currently used by ath_tx_draintxq() and
* ath_tx_tid_free_pkts().
*
* It recycles a single ath_buf.
*/
void
ath_tx_freebuf(struct ath_softc *sc, struct ath_buf *bf, int status)
{
struct ieee80211_node *ni = bf->bf_node;
struct mbuf *m0 = bf->bf_m;
Ensure that we only call the busdma unmap/flush routines once, when the buffer is being freed. * When buffers are cloned, the original mapping isn't copied but it wasn't freeing the mapping until later. To be safe, free the mapping when the buffer is cloned. * ath_freebuf() now no longer calls the busdma sync/unmap routines. * ath_tx_freebuf() now calls sync/unmap. * Call sync first, before calling unmap. Tested: * AR5416, STA mode
2013-04-01 20:57:13 +00:00
/*
* Make sure that we only sync/unload if there's an mbuf.
* If not (eg we cloned a buffer), the unload will have already
dev/ath: minor spelling fixes in comments. No functional change. Reviewed by: adrian
2016-05-02 19:56:48 +00:00
* occurred.
Ensure that we only call the busdma unmap/flush routines once, when the buffer is being freed. * When buffers are cloned, the original mapping isn't copied but it wasn't freeing the mapping until later. To be safe, free the mapping when the buffer is cloned. * ath_freebuf() now no longer calls the busdma sync/unmap routines. * ath_tx_freebuf() now calls sync/unmap. * Call sync first, before calling unmap. Tested: * AR5416, STA mode
2013-04-01 20:57:13 +00:00
*/
if (bf->bf_m != NULL) {
bus_dmamap_sync(sc->sc_dmat, bf->bf_dmamap,
BUS_DMASYNC_POSTWRITE);
bus_dmamap_unload(sc->sc_dmat, bf->bf_dmamap);
}
Refactor out the TX buffer management and completion code in preparation for TX aggregation. * Add in logic which calls ath_buf bf->bf_comp if it's set. This allows for AMPDU (and RIFS, and FF, if someone desires) code to handle completion - which includes freeing subframes, retransmitting subframes, etc. * Break out the buffer free, buffer busy/unbusy default completion handler code into separate functions. This allows bf_comp methods to free and unbusy each subframe ath_buf as required. * Break out the statistics update code into a separate function, just to clean up the TX completion path a little. Sponsored by: Hobnob, Inc.
2011-11-08 21:49:33 +00:00
bf->bf_node = NULL;
bf->bf_m = NULL;
/* Free the buffer, it's not needed any longer */
ath_freebuf(sc, bf);
Use the new ieee80211_tx_complete() function.
2013-08-27 14:39:37 +00:00
/* Pass the buffer back to net80211 - completing it */
ieee80211_tx_complete(ni, m0, status);
Refactor out the TX buffer management and completion code in preparation for TX aggregation. * Add in logic which calls ath_buf bf->bf_comp if it's set. This allows for AMPDU (and RIFS, and FF, if someone desires) code to handle completion - which includes freeing subframes, retransmitting subframes, etc. * Break out the buffer free, buffer busy/unbusy default completion handler code into separate functions. This allows bf_comp methods to free and unbusy each subframe ath_buf as required. * Break out the statistics update code into a separate function, just to clean up the TX completion path a little. Sponsored by: Hobnob, Inc.
2011-11-08 21:49:33 +00:00
}
Add per-TXQ EDMA FIFO staging queue support. Each set of frames pushed into a FIFO is represented by a list of ath_bufs - the first ath_buf in the FIFO list is marked with ATH_BUF_FIFOPTR; the last ath_buf in the FIFO list is marked with ATH_BUF_FIFOEND. Multiple lists of frames are just glued together in the TAILQ as per normal - except that at the end of a FIFO list, the descriptor link pointer will be NULL and it'll be tagged with ATH_BUF_FIFOEND. For non-EDMA chipsets this is a no-op - the ath_txq frame list (axq_q) stays the same and is treated the same. For EDMA chipsets the frames are pushed into axq_q and then when the FIFO is to be (re) filled, frames will be moved onto the FIFO queue and then pushed into the FIFO. So: * Add a new queue in each hardware TXQ (ath_txq) for staging FIFO frame lists. It's a TAILQ (like the normal hardware frame queue) rather than the ath9k list-of-lists to represent FIFO entries. * Add new ath_buf flags - ATH_TX_FIFOPTR and ATH_TX_FIFOEND. * When allocating ath_buf entries, clear out the flag value before returning it or it'll end up having stale flags. * When cloning ath_buf entries, only clone ATH_BUF_MGMT. Don't clone the FIFO related flags. * Extend ath_tx_draintxq() to first drain the FIFO staging queue, _then_ drain the normal hardware queue. Tested: * AR9280, hostap * AR9280, STA * AR9380/AR9580 - hostap TODO: * Test on other chipsets, just to be thorough.
2013-03-26 19:46:51 +00:00
static struct ath_buf *
ath_tx_draintxq_get_one(struct ath_softc *sc, struct ath_txq *txq)
{
struct ath_buf *bf;
ATH_TXQ_LOCK_ASSERT(txq);
/*
* Drain the FIFO queue first, then if it's
* empty, move to the normal frame queue.
*/
bf = TAILQ_FIRST(&txq->fifo.axq_q);
if (bf != NULL) {
/*
* Is it the last buffer in this set?
* Decrement the FIFO counter.
*/
if (bf->bf_flags & ATH_BUF_FIFOEND) {
if (txq->axq_fifo_depth == 0) {
device_printf(sc->sc_dev,
"%s: Q%d: fifo_depth=0, fifo.axq_depth=%d?\n",
__func__,
txq->axq_qnum,
txq->fifo.axq_depth);
} else
txq->axq_fifo_depth--;
}
ATH_TXQ_REMOVE(&txq->fifo, bf, bf_list);
return (bf);
}
/*
* Debugging!
*/
if (txq->axq_fifo_depth != 0 || txq->fifo.axq_depth != 0) {
device_printf(sc->sc_dev,
"%s: Q%d: fifo_depth=%d, fifo.axq_depth=%d\n",
__func__,
txq->axq_qnum,
txq->axq_fifo_depth,
txq->fifo.axq_depth);
}
/*
* Now drain the pending queue.
*/
bf = TAILQ_FIRST(&txq->axq_q);
if (bf == NULL) {
txq->axq_link = NULL;
return (NULL);
}
ATH_TXQ_REMOVE(txq, bf, bf_list);
return (bf);
}
Refactor out the TX buffer management and completion code in preparation for TX aggregation. * Add in logic which calls ath_buf bf->bf_comp if it's set. This allows for AMPDU (and RIFS, and FF, if someone desires) code to handle completion - which includes freeing subframes, retransmitting subframes, etc. * Break out the buffer free, buffer busy/unbusy default completion handler code into separate functions. This allows bf_comp methods to free and unbusy each subframe ath_buf as required. * Break out the statistics update code into a separate function, just to clean up the TX completion path a little. Sponsored by: Hobnob, Inc.
2011-11-08 21:49:33 +00:00
void
Revert the ath_tx_draintxq() method, and instead teach it the minimum necessary to "do" EDMA. It was just using the TX completion status for logging information about the descriptor completion. Since with EDMA we don't know this without checking the TX completion FIFO, we can't provide this information. So don't.
2012-08-12 00:46:15 +00:00
ath_tx_draintxq(struct ath_softc *sc, struct ath_txq *txq)
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
{
o add opt_ath.h enable tweaking various config parameters for the driver without modifying the source code o default debug msgs and diag support to off MFC after: 3 days
2006-04-03 18:14:02 +00:00
#ifdef ATH_DEBUG
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
struct ath_hal *ah = sc->sc_ah;
fix build w/o AR_DEBUG MFC after: 2 weeks
2006-02-15 18:35:09 +00:00
#endif
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
struct ath_buf *bf;
improve tx/rx buf printing routines MFC after: 2 weeks
2006-02-15 18:31:04 +00:00
u_int ix;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
Update with last year of work.
2004-12-08 17:34:36 +00:00
/*
* NB: this assumes output has been stopped and
fix comment
2008-10-27 17:53:34 +00:00
* we do not need to block ath_tx_proc
Update with last year of work.
2004-12-08 17:34:36 +00:00
*/
improve tx/rx buf printing routines MFC after: 2 weeks
2006-02-15 18:31:04 +00:00
for (ix = 0;; ix++) {
Overhaul the TXQ locking (again!) as part of some beacon/cabq timing related issues. Moving the TX locking under one lock made things easier to progress on but it had one important side-effect - it increased the latency when handling CABQ setup when sending beacons. This commit introduces a bunch of new changes and a few unrelated changs that are just easier to lump in here. The aim is to have the CABQ locking separate from other locking. The CABQ transmit path in the beacon process thus doesn't have to grab the general TX lock, reducing lock contention/latency and making it more likely that we'll make the beacon TX timing. The second half of this commit is the CABQ related setup changes needed for sane looking EDMA CABQ support. Right now the EDMA TX code naively assumes that only one frame (MPDU or A-MPDU) is being pushed into each FIFO slot. For the CABQ this isn't true - a whole list of frames is being pushed in - and thus CABQ handling breaks very quickly. The aim here is to setup the CABQ list and then push _that list_ to the hardware for transmission. I can then extend the EDMA TX code to stamp that list as being "one" FIFO entry (likely by tagging the last buffer in that list as "FIFO END") so the EDMA TX completion code correctly tracks things. Major: * Migrate the per-TXQ add/removal locking back to per-TXQ, rather than a single lock. * Leave the software queue side of things under the ATH_TX_LOCK lock, (continuing) to serialise things as they are. * Add a new function which is called whenever there's a beacon miss, to print out some debugging. This is primarily designed to help me figure out if the beacon miss events are due to a noisy environment, issues with the PHY/MAC, or other. * Move the CABQ setup/enable to occur _after_ all the VAPs have been looked at. This means that for multiple VAPS in bursted mode, the CABQ gets primed once all VAPs are checked, rather than being primed on the first VAP and then having frames appended after this. Minor: * Add a (disabled) twiddle to let me enable/disable cabq traffic. It's primarily there to let me easily debug what's going on with beacon and CABQ setup/traffic; there's some DMA engine hangs which I'm finally trying to trace down. * Clear bf_next when flushing frames; it should quieten some warnings that show up when a node goes away. Tested: * AR9280, STA/hostap, up to 4 vaps (staggered) * AR5416, STA/hostap, up to 4 vaps (staggered) TODO: * (Lots) more AR9380 and later testing, as I may have missed something here. * Leverage this to fix CABQ hanling for AR9380 and later chips. * Force bursted beaconing on the chips that default to staggered beacons and ensure the CABQ stuff is all sane (eg, the MORE bits that aren't being correctly set when chaining descriptors.)
2013-03-24 00:03:12 +00:00
ATH_TXQ_LOCK(txq);
Add per-TXQ EDMA FIFO staging queue support. Each set of frames pushed into a FIFO is represented by a list of ath_bufs - the first ath_buf in the FIFO list is marked with ATH_BUF_FIFOPTR; the last ath_buf in the FIFO list is marked with ATH_BUF_FIFOEND. Multiple lists of frames are just glued together in the TAILQ as per normal - except that at the end of a FIFO list, the descriptor link pointer will be NULL and it'll be tagged with ATH_BUF_FIFOEND. For non-EDMA chipsets this is a no-op - the ath_txq frame list (axq_q) stays the same and is treated the same. For EDMA chipsets the frames are pushed into axq_q and then when the FIFO is to be (re) filled, frames will be moved onto the FIFO queue and then pushed into the FIFO. So: * Add a new queue in each hardware TXQ (ath_txq) for staging FIFO frame lists. It's a TAILQ (like the normal hardware frame queue) rather than the ath9k list-of-lists to represent FIFO entries. * Add new ath_buf flags - ATH_TX_FIFOPTR and ATH_TX_FIFOEND. * When allocating ath_buf entries, clear out the flag value before returning it or it'll end up having stale flags. * When cloning ath_buf entries, only clone ATH_BUF_MGMT. Don't clone the FIFO related flags. * Extend ath_tx_draintxq() to first drain the FIFO staging queue, _then_ drain the normal hardware queue. Tested: * AR9280, hostap * AR9280, STA * AR9380/AR9580 - hostap TODO: * Test on other chipsets, just to be thorough.
2013-03-26 19:46:51 +00:00
bf = ath_tx_draintxq_get_one(sc, txq);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
if (bf == NULL) {
Overhaul the TXQ locking (again!) as part of some beacon/cabq timing related issues. Moving the TX locking under one lock made things easier to progress on but it had one important side-effect - it increased the latency when handling CABQ setup when sending beacons. This commit introduces a bunch of new changes and a few unrelated changs that are just easier to lump in here. The aim is to have the CABQ locking separate from other locking. The CABQ transmit path in the beacon process thus doesn't have to grab the general TX lock, reducing lock contention/latency and making it more likely that we'll make the beacon TX timing. The second half of this commit is the CABQ related setup changes needed for sane looking EDMA CABQ support. Right now the EDMA TX code naively assumes that only one frame (MPDU or A-MPDU) is being pushed into each FIFO slot. For the CABQ this isn't true - a whole list of frames is being pushed in - and thus CABQ handling breaks very quickly. The aim here is to setup the CABQ list and then push _that list_ to the hardware for transmission. I can then extend the EDMA TX code to stamp that list as being "one" FIFO entry (likely by tagging the last buffer in that list as "FIFO END") so the EDMA TX completion code correctly tracks things. Major: * Migrate the per-TXQ add/removal locking back to per-TXQ, rather than a single lock. * Leave the software queue side of things under the ATH_TX_LOCK lock, (continuing) to serialise things as they are. * Add a new function which is called whenever there's a beacon miss, to print out some debugging. This is primarily designed to help me figure out if the beacon miss events are due to a noisy environment, issues with the PHY/MAC, or other. * Move the CABQ setup/enable to occur _after_ all the VAPs have been looked at. This means that for multiple VAPS in bursted mode, the CABQ gets primed once all VAPs are checked, rather than being primed on the first VAP and then having frames appended after this. Minor: * Add a (disabled) twiddle to let me enable/disable cabq traffic. It's primarily there to let me easily debug what's going on with beacon and CABQ setup/traffic; there's some DMA engine hangs which I'm finally trying to trace down. * Clear bf_next when flushing frames; it should quieten some warnings that show up when a node goes away. Tested: * AR9280, STA/hostap, up to 4 vaps (staggered) * AR5416, STA/hostap, up to 4 vaps (staggered) TODO: * (Lots) more AR9380 and later testing, as I may have missed something here. * Leverage this to fix CABQ hanling for AR9380 and later chips. * Force bursted beaconing on the chips that default to staggered beacons and ensure the CABQ stuff is all sane (eg, the MORE bits that aren't being correctly set when chaining descriptors.)
2013-03-24 00:03:12 +00:00
ATH_TXQ_UNLOCK(txq);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
break;
}
Change the descriptor logic to use bf_lastds to point to the last descriptor, rather than using the maths involving bf_desc[bf_nseg - 1]. When doing TX aggregation, the status will be updated in the -final- descriptor of the -final- subframe in an aggregate. Thus bf_lastds may point to the last descriptor in a completely different ath_buf. Sponsored by: Hobnob, Inc.
2011-11-08 21:25:36 +00:00
if (bf->bf_state.bfs_aggr)
txq->axq_aggr_depth--;
o add opt_ath.h enable tweaking various config parameters for the driver without modifying the source code o default debug msgs and diag support to off MFC after: 3 days
2006-04-03 18:14:02 +00:00
#ifdef ATH_DEBUG
Improve ath_draintxq debug info: dump the packet as well as the descriptor and handle the beacon q like other q's MFC after: 1 month
2006-04-16 18:24:27 +00:00
if (sc->sc_debug & ATH_DEBUG_RESET) {
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
struct ieee80211com *ic = &sc->sc_ic;
Revert the ath_tx_draintxq() method, and instead teach it the minimum necessary to "do" EDMA. It was just using the TX completion status for logging information about the descriptor completion. Since with EDMA we don't know this without checking the TX completion FIFO, we can't provide this information. So don't.
2012-08-12 00:46:15 +00:00
int status = 0;
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
Revert the ath_tx_draintxq() method, and instead teach it the minimum necessary to "do" EDMA. It was just using the TX completion status for logging information about the descriptor completion. Since with EDMA we don't know this without checking the TX completion FIFO, we can't provide this information. So don't.
2012-08-12 00:46:15 +00:00
/*
* EDMA operation has a TX completion FIFO
* separate from the TX descriptor, so this
* method of checking the "completion" status
* is wrong.
*/
if (! sc->sc_isedma) {
status = (ath_hal_txprocdesc(ah,
bf->bf_lastds,
Track v0.9.20.3 hal: o no more ds_vdata in tx/rx descriptors o split h/w tx/rx descriptor from s/w status o as part of the descriptor split change the rate control module api so the ath_buf is passed in to the module so it can fetch both descriptor and status information as needed o add some const poisoning Also for sample rate control algorithm: o split debug msgs (node, rate, any) o uniformly bounds check rate indices (and in some cases correct checks) o move array index ops to after bounds checking o use final tsi from the status block instead of the h/w descriptor o replace h/w descriptor struct's with proper mask+shift defs (this doesn't belong here; everything is known by the driver and should just be sent down so there's no h/w-specific knowledge) MFC after: 1 month
2006-12-13 19:34:35 +00:00
&bf->bf_status.ds_txstat) == HAL_OK);
Revert the ath_tx_draintxq() method, and instead teach it the minimum necessary to "do" EDMA. It was just using the TX completion status for logging information about the descriptor completion. Since with EDMA we don't know this without checking the TX completion FIFO, we can't provide this information. So don't.
2012-08-12 00:46:15 +00:00
}
ath_printtxbuf(sc, bf, txq->axq_qnum, ix, status);
don't use caddr_t to match ieee80211_dump_pkt type; supplying the correct one costs nothing
2009-04-13 20:58:47 +00:00
ieee80211_dump_pkt(ic, mtod(bf->bf_m, const uint8_t *),
bf->bf_m->m_len, 0, -1);
Improve ath_draintxq debug info: dump the packet as well as the descriptor and handle the beacon q like other q's MFC after: 1 month
2006-04-16 18:24:27 +00:00
}
o add opt_ath.h enable tweaking various config parameters for the driver without modifying the source code o default debug msgs and diag support to off MFC after: 3 days
2006-04-03 18:14:02 +00:00
#endif /* ATH_DEBUG */
Refactor out the TX buffer management and completion code in preparation for TX aggregation. * Add in logic which calls ath_buf bf->bf_comp if it's set. This allows for AMPDU (and RIFS, and FF, if someone desires) code to handle completion - which includes freeing subframes, retransmitting subframes, etc. * Break out the buffer free, buffer busy/unbusy default completion handler code into separate functions. This allows bf_comp methods to free and unbusy each subframe ath_buf as required. * Break out the statistics update code into a separate function, just to clean up the TX completion path a little. Sponsored by: Hobnob, Inc.
2011-11-08 21:49:33 +00:00
/*
* Since we're now doing magic in the completion
* functions, we -must- call it for aggregation
* destinations or BAW tracking will get upset.
*/
/*
* Clear ATH_BUF_BUSY; the completion handler
* will free the buffer.
*/
Overhaul the TXQ locking (again!) as part of some beacon/cabq timing related issues. Moving the TX locking under one lock made things easier to progress on but it had one important side-effect - it increased the latency when handling CABQ setup when sending beacons. This commit introduces a bunch of new changes and a few unrelated changs that are just easier to lump in here. The aim is to have the CABQ locking separate from other locking. The CABQ transmit path in the beacon process thus doesn't have to grab the general TX lock, reducing lock contention/latency and making it more likely that we'll make the beacon TX timing. The second half of this commit is the CABQ related setup changes needed for sane looking EDMA CABQ support. Right now the EDMA TX code naively assumes that only one frame (MPDU or A-MPDU) is being pushed into each FIFO slot. For the CABQ this isn't true - a whole list of frames is being pushed in - and thus CABQ handling breaks very quickly. The aim here is to setup the CABQ list and then push _that list_ to the hardware for transmission. I can then extend the EDMA TX code to stamp that list as being "one" FIFO entry (likely by tagging the last buffer in that list as "FIFO END") so the EDMA TX completion code correctly tracks things. Major: * Migrate the per-TXQ add/removal locking back to per-TXQ, rather than a single lock. * Leave the software queue side of things under the ATH_TX_LOCK lock, (continuing) to serialise things as they are. * Add a new function which is called whenever there's a beacon miss, to print out some debugging. This is primarily designed to help me figure out if the beacon miss events are due to a noisy environment, issues with the PHY/MAC, or other. * Move the CABQ setup/enable to occur _after_ all the VAPs have been looked at. This means that for multiple VAPS in bursted mode, the CABQ gets primed once all VAPs are checked, rather than being primed on the first VAP and then having frames appended after this. Minor: * Add a (disabled) twiddle to let me enable/disable cabq traffic. It's primarily there to let me easily debug what's going on with beacon and CABQ setup/traffic; there's some DMA engine hangs which I'm finally trying to trace down. * Clear bf_next when flushing frames; it should quieten some warnings that show up when a node goes away. Tested: * AR9280, STA/hostap, up to 4 vaps (staggered) * AR5416, STA/hostap, up to 4 vaps (staggered) TODO: * (Lots) more AR9380 and later testing, as I may have missed something here. * Leverage this to fix CABQ hanling for AR9380 and later chips. * Force bursted beaconing on the chips that default to staggered beacons and ensure the CABQ stuff is all sane (eg, the MORE bits that aren't being correctly set when chaining descriptors.)
2013-03-24 00:03:12 +00:00
ATH_TXQ_UNLOCK(txq);
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
bf->bf_flags &= ~ATH_BUF_BUSY;
Refactor out the TX buffer management and completion code in preparation for TX aggregation. * Add in logic which calls ath_buf bf->bf_comp if it's set. This allows for AMPDU (and RIFS, and FF, if someone desires) code to handle completion - which includes freeing subframes, retransmitting subframes, etc. * Break out the buffer free, buffer busy/unbusy default completion handler code into separate functions. This allows bf_comp methods to free and unbusy each subframe ath_buf as required. * Break out the statistics update code into a separate function, just to clean up the TX completion path a little. Sponsored by: Hobnob, Inc.
2011-11-08 21:49:33 +00:00
if (bf->bf_comp)
bf->bf_comp(sc, bf, 1);
else
ath_tx_default_comp(sc, bf, 1);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
Refactor out the TX buffer management and completion code in preparation for TX aggregation. * Add in logic which calls ath_buf bf->bf_comp if it's set. This allows for AMPDU (and RIFS, and FF, if someone desires) code to handle completion - which includes freeing subframes, retransmitting subframes, etc. * Break out the buffer free, buffer busy/unbusy default completion handler code into separate functions. This allows bf_comp methods to free and unbusy each subframe ath_buf as required. * Break out the statistics update code into a separate function, just to clean up the TX completion path a little. Sponsored by: Hobnob, Inc.
2011-11-08 21:49:33 +00:00
Implement "holding buffers" per TX queue rather than globally. When working on TDMA, Sam Leffler found that the MAC DMA hardware would re-read the last TX descriptor when getting ready to transmit the next one. Thus the whole ATH_BUF_BUSY came into existance - the descriptor must be left alone (very specifically the link pointer must be maintained) until the hardware has moved onto the next frame. He saw this in TDMA because the MAC would be frequently stopping during active transmit (ie, when it wasn't its turn to transmit.) Fast-forward to today. It turns out that this is a problem not with a single MAC DMA instance, but with each QCU (from 0->9). They each maintain separate descriptor pointers and will re-read the last descriptor when starting to transmit the next. So when your AP is busy transmitting from multiple TX queues, you'll (more) frequently see one QCU stopped, waiting for a higher-priority QCU to finsh transmitting, before it'll go ahead and continue. If you mess up the descriptor (ie by freeing it) then you're short of luck. Thanks to rpaulo for sticking with me whilst I diagnosed this issue that he was quite reliably triggering in his environment. This is a reimplementation; it doesn't have anything in common with the ath9k or the Qualcomm Atheros reference driver. Now - it in theory doesn't apply on the EDMA chips, as long as you push one complete frame into the FIFO at a time. But the MAC can DMA from a list of frames pushed into the hardware queue (ie, you concat 'n' frames together with link pointers, and then push the head pointer into the TXQ FIFO.) Since that's likely how I'm going to implement CABQ handling in hostap mode, it's likely that I will end up teaching the EDMA TX completion code about busy buffers, just to be "sure" this doesn't creep up. Tested - iperf ap->sta and sta->ap (with both sides running this code): * AR5416 STA * AR9160/AR9220 hostap To validate that it doesn't break the EDMA (FIFO) chips: * AR9380, AR9485, AR9462 STA Using iperf with the -S <tos byte decimal value> to set the TCP client side DSCP bits, mapping to different TIDs and thus different TX queues. TODO: * Make this work on the EDMA chips, if we end up pushing lists of frames to the hardware (eg how we eventually will handle cabq in hostap/ibss mode.)
2013-03-14 06:20:02 +00:00
/*
* Free the holding buffer if it exists
*/
Fix the holding descriptor logic to actually be "right" (for values of "right".) Flip back on the "always continue TX DMA using the holding descriptor" code - by always setting ATH_BUF_BUSY and never setting axq_link to NULL. Since the holding descriptor is accessed via txq->axq_link and _that_ is done behind the TXQ lock rather than the TX path lock, the holding descriptor stuff itself needs to be behind the TXQ lock. So, do the mental gymnastics needed to do this. I've not seen any of the hardware failures that I was seeing when I last tried to do this. Tested: * AR5416, STA mode
2013-05-08 21:23:51 +00:00
ATH_TXQ_LOCK(txq);
Implement "holding buffers" per TX queue rather than globally. When working on TDMA, Sam Leffler found that the MAC DMA hardware would re-read the last TX descriptor when getting ready to transmit the next one. Thus the whole ATH_BUF_BUSY came into existance - the descriptor must be left alone (very specifically the link pointer must be maintained) until the hardware has moved onto the next frame. He saw this in TDMA because the MAC would be frequently stopping during active transmit (ie, when it wasn't its turn to transmit.) Fast-forward to today. It turns out that this is a problem not with a single MAC DMA instance, but with each QCU (from 0->9). They each maintain separate descriptor pointers and will re-read the last descriptor when starting to transmit the next. So when your AP is busy transmitting from multiple TX queues, you'll (more) frequently see one QCU stopped, waiting for a higher-priority QCU to finsh transmitting, before it'll go ahead and continue. If you mess up the descriptor (ie by freeing it) then you're short of luck. Thanks to rpaulo for sticking with me whilst I diagnosed this issue that he was quite reliably triggering in his environment. This is a reimplementation; it doesn't have anything in common with the ath9k or the Qualcomm Atheros reference driver. Now - it in theory doesn't apply on the EDMA chips, as long as you push one complete frame into the FIFO at a time. But the MAC can DMA from a list of frames pushed into the hardware queue (ie, you concat 'n' frames together with link pointers, and then push the head pointer into the TXQ FIFO.) Since that's likely how I'm going to implement CABQ handling in hostap mode, it's likely that I will end up teaching the EDMA TX completion code about busy buffers, just to be "sure" this doesn't creep up. Tested - iperf ap->sta and sta->ap (with both sides running this code): * AR5416 STA * AR9160/AR9220 hostap To validate that it doesn't break the EDMA (FIFO) chips: * AR9380, AR9485, AR9462 STA Using iperf with the -S <tos byte decimal value> to set the TCP client side DSCP bits, mapping to different TIDs and thus different TX queues. TODO: * Make this work on the EDMA chips, if we end up pushing lists of frames to the hardware (eg how we eventually will handle cabq in hostap/ibss mode.)
2013-03-14 06:20:02 +00:00
ath_txq_freeholdingbuf(sc, txq);
Fix the holding descriptor logic to actually be "right" (for values of "right".) Flip back on the "always continue TX DMA using the holding descriptor" code - by always setting ATH_BUF_BUSY and never setting axq_link to NULL. Since the holding descriptor is accessed via txq->axq_link and _that_ is done behind the TXQ lock rather than the TX path lock, the holding descriptor stuff itself needs to be behind the TXQ lock. So, do the mental gymnastics needed to do this. I've not seen any of the hardware failures that I was seeing when I last tried to do this. Tested: * AR5416, STA mode
2013-05-08 21:23:51 +00:00
ATH_TXQ_UNLOCK(txq);
Implement "holding buffers" per TX queue rather than globally. When working on TDMA, Sam Leffler found that the MAC DMA hardware would re-read the last TX descriptor when getting ready to transmit the next one. Thus the whole ATH_BUF_BUSY came into existance - the descriptor must be left alone (very specifically the link pointer must be maintained) until the hardware has moved onto the next frame. He saw this in TDMA because the MAC would be frequently stopping during active transmit (ie, when it wasn't its turn to transmit.) Fast-forward to today. It turns out that this is a problem not with a single MAC DMA instance, but with each QCU (from 0->9). They each maintain separate descriptor pointers and will re-read the last descriptor when starting to transmit the next. So when your AP is busy transmitting from multiple TX queues, you'll (more) frequently see one QCU stopped, waiting for a higher-priority QCU to finsh transmitting, before it'll go ahead and continue. If you mess up the descriptor (ie by freeing it) then you're short of luck. Thanks to rpaulo for sticking with me whilst I diagnosed this issue that he was quite reliably triggering in his environment. This is a reimplementation; it doesn't have anything in common with the ath9k or the Qualcomm Atheros reference driver. Now - it in theory doesn't apply on the EDMA chips, as long as you push one complete frame into the FIFO at a time. But the MAC can DMA from a list of frames pushed into the hardware queue (ie, you concat 'n' frames together with link pointers, and then push the head pointer into the TXQ FIFO.) Since that's likely how I'm going to implement CABQ handling in hostap mode, it's likely that I will end up teaching the EDMA TX completion code about busy buffers, just to be "sure" this doesn't creep up. Tested - iperf ap->sta and sta->ap (with both sides running this code): * AR5416 STA * AR9160/AR9220 hostap To validate that it doesn't break the EDMA (FIFO) chips: * AR9380, AR9485, AR9462 STA Using iperf with the -S <tos byte decimal value> to set the TCP client side DSCP bits, mapping to different TIDs and thus different TX queues. TODO: * Make this work on the EDMA chips, if we end up pushing lists of frames to the hardware (eg how we eventually will handle cabq in hostap/ibss mode.)
2013-03-14 06:20:02 +00:00
Introduce TX aggregation and software TX queue management for Atheros AR5416 and later wireless devices. This is a very large commit - the complete history can be found in the user/adrian/if_ath_tx branch. Legacy (ie, pre-AR5416) devices also use the per-software TXQ support and (in theory) can support non-aggregation ADDBA sessions. However, the net80211 stack doesn't currently support this. In summary: TX path: * queued frames normally go onto a per-TID, per-node queue * some special frames (eg ADDBA control frames) are thrown directly onto the relevant hardware queue so they can go out before any software queued frames are queued. * Add methods to create, suspend, resume and tear down an aggregation session. * Add in software retransmission of both normal and aggregate frames. * Add in completion handling of aggregate frames, including parsing the block ack bitmap provided by the hardware. * Write an aggregation function which can assemble frames into an aggregate based on the selected rate control and channel configuration. * The per-TID queues are locked based on their target hardware TX queue. This matches what ath9k/atheros does, and thus simplified porting over some of the aggregation logic. * When doing TX aggregation, stick the sequence number allocation in the TX path rather than net80211 TX path, and protect it by the TXQ lock. Rate control: * Delay rate control selection until the frame is about to be queued to the hardware, so retried frames can have their rate control choices changed. Frames with a static rate control selection have that applied before each TX, just to simplify the TX path (ie, not have "static" and "dynamic" rate control special cased.) * Teach ath_rate_sample about aggregates - both completion and errors. * Add an EWMA for tracking what the current "good" MCS rate is based on failure rates. Misc: * Introduce a bunch of dirty hacks and workarounds so TID mapping and net80211 frame inspection can be kept out of the net80211 layer. Because of the way this code works (and it's from Atheros and Linux ath9k), there is a consistent, 1:1 mapping between TID and AC. So we need to ensure that frames going to a specific TID will _always_ end up on the right AC, and vice versa, or the completion/locking will simply get very confused. I plan on addressing this mess in the future. Known issues: * There is no BAR frame transmission just yet. A whole lot of tidying up needs to occur before BAR frame TX can occur in the "correct" place - ie, once the TID TX queue has been drained. * Interface reset/purge/etc results in frames in the TX and RX queues being removed. This creates holes in the sequence numbers being assigned and the TX/RX AMPDU code (on either side) just hangs. * There's no filtered frame support at the present moment, so stations going into power saving mode will simply have a number of frames dropped - likely resulting in a traffic "hang". * Raw frame TX is going to just not function with 11n aggregation. Likely this needs to be modified to always override the sequence number if the frame is going into an aggregation session. However, general raw frame injection currently doesn't work in general in net80211, so let's just ignore this for now until this is sorted out. * HT protection is just not implemented and won't be until the above is sorted out. In addition, the AR5416 has issues RTS protecting large aggregates (anything >8k), so the work around needs to be ported and tested. Thus, this will be put on hold until the above work is complete. * The rate control module 'sample' is the only currently supported module; onoe/amrr haven't been tested and have likely bit rotted a little. I'll follow up with some commits to make them work again for non-11n rates, but they won't be updated to handle 11n and aggregation. If someone wishes to do so then they're welcome to send along patches. * .. and "sample" doesn't really do a good job of 11n TX. Specifically, the metrics used (packet TX time and failure/success rates) isn't as useful for 11n. It's likely that it should be extended to take into account the aggregate throughput possible and then choose a rate which maximises that. Ie, it may be acceptable for a higher MCS rate with a higher failure to be used if it gives a more acceptable throughput/latency then a lower MCS rate @ a lower error rate. Again, patches will be gratefully accepted. Because of this, ATH_ENABLE_11N is still not enabled by default. Sponsored by: Hobnob, Inc. Obtained from: Linux, Atheros
2011-11-08 22:43:13 +00:00
/*
* Drain software queued frames which are on
* active TIDs.
*/
ath_tx_txq_drain(sc, txq);
Update with last year of work.
2004-12-08 17:34:36 +00:00
}
static void
ath_tx_stopdma(struct ath_softc *sc, struct ath_txq *txq)
{
struct ath_hal *ah = sc->sc_ah;
Be (very) careful about how to add more TX DMA work. The list-based DMA engine has the following behaviour: * When the DMA engine is in the init state, you can write the first descriptor address to the QCU TxDP register and it will work. * Then when it hits the end of the list (ie, it either hits a NULL link pointer, OR it hits a descriptor with VEOL set) the QCU stops, and the TxDP points to the last descriptor that was transmitted. * Then when you want to transmit a new frame, you can then either: + write the head of the new list into TxDP, or + you write the head of the new list into the link pointer of the last completed descriptor (ie, where TxDP points), then kick TxE to restart transmission on that QCU> * The hardware then will re-read the descriptor to pick up the link pointer and then jump to that. Now, the quirks: * If you write a TxDP when there's been no previous TxDP (ie, it's 0), it works. * If you write a TxDP in any other instance, the TxDP write may actually fail. Thus, when you start transmission, it will re-read the last transmitted descriptor to get the link pointer, NOT just start a new transmission. So the correct thing to do here is: * ALWAYS use the holding descriptor (ie, the last transmitted descriptor that we've kept safe) and use the link pointer in _THAT_ to transmit the next frame. * NEVER write to the TxDP after you've done the initial write. * .. also, don't do this whilst you're also resetting the NIC. With this in mind, the following patch does basically the above. * Since this encapsulates Sam's issues with the QCU behaviour w/ TDMA, kill the TDMA special case and replace it with the above. * Add a new TXQ flag - PUTRUNNING - which indicates that we've started DMA. * Clear that flag when DMA has been shutdown. * Ensure that we're not restarting DMA with PUTRUNNING enabled. * Fix the link pointer logic during TXQ drain - we should always ensure the link pointer does point to something if there's a list of frames. Having it be NULL as an indication that DMA has finished or during a reset causes trouble. Now, given all of this, i want to nuke axq_link from orbit. There's now HAL methods to get and set the link pointer of a descriptor, so what we should do instead is to update the right link pointer. * If there's a holding descriptor and an empty TXQ list, set the link pointer of said holding descriptor to the new frame. * If there's a non-empty TXQ list, set the link pointer of the last descriptor in the list to the new frame. * Nuke axq_link from orbit. Note: * The AR9380 doesn't need this. FIFO TX writes are atomic. As long as we don't append to a list of frames that we've already passed to the hardware, all of the above doesn't apply. The holding descriptor stuff is still needed to ensure the hardware can re-read a completed descriptor to move onto the next one, but we restart DMA by pushing in a new FIFO entry into the TX QCU. That doesn't require any real gymnastics. Tested: * AR5210, AR5211, AR5212, AR5416, AR9380 - STA mode.
2013-05-18 18:27:53 +00:00
ATH_TXQ_LOCK_ASSERT(txq);
Print out the queue flags during a TX DMA shutdown.
2013-03-09 06:11:58 +00:00
DPRINTF(sc, ATH_DEBUG_RESET,
Dump out the holding buffer descriptor contents and addresses stopping DMA.
2013-05-16 17:45:01 +00:00
"%s: tx queue [%u] %p, active=%d, hwpending=%d, flags 0x%08x, "
"link %p, holdingbf=%p\n",
Print out the queue flags during a TX DMA shutdown.
2013-03-09 06:11:58 +00:00
__func__,
txq->axq_qnum,
Make this amd64-clean. sizeof is long on amd64, so things that do a printf of a sizeof, need to use %z to get the correct type on all our platforms. Also, convert integers<->pointers via uintptr_t. (I think Sam's instructions were for me to commit this. If I misunderstood, then I apologize in advance.)
2004-12-15 02:25:21 +00:00
(caddr_t)(uintptr_t) ath_hal_gettxbuf(ah, txq->axq_qnum),
Debugging changes! * That lock isn't actually held during reset - just the whole TX/RX path is paused. So, remove the assertion. * Log the TX queue status - how many hardware frames are active in the MAC and whether the queue is active.
2013-04-29 07:28:29 +00:00
(int) (!! ath_hal_txqenabled(ah, txq->axq_qnum)),
(int) ath_hal_numtxpending(ah, txq->axq_qnum),
Print out the queue flags during a TX DMA shutdown.
2013-03-09 06:11:58 +00:00
txq->axq_flags,
Dump out the holding buffer descriptor contents and addresses stopping DMA.
2013-05-16 17:45:01 +00:00
txq->axq_link,
txq->axq_holdingbf);
Improve ath_draintxq debug info: dump the packet as well as the descriptor and handle the beacon q like other q's MFC after: 1 month
2006-04-16 18:24:27 +00:00
(void) ath_hal_stoptxdma(ah, txq->axq_qnum);
Be (very) careful about how to add more TX DMA work. The list-based DMA engine has the following behaviour: * When the DMA engine is in the init state, you can write the first descriptor address to the QCU TxDP register and it will work. * Then when it hits the end of the list (ie, it either hits a NULL link pointer, OR it hits a descriptor with VEOL set) the QCU stops, and the TxDP points to the last descriptor that was transmitted. * Then when you want to transmit a new frame, you can then either: + write the head of the new list into TxDP, or + you write the head of the new list into the link pointer of the last completed descriptor (ie, where TxDP points), then kick TxE to restart transmission on that QCU> * The hardware then will re-read the descriptor to pick up the link pointer and then jump to that. Now, the quirks: * If you write a TxDP when there's been no previous TxDP (ie, it's 0), it works. * If you write a TxDP in any other instance, the TxDP write may actually fail. Thus, when you start transmission, it will re-read the last transmitted descriptor to get the link pointer, NOT just start a new transmission. So the correct thing to do here is: * ALWAYS use the holding descriptor (ie, the last transmitted descriptor that we've kept safe) and use the link pointer in _THAT_ to transmit the next frame. * NEVER write to the TxDP after you've done the initial write. * .. also, don't do this whilst you're also resetting the NIC. With this in mind, the following patch does basically the above. * Since this encapsulates Sam's issues with the QCU behaviour w/ TDMA, kill the TDMA special case and replace it with the above. * Add a new TXQ flag - PUTRUNNING - which indicates that we've started DMA. * Clear that flag when DMA has been shutdown. * Ensure that we're not restarting DMA with PUTRUNNING enabled. * Fix the link pointer logic during TXQ drain - we should always ensure the link pointer does point to something if there's a list of frames. Having it be NULL as an indication that DMA has finished or during a reset causes trouble. Now, given all of this, i want to nuke axq_link from orbit. There's now HAL methods to get and set the link pointer of a descriptor, so what we should do instead is to update the right link pointer. * If there's a holding descriptor and an empty TXQ list, set the link pointer of said holding descriptor to the new frame. * If there's a non-empty TXQ list, set the link pointer of the last descriptor in the list to the new frame. * Nuke axq_link from orbit. Note: * The AR9380 doesn't need this. FIFO TX writes are atomic. As long as we don't append to a list of frames that we've already passed to the hardware, all of the above doesn't apply. The holding descriptor stuff is still needed to ensure the hardware can re-read a completed descriptor to move onto the next one, but we restart DMA by pushing in a new FIFO entry into the TX QCU. That doesn't require any real gymnastics. Tested: * AR5210, AR5211, AR5212, AR5416, AR9380 - STA mode.
2013-05-18 18:27:53 +00:00
/* We've stopped TX DMA, so mark this as stopped. */
txq->axq_flags &= ~ATH_TXQ_PUTRUNNING;
Dump out the holding buffer descriptor contents and addresses stopping DMA.
2013-05-16 17:45:01 +00:00
#ifdef ATH_DEBUG
if ((sc->sc_debug & ATH_DEBUG_RESET)
&& (txq->axq_holdingbf != NULL)) {
ath_printtxbuf(sc, txq->axq_holdingbf, txq->axq_qnum, 0, 0);
}
#endif
Update with last year of work.
2004-12-08 17:34:36 +00:00
}
Break out the TX completion code into a separate function, so it can be re-used by the upcoming EDMA TX completion code. Make ath_stoptxdma() public, again so the EDMA TX code can use it. Don't check for the TXQ bitmap in the ISR when doing EDMA work as it doesn't apply for EDMA.
2012-08-14 22:32:20 +00:00
int
Break out the TX DMA stop code into a separate function. Sponsored by: Hobnob, Inc.
2011-11-08 21:06:36 +00:00
ath_stoptxdma(struct ath_softc *sc)
Update with last year of work.
2004-12-08 17:34:36 +00:00
{
struct ath_hal *ah = sc->sc_ah;
int i;
/* XXX return value */
Break out the TX DMA stop code into a separate function. Sponsored by: Hobnob, Inc.
2011-11-08 21:06:36 +00:00
if (sc->sc_invalid)
return 0;
Update with last year of work.
2004-12-08 17:34:36 +00:00
if (!sc->sc_invalid) {
/* don't touch the hardware if marked invalid */
Improve ath_draintxq debug info: dump the packet as well as the descriptor and handle the beacon q like other q's MFC after: 1 month
2006-04-16 18:24:27 +00:00
DPRINTF(sc, ATH_DEBUG_RESET, "%s: tx queue [%u] %p, link %p\n",
__func__, sc->sc_bhalq,
(caddr_t)(uintptr_t) ath_hal_gettxbuf(ah, sc->sc_bhalq),
NULL);
Be (very) careful about how to add more TX DMA work. The list-based DMA engine has the following behaviour: * When the DMA engine is in the init state, you can write the first descriptor address to the QCU TxDP register and it will work. * Then when it hits the end of the list (ie, it either hits a NULL link pointer, OR it hits a descriptor with VEOL set) the QCU stops, and the TxDP points to the last descriptor that was transmitted. * Then when you want to transmit a new frame, you can then either: + write the head of the new list into TxDP, or + you write the head of the new list into the link pointer of the last completed descriptor (ie, where TxDP points), then kick TxE to restart transmission on that QCU> * The hardware then will re-read the descriptor to pick up the link pointer and then jump to that. Now, the quirks: * If you write a TxDP when there's been no previous TxDP (ie, it's 0), it works. * If you write a TxDP in any other instance, the TxDP write may actually fail. Thus, when you start transmission, it will re-read the last transmitted descriptor to get the link pointer, NOT just start a new transmission. So the correct thing to do here is: * ALWAYS use the holding descriptor (ie, the last transmitted descriptor that we've kept safe) and use the link pointer in _THAT_ to transmit the next frame. * NEVER write to the TxDP after you've done the initial write. * .. also, don't do this whilst you're also resetting the NIC. With this in mind, the following patch does basically the above. * Since this encapsulates Sam's issues with the QCU behaviour w/ TDMA, kill the TDMA special case and replace it with the above. * Add a new TXQ flag - PUTRUNNING - which indicates that we've started DMA. * Clear that flag when DMA has been shutdown. * Ensure that we're not restarting DMA with PUTRUNNING enabled. * Fix the link pointer logic during TXQ drain - we should always ensure the link pointer does point to something if there's a list of frames. Having it be NULL as an indication that DMA has finished or during a reset causes trouble. Now, given all of this, i want to nuke axq_link from orbit. There's now HAL methods to get and set the link pointer of a descriptor, so what we should do instead is to update the right link pointer. * If there's a holding descriptor and an empty TXQ list, set the link pointer of said holding descriptor to the new frame. * If there's a non-empty TXQ list, set the link pointer of the last descriptor in the list to the new frame. * Nuke axq_link from orbit. Note: * The AR9380 doesn't need this. FIFO TX writes are atomic. As long as we don't append to a list of frames that we've already passed to the hardware, all of the above doesn't apply. The holding descriptor stuff is still needed to ensure the hardware can re-read a completed descriptor to move onto the next one, but we restart DMA by pushing in a new FIFO entry into the TX QCU. That doesn't require any real gymnastics. Tested: * AR5210, AR5211, AR5212, AR5416, AR9380 - STA mode.
2013-05-18 18:27:53 +00:00
/* stop the beacon queue */
Update with last year of work.
2004-12-08 17:34:36 +00:00
(void) ath_hal_stoptxdma(ah, sc->sc_bhalq);
Be (very) careful about how to add more TX DMA work. The list-based DMA engine has the following behaviour: * When the DMA engine is in the init state, you can write the first descriptor address to the QCU TxDP register and it will work. * Then when it hits the end of the list (ie, it either hits a NULL link pointer, OR it hits a descriptor with VEOL set) the QCU stops, and the TxDP points to the last descriptor that was transmitted. * Then when you want to transmit a new frame, you can then either: + write the head of the new list into TxDP, or + you write the head of the new list into the link pointer of the last completed descriptor (ie, where TxDP points), then kick TxE to restart transmission on that QCU> * The hardware then will re-read the descriptor to pick up the link pointer and then jump to that. Now, the quirks: * If you write a TxDP when there's been no previous TxDP (ie, it's 0), it works. * If you write a TxDP in any other instance, the TxDP write may actually fail. Thus, when you start transmission, it will re-read the last transmitted descriptor to get the link pointer, NOT just start a new transmission. So the correct thing to do here is: * ALWAYS use the holding descriptor (ie, the last transmitted descriptor that we've kept safe) and use the link pointer in _THAT_ to transmit the next frame. * NEVER write to the TxDP after you've done the initial write. * .. also, don't do this whilst you're also resetting the NIC. With this in mind, the following patch does basically the above. * Since this encapsulates Sam's issues with the QCU behaviour w/ TDMA, kill the TDMA special case and replace it with the above. * Add a new TXQ flag - PUTRUNNING - which indicates that we've started DMA. * Clear that flag when DMA has been shutdown. * Ensure that we're not restarting DMA with PUTRUNNING enabled. * Fix the link pointer logic during TXQ drain - we should always ensure the link pointer does point to something if there's a list of frames. Having it be NULL as an indication that DMA has finished or during a reset causes trouble. Now, given all of this, i want to nuke axq_link from orbit. There's now HAL methods to get and set the link pointer of a descriptor, so what we should do instead is to update the right link pointer. * If there's a holding descriptor and an empty TXQ list, set the link pointer of said holding descriptor to the new frame. * If there's a non-empty TXQ list, set the link pointer of the last descriptor in the list to the new frame. * Nuke axq_link from orbit. Note: * The AR9380 doesn't need this. FIFO TX writes are atomic. As long as we don't append to a list of frames that we've already passed to the hardware, all of the above doesn't apply. The holding descriptor stuff is still needed to ensure the hardware can re-read a completed descriptor to move onto the next one, but we restart DMA by pushing in a new FIFO entry into the TX QCU. That doesn't require any real gymnastics. Tested: * AR5210, AR5211, AR5212, AR5416, AR9380 - STA mode.
2013-05-18 18:27:53 +00:00
/* Stop the data queues */
for (i = 0; i < HAL_NUM_TX_QUEUES; i++) {
if (ATH_TXQ_SETUP(sc, i)) {
ATH_TXQ_LOCK(&sc->sc_txq[i]);
Update with last year of work.
2004-12-08 17:34:36 +00:00
ath_tx_stopdma(sc, &sc->sc_txq[i]);
Be (very) careful about how to add more TX DMA work. The list-based DMA engine has the following behaviour: * When the DMA engine is in the init state, you can write the first descriptor address to the QCU TxDP register and it will work. * Then when it hits the end of the list (ie, it either hits a NULL link pointer, OR it hits a descriptor with VEOL set) the QCU stops, and the TxDP points to the last descriptor that was transmitted. * Then when you want to transmit a new frame, you can then either: + write the head of the new list into TxDP, or + you write the head of the new list into the link pointer of the last completed descriptor (ie, where TxDP points), then kick TxE to restart transmission on that QCU> * The hardware then will re-read the descriptor to pick up the link pointer and then jump to that. Now, the quirks: * If you write a TxDP when there's been no previous TxDP (ie, it's 0), it works. * If you write a TxDP in any other instance, the TxDP write may actually fail. Thus, when you start transmission, it will re-read the last transmitted descriptor to get the link pointer, NOT just start a new transmission. So the correct thing to do here is: * ALWAYS use the holding descriptor (ie, the last transmitted descriptor that we've kept safe) and use the link pointer in _THAT_ to transmit the next frame. * NEVER write to the TxDP after you've done the initial write. * .. also, don't do this whilst you're also resetting the NIC. With this in mind, the following patch does basically the above. * Since this encapsulates Sam's issues with the QCU behaviour w/ TDMA, kill the TDMA special case and replace it with the above. * Add a new TXQ flag - PUTRUNNING - which indicates that we've started DMA. * Clear that flag when DMA has been shutdown. * Ensure that we're not restarting DMA with PUTRUNNING enabled. * Fix the link pointer logic during TXQ drain - we should always ensure the link pointer does point to something if there's a list of frames. Having it be NULL as an indication that DMA has finished or during a reset causes trouble. Now, given all of this, i want to nuke axq_link from orbit. There's now HAL methods to get and set the link pointer of a descriptor, so what we should do instead is to update the right link pointer. * If there's a holding descriptor and an empty TXQ list, set the link pointer of said holding descriptor to the new frame. * If there's a non-empty TXQ list, set the link pointer of the last descriptor in the list to the new frame. * Nuke axq_link from orbit. Note: * The AR9380 doesn't need this. FIFO TX writes are atomic. As long as we don't append to a list of frames that we've already passed to the hardware, all of the above doesn't apply. The holding descriptor stuff is still needed to ensure the hardware can re-read a completed descriptor to move onto the next one, but we restart DMA by pushing in a new FIFO entry into the TX QCU. That doesn't require any real gymnastics. Tested: * AR5210, AR5211, AR5212, AR5416, AR9380 - STA mode.
2013-05-18 18:27:53 +00:00
ATH_TXQ_UNLOCK(&sc->sc_txq[i]);
}
}
Update with last year of work.
2004-12-08 17:34:36 +00:00
}
Break out the TX DMA stop code into a separate function. Sponsored by: Hobnob, Inc.
2011-11-08 21:06:36 +00:00
return 1;
}
Conditionally compile this only if ATH_DEBUG is defined.
2013-04-26 22:22:38 +00:00
#ifdef ATH_DEBUG
Be (very) careful about how to add more TX DMA work. The list-based DMA engine has the following behaviour: * When the DMA engine is in the init state, you can write the first descriptor address to the QCU TxDP register and it will work. * Then when it hits the end of the list (ie, it either hits a NULL link pointer, OR it hits a descriptor with VEOL set) the QCU stops, and the TxDP points to the last descriptor that was transmitted. * Then when you want to transmit a new frame, you can then either: + write the head of the new list into TxDP, or + you write the head of the new list into the link pointer of the last completed descriptor (ie, where TxDP points), then kick TxE to restart transmission on that QCU> * The hardware then will re-read the descriptor to pick up the link pointer and then jump to that. Now, the quirks: * If you write a TxDP when there's been no previous TxDP (ie, it's 0), it works. * If you write a TxDP in any other instance, the TxDP write may actually fail. Thus, when you start transmission, it will re-read the last transmitted descriptor to get the link pointer, NOT just start a new transmission. So the correct thing to do here is: * ALWAYS use the holding descriptor (ie, the last transmitted descriptor that we've kept safe) and use the link pointer in _THAT_ to transmit the next frame. * NEVER write to the TxDP after you've done the initial write. * .. also, don't do this whilst you're also resetting the NIC. With this in mind, the following patch does basically the above. * Since this encapsulates Sam's issues with the QCU behaviour w/ TDMA, kill the TDMA special case and replace it with the above. * Add a new TXQ flag - PUTRUNNING - which indicates that we've started DMA. * Clear that flag when DMA has been shutdown. * Ensure that we're not restarting DMA with PUTRUNNING enabled. * Fix the link pointer logic during TXQ drain - we should always ensure the link pointer does point to something if there's a list of frames. Having it be NULL as an indication that DMA has finished or during a reset causes trouble. Now, given all of this, i want to nuke axq_link from orbit. There's now HAL methods to get and set the link pointer of a descriptor, so what we should do instead is to update the right link pointer. * If there's a holding descriptor and an empty TXQ list, set the link pointer of said holding descriptor to the new frame. * If there's a non-empty TXQ list, set the link pointer of the last descriptor in the list to the new frame. * Nuke axq_link from orbit. Note: * The AR9380 doesn't need this. FIFO TX writes are atomic. As long as we don't append to a list of frames that we've already passed to the hardware, all of the above doesn't apply. The holding descriptor stuff is still needed to ensure the hardware can re-read a completed descriptor to move onto the next one, but we restart DMA by pushing in a new FIFO entry into the TX QCU. That doesn't require any real gymnastics. Tested: * AR5210, AR5211, AR5212, AR5416, AR9380 - STA mode.
2013-05-18 18:27:53 +00:00
void
Dump the entire TXQ descriptor contents during a reset, rather than only completed descriptors.
2013-04-26 21:51:17 +00:00
ath_tx_dump(struct ath_softc *sc, struct ath_txq *txq)
{
struct ath_hal *ah = sc->sc_ah;
struct ath_buf *bf;
int i = 0;
if (! (sc->sc_debug & ATH_DEBUG_RESET))
return;
device_printf(sc->sc_dev, "%s: Q%d: begin\n",
__func__, txq->axq_qnum);
TAILQ_FOREACH(bf, &txq->axq_q, bf_list) {
ath_printtxbuf(sc, bf, txq->axq_qnum, i,
ath_hal_txprocdesc(ah, bf->bf_lastds,
&bf->bf_status.ds_txstat) == HAL_OK);
i++;
}
device_printf(sc->sc_dev, "%s: Q%d: end\n",
__func__, txq->axq_qnum);
}
Conditionally compile this only if ATH_DEBUG is defined.
2013-04-26 22:22:38 +00:00
#endif /* ATH_DEBUG */
Dump the entire TXQ descriptor contents during a reset, rather than only completed descriptors.
2013-04-26 21:51:17 +00:00
Break out the TX DMA stop code into a separate function. Sponsored by: Hobnob, Inc.
2011-11-08 21:06:36 +00:00
/*
* Drain the transmit queues and reclaim resources.
*/
Break out ath_draintxq() into a method and un-methodize ath_tx_processq(). Now that I understand what's going on with this, I've realised that it's going to be quite difficult to implement a processq method in the EDMA case. Because there's a separate TX status FIFO, I can't just run processq() on each EDMA TXQ to see what's finished. i have to actually run the TX status queue and handle individual TXQs. So: * unmethodize ath_tx_processq(); * leave ath_tx_draintxq() as a method, as it only uses the completion status for debugging rather than actively completing the frames (ie, all frames here are failed); * Methodize ath_draintxq(). The EDMA ath_draintxq() will have to take care of running the TX completion FIFO before (potentially) freeing frames in the queue. The only two places where ath_tx_draintxq() (on a single TXQ) are used: * ath_draintxq(); and * the CABQ handling in the beacon setup code - it drains the CABQ before populating the CABQ with frames for a new beacon (when doing multi-VAP operation.) So it's quite possible that once I methodize the CABQ and beacon handling, I can just drop ath_tx_draintxq() in its entirety. Finally, it's also quite possible that I can remove ath_tx_draintxq() in the future and just "teach" it to not check the status when doing EDMA.
2012-08-12 00:37:29 +00:00
void
ath_legacy_tx_drain(struct ath_softc *sc, ATH_RESET_TYPE reset_type)
Break out the TX DMA stop code into a separate function. Sponsored by: Hobnob, Inc.
2011-11-08 21:06:36 +00:00
{
struct ath_hal *ah = sc->sc_ah;
Revert the wifi ifnet changes until things are more baked and tested. * 286410 * 286413 * 286416 The initial commit broke a variety of debug and features that aren't in the GENERIC kernels but are enabled in other platforms.
2015-08-08 01:10:17 +00:00
struct ath_buf *bf_last;
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
int i;
Break out the TX DMA stop code into a separate function. Sponsored by: Hobnob, Inc.
2011-11-08 21:06:36 +00:00
(void) ath_stoptxdma(sc);
Dump the entire TXQ descriptor contents during a reset, rather than only completed descriptors.
2013-04-26 21:51:17 +00:00
/*
* Dump the queue contents
*/
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
for (i = 0; i < HAL_NUM_TX_QUEUES; i++) {
/*
* XXX TODO: should we just handle the completed TX frames
* here, whether or not the reset is a full one or not?
*/
if (ATH_TXQ_SETUP(sc, i)) {
Conditionally compile this only if ATH_DEBUG is defined.
2013-04-26 22:22:38 +00:00
#ifdef ATH_DEBUG
Dump the entire TXQ descriptor contents during a reset, rather than only completed descriptors.
2013-04-26 21:51:17 +00:00
if (sc->sc_debug & ATH_DEBUG_RESET)
ath_tx_dump(sc, &sc->sc_txq[i]);
Conditionally compile this only if ATH_DEBUG is defined.
2013-04-26 22:22:38 +00:00
#endif /* ATH_DEBUG */
Make sure the holding descriptor and link pointer are both freed during a non-loss reset. When the drain functions are called, the holding descriptor and link pointers are NULLed out. But when the processq function is called during a non-loss reset, this doesn't occur. So the next time a DMA occurs, it's chained to a descriptor that no longer exists and the hardware gets angry. Tested: * AR5416, STA mode; use sysctl dev.ath.X.forcebstuck=1 to force a non-loss reset. TODO: * Further AR9380 testing just to check that the behaviour for the EDMA chips is sane. PR: kern/178477
2013-05-10 10:06:45 +00:00
if (reset_type == ATH_RESET_NOLOSS) {
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
ath_tx_processq(sc, &sc->sc_txq[i], 0);
Make sure the holding descriptor and link pointer are both freed during a non-loss reset. When the drain functions are called, the holding descriptor and link pointers are NULLed out. But when the processq function is called during a non-loss reset, this doesn't occur. So the next time a DMA occurs, it's chained to a descriptor that no longer exists and the hardware gets angry. Tested: * AR5416, STA mode; use sysctl dev.ath.X.forcebstuck=1 to force a non-loss reset. TODO: * Further AR9380 testing just to check that the behaviour for the EDMA chips is sane. PR: kern/178477
2013-05-10 10:06:45 +00:00
ATH_TXQ_LOCK(&sc->sc_txq[i]);
/*
* Free the holding buffer; DMA is now
* stopped.
*/
ath_txq_freeholdingbuf(sc, &sc->sc_txq[i]);
/*
Be (very) careful about how to add more TX DMA work. The list-based DMA engine has the following behaviour: * When the DMA engine is in the init state, you can write the first descriptor address to the QCU TxDP register and it will work. * Then when it hits the end of the list (ie, it either hits a NULL link pointer, OR it hits a descriptor with VEOL set) the QCU stops, and the TxDP points to the last descriptor that was transmitted. * Then when you want to transmit a new frame, you can then either: + write the head of the new list into TxDP, or + you write the head of the new list into the link pointer of the last completed descriptor (ie, where TxDP points), then kick TxE to restart transmission on that QCU> * The hardware then will re-read the descriptor to pick up the link pointer and then jump to that. Now, the quirks: * If you write a TxDP when there's been no previous TxDP (ie, it's 0), it works. * If you write a TxDP in any other instance, the TxDP write may actually fail. Thus, when you start transmission, it will re-read the last transmitted descriptor to get the link pointer, NOT just start a new transmission. So the correct thing to do here is: * ALWAYS use the holding descriptor (ie, the last transmitted descriptor that we've kept safe) and use the link pointer in _THAT_ to transmit the next frame. * NEVER write to the TxDP after you've done the initial write. * .. also, don't do this whilst you're also resetting the NIC. With this in mind, the following patch does basically the above. * Since this encapsulates Sam's issues with the QCU behaviour w/ TDMA, kill the TDMA special case and replace it with the above. * Add a new TXQ flag - PUTRUNNING - which indicates that we've started DMA. * Clear that flag when DMA has been shutdown. * Ensure that we're not restarting DMA with PUTRUNNING enabled. * Fix the link pointer logic during TXQ drain - we should always ensure the link pointer does point to something if there's a list of frames. Having it be NULL as an indication that DMA has finished or during a reset causes trouble. Now, given all of this, i want to nuke axq_link from orbit. There's now HAL methods to get and set the link pointer of a descriptor, so what we should do instead is to update the right link pointer. * If there's a holding descriptor and an empty TXQ list, set the link pointer of said holding descriptor to the new frame. * If there's a non-empty TXQ list, set the link pointer of the last descriptor in the list to the new frame. * Nuke axq_link from orbit. Note: * The AR9380 doesn't need this. FIFO TX writes are atomic. As long as we don't append to a list of frames that we've already passed to the hardware, all of the above doesn't apply. The holding descriptor stuff is still needed to ensure the hardware can re-read a completed descriptor to move onto the next one, but we restart DMA by pushing in a new FIFO entry into the TX QCU. That doesn't require any real gymnastics. Tested: * AR5210, AR5211, AR5212, AR5416, AR9380 - STA mode.
2013-05-18 18:27:53 +00:00
* Setup the link pointer to be the
* _last_ buffer/descriptor in the list.
* If there's nothing in the list, set it
* to NULL.
Make sure the holding descriptor and link pointer are both freed during a non-loss reset. When the drain functions are called, the holding descriptor and link pointers are NULLed out. But when the processq function is called during a non-loss reset, this doesn't occur. So the next time a DMA occurs, it's chained to a descriptor that no longer exists and the hardware gets angry. Tested: * AR5416, STA mode; use sysctl dev.ath.X.forcebstuck=1 to force a non-loss reset. TODO: * Further AR9380 testing just to check that the behaviour for the EDMA chips is sane. PR: kern/178477
2013-05-10 10:06:45 +00:00
*/
Be (very) careful about how to add more TX DMA work. The list-based DMA engine has the following behaviour: * When the DMA engine is in the init state, you can write the first descriptor address to the QCU TxDP register and it will work. * Then when it hits the end of the list (ie, it either hits a NULL link pointer, OR it hits a descriptor with VEOL set) the QCU stops, and the TxDP points to the last descriptor that was transmitted. * Then when you want to transmit a new frame, you can then either: + write the head of the new list into TxDP, or + you write the head of the new list into the link pointer of the last completed descriptor (ie, where TxDP points), then kick TxE to restart transmission on that QCU> * The hardware then will re-read the descriptor to pick up the link pointer and then jump to that. Now, the quirks: * If you write a TxDP when there's been no previous TxDP (ie, it's 0), it works. * If you write a TxDP in any other instance, the TxDP write may actually fail. Thus, when you start transmission, it will re-read the last transmitted descriptor to get the link pointer, NOT just start a new transmission. So the correct thing to do here is: * ALWAYS use the holding descriptor (ie, the last transmitted descriptor that we've kept safe) and use the link pointer in _THAT_ to transmit the next frame. * NEVER write to the TxDP after you've done the initial write. * .. also, don't do this whilst you're also resetting the NIC. With this in mind, the following patch does basically the above. * Since this encapsulates Sam's issues with the QCU behaviour w/ TDMA, kill the TDMA special case and replace it with the above. * Add a new TXQ flag - PUTRUNNING - which indicates that we've started DMA. * Clear that flag when DMA has been shutdown. * Ensure that we're not restarting DMA with PUTRUNNING enabled. * Fix the link pointer logic during TXQ drain - we should always ensure the link pointer does point to something if there's a list of frames. Having it be NULL as an indication that DMA has finished or during a reset causes trouble. Now, given all of this, i want to nuke axq_link from orbit. There's now HAL methods to get and set the link pointer of a descriptor, so what we should do instead is to update the right link pointer. * If there's a holding descriptor and an empty TXQ list, set the link pointer of said holding descriptor to the new frame. * If there's a non-empty TXQ list, set the link pointer of the last descriptor in the list to the new frame. * Nuke axq_link from orbit. Note: * The AR9380 doesn't need this. FIFO TX writes are atomic. As long as we don't append to a list of frames that we've already passed to the hardware, all of the above doesn't apply. The holding descriptor stuff is still needed to ensure the hardware can re-read a completed descriptor to move onto the next one, but we restart DMA by pushing in a new FIFO entry into the TX QCU. That doesn't require any real gymnastics. Tested: * AR5210, AR5211, AR5212, AR5416, AR9380 - STA mode.
2013-05-18 18:27:53 +00:00
bf_last = ATH_TXQ_LAST(&sc->sc_txq[i],
axq_q_s);
if (bf_last != NULL) {
ath_hal_gettxdesclinkptr(ah,
bf_last->bf_lastds,
&sc->sc_txq[i].axq_link);
} else {
sc->sc_txq[i].axq_link = NULL;
}
Make sure the holding descriptor and link pointer are both freed during a non-loss reset. When the drain functions are called, the holding descriptor and link pointers are NULLed out. But when the processq function is called during a non-loss reset, this doesn't occur. So the next time a DMA occurs, it's chained to a descriptor that no longer exists and the hardware gets angry. Tested: * AR5416, STA mode; use sysctl dev.ath.X.forcebstuck=1 to force a non-loss reset. TODO: * Further AR9380 testing just to check that the behaviour for the EDMA chips is sane. PR: kern/178477
2013-05-10 10:06:45 +00:00
ATH_TXQ_UNLOCK(&sc->sc_txq[i]);
} else
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
ath_tx_draintxq(sc, &sc->sc_txq[i]);
}
}
Improve ath_draintxq debug info: dump the packet as well as the descriptor and handle the beacon q like other q's MFC after: 1 month
2006-04-16 18:24:27 +00:00
#ifdef ATH_DEBUG
if (sc->sc_debug & ATH_DEBUG_RESET) {
Migrate the STAILQ lists to TAILQs. A bunch of the 11n TX aggregation logic wants to traverse lists of buffers in various ways. In order to provide O(1) behaviour in this instance, use TAILQs. This does blow out the memory footprint and CPU cycles slightly for some of these operations. I may convert some of these back to STAILQs once the rest of the software transmit queue handling has been stabilised. Sponsored by: Hobnob, Inc.
2011-11-08 17:08:12 +00:00
struct ath_buf *bf = TAILQ_FIRST(&sc->sc_bbuf);
Improve ath_draintxq debug info: dump the packet as well as the descriptor and handle the beacon q like other q's MFC after: 1 month
2006-04-16 18:24:27 +00:00
if (bf != NULL && bf->bf_m != NULL) {
print the extended tx/rx descriptor for 5416 and later parts
2008-11-24 01:34:56 +00:00
ath_printtxbuf(sc, bf, sc->sc_bhalq, 0,
Change the descriptor logic to use bf_lastds to point to the last descriptor, rather than using the maths involving bf_desc[bf_nseg - 1]. When doing TX aggregation, the status will be updated in the -final- descriptor of the -final- subframe in an aggregate. Thus bf_lastds may point to the last descriptor in a completely different ath_buf. Sponsored by: Hobnob, Inc.
2011-11-08 21:25:36 +00:00
ath_hal_txprocdesc(ah, bf->bf_lastds,
Track v0.9.20.3 hal: o no more ds_vdata in tx/rx descriptors o split h/w tx/rx descriptor from s/w status o as part of the descriptor split change the rate control module api so the ath_buf is passed in to the module so it can fetch both descriptor and status information as needed o add some const poisoning Also for sample rate control algorithm: o split debug msgs (node, rate, any) o uniformly bounds check rate indices (and in some cases correct checks) o move array index ops to after bounds checking o use final tsi from the status block instead of the h/w descriptor o replace h/w descriptor struct's with proper mask+shift defs (this doesn't belong here; everything is known by the driver and should just be sent down so there's no h/w-specific knowledge) MFC after: 1 month
2006-12-13 19:34:35 +00:00
&bf->bf_status.ds_txstat) == HAL_OK);
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
ieee80211_dump_pkt(&sc->sc_ic,
don't use caddr_t to match ieee80211_dump_pkt type; supplying the correct one costs nothing
2009-04-13 20:58:47 +00:00
mtod(bf->bf_m, const uint8_t *), bf->bf_m->m_len,
0, -1);
Improve ath_draintxq debug info: dump the packet as well as the descriptor and handle the beacon q like other q's MFC after: 1 month
2006-04-16 18:24:27 +00:00
}
}
#endif /* ATH_DEBUG */
replace if_watchdog w/ private callout; probably can merge this with the calibration work sometime in the future
2009-03-09 23:10:19 +00:00
sc->sc_wd_timer = 0;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
Correct spelling of reseting (found while researching the "bb hang detected" messages that are plaguing me). While I'm here, delete trailing whitespace.
2010-02-19 18:23:45 +00:00
/*
Update with last year of work.
2004-12-08 17:34:36 +00:00
* Update internal state after a channel change.
*/
static void
ath_chan_change(struct ath_softc *sc, struct ieee80211_channel *chan)
{
enum ieee80211_phymode mode;
/*
* Change channels and update the h/w rate map
* if we're switching; e.g. 11a to 11b/g.
*/
remove private support for IEEE80211_MODE_HALF and IEEE80211_MODE_QUARTER now that net80211 has them
2009-02-19 05:22:40 +00:00
mode = ieee80211_chan2mode(chan);
Update with last year of work.
2004-12-08 17:34:36 +00:00
if (mode != sc->sc_curmode)
ath_setcurmode(sc, mode);
Overhaul regulatory support: o remove HAL_CHANNEL; convert the hal to use net80211 channels; this mostly involves mechanical changes to variable names and channel attribute macros o gut HAL_CHANNEL_PRIVATE as most of the contents are now redundant with the net80211 channel available o change api for ath_hal_init_channels: no more reglass id's, no more outdoor indication (was a noop), anM contents o add ath_hal_getchannels to have the hal construct a channel list without altering runtime state; this is used to retrieve the calibration list for the device in ath_getradiocaps o add ath_hal_set_channels to take a channel list and regulatory data from above and construct internal state to match (maps frequencies for 900MHz cards, setup for CTL lookups, etc) o compact the private channel table: we keep one private channel per frequency instead of one per HAL_CHANNEL; this gives a big space savings and potentially improves ani and calibration by sharing state (to be seen; didn't see anything in testing); a new config option AH_MAXCHAN controls the table size (default to 96 which was chosen to be ~3x the largest expected size) o shrink ani state and change to mirror private channel table (one entry per frequency indexed by ic_devdata) o move ani state flags to private channel state o remove country codes; use net80211 definitions instead o remove GSM regulatory support; it's no longer needed now that we pass in channel lists from above o consolidate ADHOC_NO_11A attribute with DISALLOW_ADHOC_11A o simplify initial channel list construction based on the EEPROM contents; we preserve country code support for now but may want to just fallback to a WWR sku and dispatch the discovered country code up to user space so the channel list can be constructed using the master regdomain tables o defer to net80211 for max antenna gain o eliminate sorting of internal channel table; now that we use ic_devdata as an index, table lookups are O(1) o remove internal copy of the country code; the public one is sufficient o remove AH_SUPPORT_11D conditional compilation; we always support 11d o remove ath_hal_ispublicsafetysku; not needed any more o remove ath_hal_isgsmsku; no more GSM stuff o move Conformance Test Limit (CTL) state from private channel to a lookup using per-band pointers cached in the private state block o remove regulatory class id support; was unused and belongs in net80211 o fix channel list construction to set IEEE80211_CHAN_NOADHOC, IEEE80211_CHAN_NOHOSTAP, and IEEE80211_CHAN_4MSXMIT o remove private channel flags CHANNEL_DFS and CHANNEL_4MS_LIMIT; these are now set in the constructed net80211 channel o store CHANNEL_NFCREQUIRED (Noise Floor Required) channel attribute in one of the driver-private flag bits of the net80211 channel o move 900MHz frequency mapping into the hal; the mapped frequency is stored in the private channel and used throughout the hal (no more mapping in the driver and/or net80211) o remove ath_hal_mhz2ieee; it's no longer needed as net80211 does the calculation and available in the net80211 channel o change noise floor calibration logic to work with compacted private channel table setup; this may require revisiting as we no longer can distinguish channel attributes (e.g. 11b vs 11g vs turbo) but since the data is used only to calculate status data we can live with it for now o change ah_getChipPowerLimits internal method to operate on a single channel instead of all channels in the private channel table o add ath_hal_gethwchannel to map a net80211 channel to a h/w frequency (always the same except for 900MHz channels) o add HAL_EEBADREG and HAL_EEBADCC status codes to better identify regulatory problems o remove CTRY_DEBUG and CTRY_DEFAULT enum's; these come from net80211 now o change ath_hal_getwirelessmodes to really return wireless modes supported by the hardware (was previously applying regulatory constraints) o return channel interference status with IEEE80211_CHANSTATE_CWINT (should change to a callback so hal api's can take const pointers) o remove some #define's no longer needed with the inclusion of <net80211/_ieee80211.h> Sponsored by: Carlson Wireless
2009-01-28 18:00:22 +00:00
sc->sc_curchan = chan;
Update with last year of work.
2004-12-08 17:34:36 +00:00
}
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
/*
* Set/change channels. If the channel is really being changed,
Correct spelling of reseting (found while researching the "bb hang detected" messages that are plaguing me). While I'm here, delete trailing whitespace.
2010-02-19 18:23:45 +00:00
* it's done by resetting the chip. To accomplish this we must
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
* first cleanup any pending DMA, then restart stuff after a la
* ath_init.
*/
static int
ath_chan_set(struct ath_softc *sc, struct ieee80211_channel *chan)
{
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
struct ieee80211com *ic = &sc->sc_ic;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
struct ath_hal *ah = sc->sc_ah;
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
int ret = 0;
/* Treat this as an interface reset */
Attempt to further fix some of the concurrency/reset issues that occur. * ath_reset() is being called in softclock context, which may have the thing sleep on a lock. To avoid this, since we really _shouldn't_ be sleeping on any locks, break out the no-loss reset path into a tasklet and call that from: + ath_calibrate() + ath_watchdog() This has the added advantage that it'll end up also doing the frame RX cleanup from within the taskqueue context, rather than the softclock context. * Shuffle around the taskqueue_block() call to be before we grab the lock and disable interrupts. The trouble here is that taskqueue_block() doesn't block currently queued (but not yet running) tasks so calling it doesn't guarantee no further tasks (that weren't running on _A_ CPU at the time of this call) will complete. Calling taskqueue_drain() on these tasks won't work because if any _other_ thread calls taskqueue_enqueue() for whatever reason, everything gets very angry and stops working. This slightly changes the race condition enough to let ath_rx_tasklet() run before we try disabling it, and thus quietens the warnings a bit. The (more) true solution will be doing something like the following: * having a taskqueue_blocked mask in ath_softc; * having an interrupt_blocked mask in ath_softc; * only calling taskqueue_drain() on each individual task _after_ the lock has been acquired - that way no further tasklet scheduling is going to occur. * Then once the tasks have been blocked _and_ the interrupt has been disabled, call taskqueue_drain() on each, ensuring that anything that _was_ scheduled or running is removed. The trouble is if something calls taskqueue_enqueue() on a task after taskqueue_blocked() has been called but BEFORE taskqueue_drain() has been called, ta_pending will be set to 1 and taskqueue_drain() will sit there stuck in msleep() until you hard-kill the machine. PR: kern/165382 PR: kern/165220
2012-02-25 19:12:54 +00:00
ATH_PCU_UNLOCK_ASSERT(sc);
ATH_UNLOCK_ASSERT(sc);
dev/ath: minor spelling fixes in comments. No functional change. Reviewed by: adrian
2016-05-02 19:56:48 +00:00
/* (Try to) stop TX/RX from occurring */
Attempt to further fix some of the concurrency/reset issues that occur. * ath_reset() is being called in softclock context, which may have the thing sleep on a lock. To avoid this, since we really _shouldn't_ be sleeping on any locks, break out the no-loss reset path into a tasklet and call that from: + ath_calibrate() + ath_watchdog() This has the added advantage that it'll end up also doing the frame RX cleanup from within the taskqueue context, rather than the softclock context. * Shuffle around the taskqueue_block() call to be before we grab the lock and disable interrupts. The trouble here is that taskqueue_block() doesn't block currently queued (but not yet running) tasks so calling it doesn't guarantee no further tasks (that weren't running on _A_ CPU at the time of this call) will complete. Calling taskqueue_drain() on these tasks won't work because if any _other_ thread calls taskqueue_enqueue() for whatever reason, everything gets very angry and stops working. This slightly changes the race condition enough to let ath_rx_tasklet() run before we try disabling it, and thus quietens the warnings a bit. The (more) true solution will be doing something like the following: * having a taskqueue_blocked mask in ath_softc; * having an interrupt_blocked mask in ath_softc; * only calling taskqueue_drain() on each individual task _after_ the lock has been acquired - that way no further tasklet scheduling is going to occur. * Then once the tasks have been blocked _and_ the interrupt has been disabled, call taskqueue_drain() on each, ensuring that anything that _was_ scheduled or running is removed. The trouble is if something calls taskqueue_enqueue() on a task after taskqueue_blocked() has been called but BEFORE taskqueue_drain() has been called, ta_pending will be set to 1 and taskqueue_drain() will sit there stuck in msleep() until you hard-kill the machine. PR: kern/165382 PR: kern/165220
2012-02-25 19:12:54 +00:00
taskqueue_block(sc->sc_tq);
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
ATH_PCU_LOCK(sc);
Fix the order of TX shutdown and reset. * Grab the reset lock first, so any subsequent interrupt, TX, RX work will fail * Then shut down interrupts * Then wait for TX/RX to finish running At this point no further work will be running, so it's safe to do the reset path code. PR: kern/179232
2013-06-03 19:39:37 +00:00
Fix up the EDMA RX setup path to correctly initialise and reset the RX FIFO. The original code was .. well, slightly more than incorrect. It showed up as stalled RX queues if the NIC needed to be frequently reinitialised (eg during scans.) This is inspired by work done by Matt Dillon over at the DragonflyBSD project. So: * track when EDMA RX has been stopped and when the MAC has been reset; * re-initialise the ring only after a reset; * track whether RX has been stopped/started - just for debugging now; * don't bother with the RX EOL stuff for EDMA - we don't need the interrupt at all. We also don't need to disable/enable the interrupt or start DMA - once new frames are pushed into the ring via the normal RX path, it'll just restart RX DMA on its own. Tested: * AR9380, STA mode * AR9380, AP mode * AR9485, STA mode * AR9462, STA mode
2014-09-20 01:22:17 +00:00
/* Disable interrupts */
ath_hal_intrset(ah, 0);
Fix the order of TX shutdown and reset. * Grab the reset lock first, so any subsequent interrupt, TX, RX work will fail * Then shut down interrupts * Then wait for TX/RX to finish running At this point no further work will be running, so it's safe to do the reset path code. PR: kern/179232
2013-06-03 19:39:37 +00:00
/* Stop new RX/TX/interrupt completion */
Rework this ugly mess that tries to handle reset serialisation. Some users were reporting concurrent resets _were_ occuring - ie, either two ath_reset()s ran at the same time (likely one on each CPU) or ath_reset() versus ath_chan_change(). Instead, this now tries to grab the serialisation semaphore and will pause() for a while if it fails. It will always eventually succeed though and will log an error if it hits the recursion situation. All of this stuff needs to die a horrible death at some point and be replaced with a properly serialising method of programming this stuff (eg using the net80211 taskqueue for all of this stuff.) The trouble is figuring out how to handle the concurrent ioctl() based things without introducing more LORs (which is another reason why I haven't just wrapped all of this stuff in large, long-lived locks, a-la what Linux can get away with.) MFC after: Absolutely, positively never.
2011-12-23 03:59:49 +00:00
if (ath_reset_grablock(sc, 1) == 0) {
device_printf(sc->sc_dev, "%s: concurrent reset! Danger!\n",
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
__func__);
Rework this ugly mess that tries to handle reset serialisation. Some users were reporting concurrent resets _were_ occuring - ie, either two ath_reset()s ran at the same time (likely one on each CPU) or ath_reset() versus ath_chan_change(). Instead, this now tries to grab the serialisation semaphore and will pause() for a while if it fails. It will always eventually succeed though and will log an error if it hits the recursion situation. All of this stuff needs to die a horrible death at some point and be replaced with a properly serialising method of programming this stuff (eg using the net80211 taskqueue for all of this stuff.) The trouble is figuring out how to handle the concurrent ioctl() based things without introducing more LORs (which is another reason why I haven't just wrapped all of this stuff in large, long-lived locks, a-la what Linux can get away with.) MFC after: Absolutely, positively never.
2011-12-23 03:59:49 +00:00
}
Fix the order of TX shutdown and reset. * Grab the reset lock first, so any subsequent interrupt, TX, RX work will fail * Then shut down interrupts * Then wait for TX/RX to finish running At this point no further work will be running, so it's safe to do the reset path code. PR: kern/179232
2013-06-03 19:39:37 +00:00
/* Stop pending RX/TX completion */
ath_txrx_stop_locked(sc);
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
ATH_PCU_UNLOCK(sc);
Update with last year of work.
2004-12-08 17:34:36 +00:00
Overhaul regulatory support: o remove HAL_CHANNEL; convert the hal to use net80211 channels; this mostly involves mechanical changes to variable names and channel attribute macros o gut HAL_CHANNEL_PRIVATE as most of the contents are now redundant with the net80211 channel available o change api for ath_hal_init_channels: no more reglass id's, no more outdoor indication (was a noop), anM contents o add ath_hal_getchannels to have the hal construct a channel list without altering runtime state; this is used to retrieve the calibration list for the device in ath_getradiocaps o add ath_hal_set_channels to take a channel list and regulatory data from above and construct internal state to match (maps frequencies for 900MHz cards, setup for CTL lookups, etc) o compact the private channel table: we keep one private channel per frequency instead of one per HAL_CHANNEL; this gives a big space savings and potentially improves ani and calibration by sharing state (to be seen; didn't see anything in testing); a new config option AH_MAXCHAN controls the table size (default to 96 which was chosen to be ~3x the largest expected size) o shrink ani state and change to mirror private channel table (one entry per frequency indexed by ic_devdata) o move ani state flags to private channel state o remove country codes; use net80211 definitions instead o remove GSM regulatory support; it's no longer needed now that we pass in channel lists from above o consolidate ADHOC_NO_11A attribute with DISALLOW_ADHOC_11A o simplify initial channel list construction based on the EEPROM contents; we preserve country code support for now but may want to just fallback to a WWR sku and dispatch the discovered country code up to user space so the channel list can be constructed using the master regdomain tables o defer to net80211 for max antenna gain o eliminate sorting of internal channel table; now that we use ic_devdata as an index, table lookups are O(1) o remove internal copy of the country code; the public one is sufficient o remove AH_SUPPORT_11D conditional compilation; we always support 11d o remove ath_hal_ispublicsafetysku; not needed any more o remove ath_hal_isgsmsku; no more GSM stuff o move Conformance Test Limit (CTL) state from private channel to a lookup using per-band pointers cached in the private state block o remove regulatory class id support; was unused and belongs in net80211 o fix channel list construction to set IEEE80211_CHAN_NOADHOC, IEEE80211_CHAN_NOHOSTAP, and IEEE80211_CHAN_4MSXMIT o remove private channel flags CHANNEL_DFS and CHANNEL_4MS_LIMIT; these are now set in the constructed net80211 channel o store CHANNEL_NFCREQUIRED (Noise Floor Required) channel attribute in one of the driver-private flag bits of the net80211 channel o move 900MHz frequency mapping into the hal; the mapped frequency is stored in the private channel and used throughout the hal (no more mapping in the driver and/or net80211) o remove ath_hal_mhz2ieee; it's no longer needed as net80211 does the calculation and available in the net80211 channel o change noise floor calibration logic to work with compacted private channel table setup; this may require revisiting as we no longer can distinguish channel attributes (e.g. 11b vs 11g vs turbo) but since the data is used only to calculate status data we can live with it for now o change ah_getChipPowerLimits internal method to operate on a single channel instead of all channels in the private channel table o add ath_hal_gethwchannel to map a net80211 channel to a h/w frequency (always the same except for 900MHz channels) o add HAL_EEBADREG and HAL_EEBADCC status codes to better identify regulatory problems o remove CTRY_DEBUG and CTRY_DEFAULT enum's; these come from net80211 now o change ath_hal_getwirelessmodes to really return wireless modes supported by the hardware (was previously applying regulatory constraints) o return channel interference status with IEEE80211_CHANSTATE_CWINT (should change to a callback so hal api's can take const pointers) o remove some #define's no longer needed with the inclusion of <net80211/_ieee80211.h> Sponsored by: Carlson Wireless
2009-01-28 18:00:22 +00:00
DPRINTF(sc, ATH_DEBUG_RESET, "%s: %u (%u MHz, flags 0x%x)\n",
__func__, ieee80211_chan2ieee(ic, chan),
chan->ic_freq, chan->ic_flags);
if (chan != sc->sc_curchan) {
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
HAL_STATUS status;
/*
* To switch channels clear any pending DMA operations;
* wait long enough for the RX fifo to drain, reset the
* hardware at the new frequency, and then re-enable
* the relevant bits of the h/w.
*/
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
#if 0
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
ath_hal_intrset(ah, 0); /* disable interrupts */
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
#endif
Begin breaking apart the receive setup/stop path in preparation for more "correct" handling of frames in the RX pending queue during interface transitions. * ath_stoprecv() doesn't blank out the descriptor list - that's what ath_startrecv() does. So, change a comment to reflect that. * ath_stoprecv() does include a large (3ms) delay to let pending DMA complete. However, I'm under the impression that the stopdma hal method does check for a bit in the PCU to indicate DMA has stopped. So, to help with fast abort and restart, modify ath_stoprecv() to take a flag which indicates whether this is needed. * Modify the uses of ath_stoprecv() to pass in a flag to support the existing behaviour (ie, do the delay.) * Remove some duplicate PCU teardown code (which wasn't shutting down DMA, so it wasn't entirely correct..) and replace it with a call to ath_stoprecv(sc, 0) - which disables the DELAY call. The upshoot of this is now channel change doesn't simply drop completed frames on the floor, but instead it cleanly handles those frames. It still discards pending TX frames in the software and hardware queues as there's no (current) logic which forcibly recalculates the rate control information (or whether they're appropriate to be on the TX queue after a channel change), that'll come later. This still doesn't stop all the sources of queue stalls but it does tidy up some of the code duplication. To be complete, queue stalls now occur during normal behaviour - they only occur after some kind of broken behaviour causes an interface or node flush, upsetting the TX/RX BAW. Subsequent commits will incrementally fix these and other related issues. Sponsored by: Hobnob, Inc.
2011-11-19 21:05:31 +00:00
ath_stoprecv(sc, 1); /* turn off frame recv */
/*
* First, handle completed TX/RX frames.
*/
Begin abstracting out the RX path in preparation for RX EDMA support. The RX EDMA support requires a modified approach to the RX descriptor handling. Specifically: * There's now two RX queues - high and low priority; * The RX queues are implemented as FIFOs; they're now an array of pointers to buffers; * .. and the RX buffer and descriptor are in the same "buffer", rather than being separate. So to that end, this commit abstracts out most of the RX related functions from the bulk of the driver. Notably, the RX DMA/buffer allocation isn't updated, primarily because I haven't yet fleshed out what it should look like. Whilst I'm here, create a set of matching but mostly unimplemented EDMA stubs. Tested: * AR9280, station mode TODO: * Thorough AP and other mode testing for non-EDMA chips; * Figure out how to allocate RX buffers suitable for RX EDMA, including correctly setting the mbuf length to compensate for the RX descriptor and completion status area.
2012-07-03 06:59:12 +00:00
ath_rx_flush(sc);
Begin breaking apart the receive setup/stop path in preparation for more "correct" handling of frames in the RX pending queue during interface transitions. * ath_stoprecv() doesn't blank out the descriptor list - that's what ath_startrecv() does. So, change a comment to reflect that. * ath_stoprecv() does include a large (3ms) delay to let pending DMA complete. However, I'm under the impression that the stopdma hal method does check for a bit in the PCU to indicate DMA has stopped. So, to help with fast abort and restart, modify ath_stoprecv() to take a flag which indicates whether this is needed. * Modify the uses of ath_stoprecv() to pass in a flag to support the existing behaviour (ie, do the delay.) * Remove some duplicate PCU teardown code (which wasn't shutting down DMA, so it wasn't entirely correct..) and replace it with a call to ath_stoprecv(sc, 0) - which disables the DELAY call. The upshoot of this is now channel change doesn't simply drop completed frames on the floor, but instead it cleanly handles those frames. It still discards pending TX frames in the software and hardware queues as there's no (current) logic which forcibly recalculates the rate control information (or whether they're appropriate to be on the TX queue after a channel change), that'll come later. This still doesn't stop all the sources of queue stalls but it does tidy up some of the code duplication. To be complete, queue stalls now occur during normal behaviour - they only occur after some kind of broken behaviour causes an interface or node flush, upsetting the TX/RX BAW. Subsequent commits will incrementally fix these and other related issues. Sponsored by: Hobnob, Inc.
2011-11-19 21:05:31 +00:00
ath_draintxq(sc, ATH_RESET_NOLOSS);
/*
* Next, flush the non-scheduled frames.
*/
Add KTR tracepoints to the ath driver, in order to debug TX, RX and interrupt handling. Sponsored by: Hobnob, Inc.
2011-11-08 19:02:59 +00:00
ath_draintxq(sc, ATH_RESET_FULL); /* clear pending tx frames */
Begin breaking apart the receive setup/stop path in preparation for more "correct" handling of frames in the RX pending queue during interface transitions. * ath_stoprecv() doesn't blank out the descriptor list - that's what ath_startrecv() does. So, change a comment to reflect that. * ath_stoprecv() does include a large (3ms) delay to let pending DMA complete. However, I'm under the impression that the stopdma hal method does check for a bit in the PCU to indicate DMA has stopped. So, to help with fast abort and restart, modify ath_stoprecv() to take a flag which indicates whether this is needed. * Modify the uses of ath_stoprecv() to pass in a flag to support the existing behaviour (ie, do the delay.) * Remove some duplicate PCU teardown code (which wasn't shutting down DMA, so it wasn't entirely correct..) and replace it with a call to ath_stoprecv(sc, 0) - which disables the DELAY call. The upshoot of this is now channel change doesn't simply drop completed frames on the floor, but instead it cleanly handles those frames. It still discards pending TX frames in the software and hardware queues as there's no (current) logic which forcibly recalculates the rate control information (or whether they're appropriate to be on the TX queue after a channel change), that'll come later. This still doesn't stop all the sources of queue stalls but it does tidy up some of the code duplication. To be complete, queue stalls now occur during normal behaviour - they only occur after some kind of broken behaviour causes an interface or node flush, upsetting the TX/RX BAW. Subsequent commits will incrementally fix these and other related issues. Sponsored by: Hobnob, Inc.
2011-11-19 21:05:31 +00:00
Part #2 of the TX chainmask changes: * Remove ar5416UpdateChainmasks(); * Remove the TX chainmask override code from the ar5416 TX descriptor setup routines; * Write a driver method to calculate the current chainmask based on the operating mode and update the driver state; * Call the HAL chainmask method before calling ath_hal_reset(); * Use the currently configured chainmask in the TX descriptors rather than the hardware TX chainmasks. Tested: * AR5416, STA/AP mode - legacy and 11n modes
2013-02-25 22:45:02 +00:00
ath_update_chainmasks(sc, chan);
ath_hal_setchainmasks(sc->sc_ah, sc->sc_cur_txchainmask,
sc->sc_cur_rxchainmask);
ath(4): begin fleshing out a "reset type" extension to force cold/warn resets. Right now the only way to force a cold reset is: * The HAL itself detects it's needed, or * The sysctl, setting all resets to be cold. Trouble is, cold resets take quite a bit longer than warm resets. However, there are situations where a cold reset would be nice. Specifically, after a stuck beacon, BB/MAC hang, stuck calibration results, etc. The vendor HAL has a separate method to set the reset reason (which is how HAL_RESET_BBPANIC gets set) which informs the HAL during the reset path why it occured. This is almost but not quite the same; I may eventually unify both approaches in the future. This commit just extends HAL_RESET_TYPE to include both status (eg BBPANIC) and type (eg do COLD.) None of the HAL code uses it yet though; that'll come later. It also is a big no-op in each HAL - I need to go teach each of the HALs about cold/warm reset through this path.
2015-11-09 15:59:42 +00:00
if (!ath_hal_reset(ah, sc->sc_opmode, chan, AH_TRUE,
HAL_RESET_NORMAL, &status)) {
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
device_printf(sc->sc_dev, "%s: unable to reset "
Spell "Hz" correctly wherever it is user-visible. PR: bin/142566 Submitted by: N.J. Mann njm njm.me.uk Approved by: ed (mentor) MFC after: 2 weeks
2010-01-12 17:59:58 +00:00
"channel %u (%u MHz, flags 0x%x), hal status %u\n",
Overhaul regulatory support: o remove HAL_CHANNEL; convert the hal to use net80211 channels; this mostly involves mechanical changes to variable names and channel attribute macros o gut HAL_CHANNEL_PRIVATE as most of the contents are now redundant with the net80211 channel available o change api for ath_hal_init_channels: no more reglass id's, no more outdoor indication (was a noop), anM contents o add ath_hal_getchannels to have the hal construct a channel list without altering runtime state; this is used to retrieve the calibration list for the device in ath_getradiocaps o add ath_hal_set_channels to take a channel list and regulatory data from above and construct internal state to match (maps frequencies for 900MHz cards, setup for CTL lookups, etc) o compact the private channel table: we keep one private channel per frequency instead of one per HAL_CHANNEL; this gives a big space savings and potentially improves ani and calibration by sharing state (to be seen; didn't see anything in testing); a new config option AH_MAXCHAN controls the table size (default to 96 which was chosen to be ~3x the largest expected size) o shrink ani state and change to mirror private channel table (one entry per frequency indexed by ic_devdata) o move ani state flags to private channel state o remove country codes; use net80211 definitions instead o remove GSM regulatory support; it's no longer needed now that we pass in channel lists from above o consolidate ADHOC_NO_11A attribute with DISALLOW_ADHOC_11A o simplify initial channel list construction based on the EEPROM contents; we preserve country code support for now but may want to just fallback to a WWR sku and dispatch the discovered country code up to user space so the channel list can be constructed using the master regdomain tables o defer to net80211 for max antenna gain o eliminate sorting of internal channel table; now that we use ic_devdata as an index, table lookups are O(1) o remove internal copy of the country code; the public one is sufficient o remove AH_SUPPORT_11D conditional compilation; we always support 11d o remove ath_hal_ispublicsafetysku; not needed any more o remove ath_hal_isgsmsku; no more GSM stuff o move Conformance Test Limit (CTL) state from private channel to a lookup using per-band pointers cached in the private state block o remove regulatory class id support; was unused and belongs in net80211 o fix channel list construction to set IEEE80211_CHAN_NOADHOC, IEEE80211_CHAN_NOHOSTAP, and IEEE80211_CHAN_4MSXMIT o remove private channel flags CHANNEL_DFS and CHANNEL_4MS_LIMIT; these are now set in the constructed net80211 channel o store CHANNEL_NFCREQUIRED (Noise Floor Required) channel attribute in one of the driver-private flag bits of the net80211 channel o move 900MHz frequency mapping into the hal; the mapped frequency is stored in the private channel and used throughout the hal (no more mapping in the driver and/or net80211) o remove ath_hal_mhz2ieee; it's no longer needed as net80211 does the calculation and available in the net80211 channel o change noise floor calibration logic to work with compacted private channel table setup; this may require revisiting as we no longer can distinguish channel attributes (e.g. 11b vs 11g vs turbo) but since the data is used only to calculate status data we can live with it for now o change ah_getChipPowerLimits internal method to operate on a single channel instead of all channels in the private channel table o add ath_hal_gethwchannel to map a net80211 channel to a h/w frequency (always the same except for 900MHz channels) o add HAL_EEBADREG and HAL_EEBADCC status codes to better identify regulatory problems o remove CTRY_DEBUG and CTRY_DEFAULT enum's; these come from net80211 now o change ath_hal_getwirelessmodes to really return wireless modes supported by the hardware (was previously applying regulatory constraints) o return channel interference status with IEEE80211_CHANSTATE_CWINT (should change to a callback so hal api's can take const pointers) o remove some #define's no longer needed with the inclusion of <net80211/_ieee80211.h> Sponsored by: Carlson Wireless
2009-01-28 18:00:22 +00:00
__func__, ieee80211_chan2ieee(ic, chan),
chan->ic_freq, chan->ic_flags, status);
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
ret = EIO;
goto finish;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
o fix setup of sc_diversity; the hal does not give us reliable status after attach, only after a reset o when setting diversity via the sysctl don't update sc_diversity until we know the hal requested worked o while here eliminate sc_hasdiversity and sc_hastpc; just query the hal each time since these are the only places we need to know MFC after: 3 days
2005-07-24 05:11:39 +00:00
sc->sc_diversity = ath_hal_getdiversity(ah);
Update with last year of work.
2004-12-08 17:34:36 +00:00
Fix up the EDMA RX setup path to correctly initialise and reset the RX FIFO. The original code was .. well, slightly more than incorrect. It showed up as stalled RX queues if the NIC needed to be frequently reinitialised (eg during scans.) This is inspired by work done by Matt Dillon over at the DragonflyBSD project. So: * track when EDMA RX has been stopped and when the MAC has been reset; * re-initialise the ring only after a reset; * track whether RX has been stopped/started - just for debugging now; * don't bother with the RX EOL stuff for EDMA - we don't need the interrupt at all. We also don't need to disable/enable the interrupt or start DMA - once new frames are pushed into the ring via the normal RX path, it'll just restart RX DMA on its own. Tested: * AR9380, STA mode * AR9380, AP mode * AR9485, STA mode * AR9462, STA mode
2014-09-20 01:22:17 +00:00
ATH_RX_LOCK(sc);
sc->sc_rx_stopped = 1;
sc->sc_rx_resetted = 1;
ATH_RX_UNLOCK(sc);
[ath] initial station side quiet IE support. This implements hardware assisted quiet IE support. Quiet time is an optional interval on DFS channels (but doesn't have to be DFS only channels! sigh) where the station and AP can be quiet in order to allow for channel utilisation measurements. Typically that's stuff like radar detection, spectral scan, other-BSS frame sniffing, checking how busy the air is, etc. The hardware implements it as one of the generic timers, which is supplied a period, offset from the trigger period and duration to stay quiet. The AP can announce quiet time configurations which change, and so this code also tracks that. Implementation details: * track the current quiet time IE * compare the new one against the previous one - if only the TBTT counter changes, don't update things * If tbttcount=1 then program it into the hardware - that is when it is easiest to program the correct starting offset (one TBTT + configured offset). * .. later on check to see if it can be done on any tbttcount * If the IE goes away then remove the quiet timer and clear the config * Upon reset, state change, new beacon - clear quiet time IE and just let it resync from the next beacon. History: This was work done initially by sibridgetech.com in 2011/2012/2013 as part of some FreeBSD wifi DFS contracting work they had for a third party. They implemented the net80211 quiet time IE pieces and had some test code for the station side which didn't entirely use the timers correctly. I figured out how to use the timers correctly without stopping/starting the transmit DMA engine each time. When done correctly, the timer just needs to be programmed once and left alone until the next configuration change. So, thanks to Himali Patel and Parthiv Shah for their work way back then. I finally figured it out and finished it! TODO: * Now, I'd rather net80211 did the quiet time IE tracking and parsing, pushing configurations into the driver is needed. I'll look at doing that in a subsequent update. * This doesn't handle multiple quiet time IEs, which will currently just mess things up. I'll look into supporting that in the future (at least by only obeying "one" of them, and then ignoring subsequent IEs in a beacon/probe frame.) * This also implements the STA side and not the AP side - the AP side will come later, and involves taking various other intervals into account (eg the beacon offset for multi-VAP modes, the SWBA time, etc, etc) as well as obtaining the configuration when a beacon is configured/generated rather than "hearing" an IE. * .. investigate supporting quiet IE in mesh, tdma, ibss modes * .. investigate supporting quiet IE for non-DFS channels (so this can be done for say, 2GHz channels.) * Chances are i should commit NULL methods for the ar5210, ar5211 HALs.. Tested: * AR9380, STA mode - announcing quiet, removing quiet, changing quite time config, whilst doing iperf testing; * AR9380, AP mode.
2017-02-09 23:15:11 +00:00
/* Quiet time handling - ensure we resync */
ath_vap_clear_quiet_ie(sc);
Flesh out the radar detection related operations for the ath driver. This is in no way a complete DFS/radar detection implementation! It merely creates an abstracted interface which allows for future development of the DFS radar detection code. Note: Net80211 already handles the bulk of the DFS machinery, all we need to do here is figure out that a radar event has occured and inform it as such. It then drives the DFS state engine for us. The "null" DFS radar detection module is included by default; it doesn't require a device line. This commit: * Adds a simple abstracted layer for radar detection state - sys/dev/ath/ath_dfs/; * Implements a null DFS module which doesn't do anything; (ie, implements the exact behaviour at the moment); * Adds hooks to the ath driver to process received radar events and gives the DFS module a chance to determine whether a radar has been detected. Obtained from: Atheros
2011-06-01 20:09:49 +00:00
/* Let DFS at it in case it's a DFS channel */
Use the passed-in channel rather than ic->ic_curchan. I'm not sure _why_ the ic is NULL here, but I've seen it occasionally do this after I've been tinkering with things for a while. It ends up crashing in a call to ath_chan_set() via the net80211 scan code and scan task.
2012-02-23 08:32:54 +00:00
ath_dfs_radar_enable(sc, chan);
Flesh out the radar detection related operations for the ath driver. This is in no way a complete DFS/radar detection implementation! It merely creates an abstracted interface which allows for future development of the DFS radar detection code. Note: Net80211 already handles the bulk of the DFS machinery, all we need to do here is figure out that a radar event has occured and inform it as such. It then drives the DFS state engine for us. The "null" DFS radar detection module is included by default; it doesn't require a device line. This commit: * Adds a simple abstracted layer for radar detection state - sys/dev/ath/ath_dfs/; * Implements a null DFS module which doesn't do anything; (ie, implements the exact behaviour at the moment); * Adds hooks to the ath driver to process received radar events and gives the DFS module a chance to determine whether a radar has been detected. Obtained from: Atheros
2011-06-01 20:09:49 +00:00
Add a new (skeleton) spectral mode manager module.
2013-01-02 03:59:02 +00:00
/* Let spectral at in case spectral is enabled */
ath_spectral_enable(sc, chan);
Bring over the initial static bluetooth coexistence configuration for the WB195 combo NIC - an AR9285 w/ an AR3011 USB bluetooth NIC. The AR3011 is wired up using a 3-wire coexistence scheme to the AR9285. The code in if_ath_btcoex.c sets up the initial hardware mapping and coexistence configuration. There's nothing special about it - it's static; it doesn't try to configure bluetooth / MAC traffic priorities or try to figure out what's actually going on. It's enough to stop basic bluetooth traffic from causing traffic stalls and diassociation from the wireless network. To use this code, you must have the above NIC. No, it won't work for the AR9287+AR3012, nor the AR9485, AR9462 or AR955x combo cards. Then you set a kernel hint before boot or before kldload, where 'X' is the unit number of your AR9285 NIC: # kenv hint.ath.X.btcoex_profile=wb195 This will then appear in your boot messages: [100482] athX: Enabling WB195 BTCOEX This code is going to evolve pretty quickly (well, depending upon my spare time) so don't assume the btcoex API is going to stay stable. In order to use the bluetooth side, you must also load in firmware using ath3kfw and the binary firmware file (ath3k-1.fw in my case.) Tested: * AR9280, no interference * WB195 - AR9285 + AR3011 combo; STA mode; basic bluetooth inquiries were enough to cause traffic stalls and disassociations. This has stopped with the btcoex profile code. TODO: * Importantly - the AR9285 needs ASPM disabled if bluetooth coexistence is enabled. No, I don't know why. It's likely some kind of bug to do with the AR3011 sending bluetooth coexistence signals whilst the device is asleep. Since we don't actually sleep the MAC just yet, it shouldn't be a problem. That said, to be totally correct: + ASPM should be disabled - upon attach and wakeup + The PCIe powersave HAL code should never be called Look at what the ath9k driver does for inspiration. * Add WB197 (AR9287+AR3012) support * Add support for the AR9485, which is another combo like the AR9285 * The later NICs have a different signaling mechanism between the MAC and the bluetooth device; I haven't even begun to experiment with making that HAL code work. But it should be a lot more automatic. * The hardware can do much more interesting traffic weighting with bluetooth and wifi traffic. None of this is currently used. Ideally someone would code up something to watch the bluetooth traffic GPIO (via an interrupt) and then watch it go high/low; then figure out what the bluetooth traffic is and adjust things appropriately. * If I get the time I may add in some code to at least track this stuff and expose statistics. But it's up to someone else to experiment with the bluetooth coexistence support and add the interesting stuff (like "real" detection of bulk, audio, etc bluetooth traffic patterns and change wifi parameters appropriately - eg, maximum aggregate length, transmit power, using quiet time to control TX duty cycle, etc.)
2013-06-07 09:02:02 +00:00
/*
* Let bluetooth coexistence at in case it's needed for this
* channel
*/
ath_btcoex_enable(sc, ic->ic_curchan);
Enable the use of TDMA on an 802.11n channel (with aggregation disabled, of course.) There's a few things that needed to happen: * In case someone decides to set the beacon transmission rate to be at an MCS rate, use the MCS-aware version of the duration calculation to figure out how long the received beacon frame was. * If TxOP enforcing is available on the hardware and we're doing TDMA, enable it after a reset and set the TDMA guard interval to zero. This seems to behave fine. TODO: * Although I haven't yet seen packet loss, the PHY errors that would be triggered (specifically Transmit-Override-Receive) aren't enabled by the 11n HAL. I'll have to do some work to enable these PHY errors for debugging. What broke: * My recent changes to the TX queue handling has resulted in the driver not keeping the hardware queue properly filled when doing non-aggregate traffic. I have a patch to commit soon which fixes this situation (albeit by reminding me about how my ath driver locking isn't working out, sigh.) So if you want to test this without updating to the next set of patches that I commit, just bump the sysctl dev.ath.X.hwq_limit from 2 to 32. Tested: * AR5416 <-> AR5416, with ampdu disabled, HT40, 5GHz, MCS12+Short-GI. I saw 30mbit/sec in both directions using a bidirectional UDP test.
2013-05-21 18:02:54 +00:00
/*
* If we're doing TDMA, enforce the TXOP limitation for chips
* that support it.
*/
if (sc->sc_hasenforcetxop && sc->sc_tdma)
ath_hal_setenforcetxop(sc->sc_ah, 1);
else
ath_hal_setenforcetxop(sc->sc_ah, 0);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
/*
* Re-enable rx framework.
*/
if (ath_startrecv(sc) != 0) {
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
device_printf(sc->sc_dev,
"%s: unable to restart recv logic\n", __func__);
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
ret = EIO;
goto finish;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
/*
* Change channels and update the h/w rate map
* if we're switching; e.g. 11a to 11b/g.
*/
Update with last year of work.
2004-12-08 17:34:36 +00:00
ath_chan_change(sc, chan);
MFp4 changes to fix locking issues and correct reference count handling of station entries in hostap mode: Input path: o driver is now expected to find the node associated with the sender of a received frame; use ic_bss if none is located o driver passes the (referenced) node into ieee80211_input for use within the wlan module and is responsible for cleaning up on return o the antenna state is no longer passed up with each frame; this is now considered driver-private state and drivers are responsible for keeping it in the driver-private part of a node Output path: Revamp output path for management frames to eliminate redundant locking that causes problems and to correct reference counting bogosity that occurs when stations are timed out due to inactivity (in AP mode). On output the refcnt'd node is stashed in the pkthdr's recvif field (yech) and retrieved by the driver. This eliminates an unref/ref scenario and related node table unlock/lock due to the driver looking up the node. This is particularly important when stations are timed out as this causes a lock order reversal that can result in a deadlock. As a byproduct we also reduce the overhead for sending management frames (minimal). Additional fallout from this is a change to ieee80211_encap to return a refcn't node for tieing to the outbound frame. Node refcnts are not reclaimed until after a frame is completely processed (e.g. in the tx interrupt handler). This is especially important for timed out stations as this deref will be the final one causing the node entry to be reclaimed. Additional semi-related changes: o replace m_copym use with m_copypacket (optimization) o add assert to verify ic_bss is never free'd during normal operation o add comments explaining calling conventions by drivers for frames going in each direction o remove extraneous code that "cannot be executed" (e.g. because pointers may never be null)
2003-08-19 22:17:04 +00:00
Fix beacon transmission after a channel set. The DFS code was tickling the channel set directly whilst going through the state RUN -> CSA -> RUN. This only changed the channel; it didn't go via ath_reset(). However in this driver, a channel change always causes a chip reset, which resets the beacon timer configuration and interrupt setup. This meant that data would go out but as the beacon timers never fired, beacons would never be queued. The confusing part is that sometimes the state transition was RUN -> SCAN -> CAC -> RUN (with CSA being in there sometimes); going via SCAN would clear sc_beacons and thus the transition to RUN would reprogram beacon transmission. In case someone tries debugging why suspending a device currently beaconing (versus just RX'ing beacons which is what occurs in STA mode), add a silly comment which should hopefully land them at this commit message. The call to ath_hal_reset() will be clearing the beacon config and it may not be always reset.
2011-06-26 13:53:24 +00:00
/*
* Reset clears the beacon timers; reset them
* here if needed.
*/
if (sc->sc_beacons) { /* restart beacons */
#ifdef IEEE80211_SUPPORT_TDMA
if (sc->sc_tdma)
ath_tdma_config(sc, NULL);
else
#endif
ath_beacon_config(sc, NULL);
}
MFp4 changes to fix locking issues and correct reference count handling of station entries in hostap mode: Input path: o driver is now expected to find the node associated with the sender of a received frame; use ic_bss if none is located o driver passes the (referenced) node into ieee80211_input for use within the wlan module and is responsible for cleaning up on return o the antenna state is no longer passed up with each frame; this is now considered driver-private state and drivers are responsible for keeping it in the driver-private part of a node Output path: Revamp output path for management frames to eliminate redundant locking that causes problems and to correct reference counting bogosity that occurs when stations are timed out due to inactivity (in AP mode). On output the refcnt'd node is stashed in the pkthdr's recvif field (yech) and retrieved by the driver. This eliminates an unref/ref scenario and related node table unlock/lock due to the driver looking up the node. This is particularly important when stations are timed out as this causes a lock order reversal that can result in a deadlock. As a byproduct we also reduce the overhead for sending management frames (minimal). Additional fallout from this is a change to ieee80211_encap to return a refcn't node for tieing to the outbound frame. Node refcnts are not reclaimed until after a frame is completely processed (e.g. in the tx interrupt handler). This is especially important for timed out stations as this deref will be the final one causing the node entry to be reclaimed. Additional semi-related changes: o replace m_copym use with m_copypacket (optimization) o add assert to verify ic_bss is never free'd during normal operation o add comments explaining calling conventions by drivers for frames going in each direction o remove extraneous code that "cannot be executed" (e.g. because pointers may never be null)
2003-08-19 22:17:04 +00:00
/*
* Re-enable interrupts.
*/
Enforce some consistent ordering and handling of interrupt disable/enable with RX/TX halting. * Always disable/enable interrupts during a channel change, just to simply things. * Ensure that the ath taskqueue has completed and is paused before continuing. This dramatically reduces the instances of overlapping RX and reset conditions. PR: kern/165220
2012-02-17 03:46:38 +00:00
#if 0
MFp4 changes to fix locking issues and correct reference count handling of station entries in hostap mode: Input path: o driver is now expected to find the node associated with the sender of a received frame; use ic_bss if none is located o driver passes the (referenced) node into ieee80211_input for use within the wlan module and is responsible for cleaning up on return o the antenna state is no longer passed up with each frame; this is now considered driver-private state and drivers are responsible for keeping it in the driver-private part of a node Output path: Revamp output path for management frames to eliminate redundant locking that causes problems and to correct reference counting bogosity that occurs when stations are timed out due to inactivity (in AP mode). On output the refcnt'd node is stashed in the pkthdr's recvif field (yech) and retrieved by the driver. This eliminates an unref/ref scenario and related node table unlock/lock due to the driver looking up the node. This is particularly important when stations are timed out as this causes a lock order reversal that can result in a deadlock. As a byproduct we also reduce the overhead for sending management frames (minimal). Additional fallout from this is a change to ieee80211_encap to return a refcn't node for tieing to the outbound frame. Node refcnts are not reclaimed until after a frame is completely processed (e.g. in the tx interrupt handler). This is especially important for timed out stations as this deref will be the final one causing the node entry to be reclaimed. Additional semi-related changes: o replace m_copym use with m_copypacket (optimization) o add assert to verify ic_bss is never free'd during normal operation o add comments explaining calling conventions by drivers for frames going in each direction o remove extraneous code that "cannot be executed" (e.g. because pointers may never be null)
2003-08-19 22:17:04 +00:00
ath_hal_intrset(ah, sc->sc_imask);
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
#endif
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
finish:
ATH_PCU_LOCK(sc);
sc->sc_inreset_cnt--;
/* XXX only do this if sc_inreset_cnt == 0? */
Enforce some consistent ordering and handling of interrupt disable/enable with RX/TX halting. * Always disable/enable interrupts during a channel change, just to simply things. * Ensure that the ath taskqueue has completed and is paused before continuing. This dramatically reduces the instances of overlapping RX and reset conditions. PR: kern/165220
2012-02-17 03:46:38 +00:00
ath_hal_intrset(ah, sc->sc_imask);
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
ATH_PCU_UNLOCK(sc);
ath_txrx_start(sc);
/* XXX ath_start? */
return ret;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
/*
* Periodically recalibrate the PHY to account
* for temperature/environment changes.
*/
static void
ath_calibrate(void *arg)
{
struct ath_softc *sc = arg;
struct ath_hal *ah = sc->sc_ah;
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
struct ieee80211com *ic = &sc->sc_ic;
Initialise an uninitialised variable.
2012-10-05 16:44:00 +00:00
HAL_BOOL longCal, isCalDone = AH_TRUE;
ANI changes #1 - split out the ANI polling from the RxMonitor hook. The rxmonitor hook is called on each received packet. This can get very, very busy as the tx/rx/chanbusy registers are thus read each time a packet is received. Instead, shuffle out the true per-packet processing which is needed and move the rest of the ANI processing into a periodic event which runs every 100ms by default.
2011-01-21 05:21:00 +00:00
HAL_BOOL aniCal, shortCal = AH_FALSE;
New periodic calibration scheme needed for 11n parts that have multiple algorithms and potentially collect multiple samples. Instead of a single calibration interval we now have short and long intervals; the long interval roughly corresponds to the previous single interval. The short interval is used to speedup collection of samples and happens much quicker. We make calls using the short interval until we're told the calibration work is complete at which point we fallback to the long interval. In addition there is a much longer reset interval used to flush all calibration state and cause everthing to start anew. With these changes you can also disable calibration entirely by setting the long interval to zero.
2008-12-07 19:26:34 +00:00
int nextcal;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
Convert the callouts back to using mutexes. I did this wrong - I should've included a state flag for each callout to see if it was supposed to run or not. I didn't do that. Instead, just use mutexes anyway. Suggested by: jhb
2014-11-15 01:18:49 +00:00
ATH_LOCK_ASSERT(sc);
Migrate the callouts from using mutex locks to being mpsafe with the locks being held by the callers. Kill callout_drain() and use callout_stop().
2014-11-14 04:26:26 +00:00
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
/*
* Force the hardware awake for ANI work.
*/
ath_power_set_power_state(sc, HAL_PM_AWAKE);
/* Skip trying to do this if we're in reset */
if (sc->sc_inreset_cnt)
goto restart;
don't run the calibration code if scanning, we won't be on the home channel
2009-01-23 03:15:28 +00:00
if (ic->ic_flags & IEEE80211_F_SCAN) /* defer, off channel */
goto restart;
New periodic calibration scheme needed for 11n parts that have multiple algorithms and potentially collect multiple samples. Instead of a single calibration interval we now have short and long intervals; the long interval roughly corresponds to the previous single interval. The short interval is used to speedup collection of samples and happens much quicker. We make calls using the short interval until we're told the calibration work is complete at which point we fallback to the long interval. In addition there is a much longer reset interval used to flush all calibration state and cause everthing to start anew. With these changes you can also disable calibration entirely by setting the long interval to zero.
2008-12-07 19:26:34 +00:00
longCal = (ticks - sc->sc_lastlongcal >= ath_longcalinterval*hz);
ANI changes #1 - split out the ANI polling from the RxMonitor hook. The rxmonitor hook is called on each received packet. This can get very, very busy as the tx/rx/chanbusy registers are thus read each time a packet is received. Instead, shuffle out the true per-packet processing which is needed and move the rest of the ANI processing into a periodic event which runs every 100ms by default.
2011-01-21 05:21:00 +00:00
aniCal = (ticks - sc->sc_lastani >= ath_anicalinterval*hz/1000);
if (sc->sc_doresetcal)
shortCal = (ticks - sc->sc_lastshortcal >= ath_shortcalinterval*hz/1000);
DPRINTF(sc, ATH_DEBUG_CALIBRATE, "%s: shortCal=%d; longCal=%d; aniCal=%d\n", __func__, shortCal, longCal, aniCal);
if (aniCal) {
sc->sc_stats.ast_ani_cal++;
sc->sc_lastani = ticks;
ath_hal_ani_poll(ah, sc->sc_curchan);
}
New periodic calibration scheme needed for 11n parts that have multiple algorithms and potentially collect multiple samples. Instead of a single calibration interval we now have short and long intervals; the long interval roughly corresponds to the previous single interval. The short interval is used to speedup collection of samples and happens much quicker. We make calls using the short interval until we're told the calibration work is complete at which point we fallback to the long interval. In addition there is a much longer reset interval used to flush all calibration state and cause everthing to start anew. With these changes you can also disable calibration entirely by setting the long interval to zero.
2008-12-07 19:26:34 +00:00
if (longCal) {
sc->sc_stats.ast_per_cal++;
Don't delay updating the longcal timer - instead, update the longcal flag immediately so it's only set once per longcal interval. Without this, the current AR5416 code will continuously spam NF calibrations during a periodic calibration if the longcal flag is set. The longcal flag wouldn't be cleared until the calibration method indicates that calibrations are "complete". This drops the rate of NF calibration updates down from "once every shortcal" (ie, every 100ms) during a periodic calibration, to only once per "longcal" interval. Spamming NF calibrations every 100ms caused some potentially horrific issues in noisy environments as NF calibrations can take longer than 100ms and this spamming can cause invalid NF calibration results to be read back - leading to missed beacons, and thus leading to a stuck beacon situation. Stuck beacons cause interface resets, which restart calibrations. This means that the longcal calibration runs every 100ms (shortcal) until all initial calibrations are completed. This spamming can then cause the above issues which leads to stuck beacons, leading to interface resets, etc, etc. Quite annoying.
2010-08-10 07:56:56 +00:00
sc->sc_lastlongcal = ticks;
New periodic calibration scheme needed for 11n parts that have multiple algorithms and potentially collect multiple samples. Instead of a single calibration interval we now have short and long intervals; the long interval roughly corresponds to the previous single interval. The short interval is used to speedup collection of samples and happens much quicker. We make calls using the short interval until we're told the calibration work is complete at which point we fallback to the long interval. In addition there is a much longer reset interval used to flush all calibration state and cause everthing to start anew. With these changes you can also disable calibration entirely by setting the long interval to zero.
2008-12-07 19:26:34 +00:00
if (ath_hal_getrfgain(ah) == HAL_RFGAIN_NEED_CHANGE) {
/*
* Rfgain is out of bounds, reset the chip
* to load new gain values.
*/
DPRINTF(sc, ATH_DEBUG_CALIBRATE,
"%s: rfgain change\n", __func__);
sc->sc_stats.ast_per_rfgain++;
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
sc->sc_resetcal = 0;
sc->sc_doresetcal = AH_TRUE;
Attempt to further fix some of the concurrency/reset issues that occur. * ath_reset() is being called in softclock context, which may have the thing sleep on a lock. To avoid this, since we really _shouldn't_ be sleeping on any locks, break out the no-loss reset path into a tasklet and call that from: + ath_calibrate() + ath_watchdog() This has the added advantage that it'll end up also doing the frame RX cleanup from within the taskqueue context, rather than the softclock context. * Shuffle around the taskqueue_block() call to be before we grab the lock and disable interrupts. The trouble here is that taskqueue_block() doesn't block currently queued (but not yet running) tasks so calling it doesn't guarantee no further tasks (that weren't running on _A_ CPU at the time of this call) will complete. Calling taskqueue_drain() on these tasks won't work because if any _other_ thread calls taskqueue_enqueue() for whatever reason, everything gets very angry and stops working. This slightly changes the race condition enough to let ath_rx_tasklet() run before we try disabling it, and thus quietens the warnings a bit. The (more) true solution will be doing something like the following: * having a taskqueue_blocked mask in ath_softc; * having an interrupt_blocked mask in ath_softc; * only calling taskqueue_drain() on each individual task _after_ the lock has been acquired - that way no further tasklet scheduling is going to occur. * Then once the tasks have been blocked _and_ the interrupt has been disabled, call taskqueue_drain() on each, ensuring that anything that _was_ scheduled or running is removed. The trouble is if something calls taskqueue_enqueue() on a task after taskqueue_blocked() has been called but BEFORE taskqueue_drain() has been called, ta_pending will be set to 1 and taskqueue_drain() will sit there stuck in msleep() until you hard-kill the machine. PR: kern/165382 PR: kern/165220
2012-02-25 19:12:54 +00:00
taskqueue_enqueue(sc->sc_tq, &sc->sc_resettask);
callout_reset(&sc->sc_cal_ch, 1, ath_calibrate, sc);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ath_power_restore_power_state(sc);
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
return;
New periodic calibration scheme needed for 11n parts that have multiple algorithms and potentially collect multiple samples. Instead of a single calibration interval we now have short and long intervals; the long interval roughly corresponds to the previous single interval. The short interval is used to speedup collection of samples and happens much quicker. We make calls using the short interval until we're told the calibration work is complete at which point we fallback to the long interval. In addition there is a much longer reset interval used to flush all calibration state and cause everthing to start anew. With these changes you can also disable calibration entirely by setting the long interval to zero.
2008-12-07 19:26:34 +00:00
}
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
/*
New periodic calibration scheme needed for 11n parts that have multiple algorithms and potentially collect multiple samples. Instead of a single calibration interval we now have short and long intervals; the long interval roughly corresponds to the previous single interval. The short interval is used to speedup collection of samples and happens much quicker. We make calls using the short interval until we're told the calibration work is complete at which point we fallback to the long interval. In addition there is a much longer reset interval used to flush all calibration state and cause everthing to start anew. With these changes you can also disable calibration entirely by setting the long interval to zero.
2008-12-07 19:26:34 +00:00
* If this long cal is after an idle period, then
* reset the data collection state so we start fresh.
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
*/
New periodic calibration scheme needed for 11n parts that have multiple algorithms and potentially collect multiple samples. Instead of a single calibration interval we now have short and long intervals; the long interval roughly corresponds to the previous single interval. The short interval is used to speedup collection of samples and happens much quicker. We make calls using the short interval until we're told the calibration work is complete at which point we fallback to the long interval. In addition there is a much longer reset interval used to flush all calibration state and cause everthing to start anew. With these changes you can also disable calibration entirely by setting the long interval to zero.
2008-12-07 19:26:34 +00:00
if (sc->sc_resetcal) {
Overhaul regulatory support: o remove HAL_CHANNEL; convert the hal to use net80211 channels; this mostly involves mechanical changes to variable names and channel attribute macros o gut HAL_CHANNEL_PRIVATE as most of the contents are now redundant with the net80211 channel available o change api for ath_hal_init_channels: no more reglass id's, no more outdoor indication (was a noop), anM contents o add ath_hal_getchannels to have the hal construct a channel list without altering runtime state; this is used to retrieve the calibration list for the device in ath_getradiocaps o add ath_hal_set_channels to take a channel list and regulatory data from above and construct internal state to match (maps frequencies for 900MHz cards, setup for CTL lookups, etc) o compact the private channel table: we keep one private channel per frequency instead of one per HAL_CHANNEL; this gives a big space savings and potentially improves ani and calibration by sharing state (to be seen; didn't see anything in testing); a new config option AH_MAXCHAN controls the table size (default to 96 which was chosen to be ~3x the largest expected size) o shrink ani state and change to mirror private channel table (one entry per frequency indexed by ic_devdata) o move ani state flags to private channel state o remove country codes; use net80211 definitions instead o remove GSM regulatory support; it's no longer needed now that we pass in channel lists from above o consolidate ADHOC_NO_11A attribute with DISALLOW_ADHOC_11A o simplify initial channel list construction based on the EEPROM contents; we preserve country code support for now but may want to just fallback to a WWR sku and dispatch the discovered country code up to user space so the channel list can be constructed using the master regdomain tables o defer to net80211 for max antenna gain o eliminate sorting of internal channel table; now that we use ic_devdata as an index, table lookups are O(1) o remove internal copy of the country code; the public one is sufficient o remove AH_SUPPORT_11D conditional compilation; we always support 11d o remove ath_hal_ispublicsafetysku; not needed any more o remove ath_hal_isgsmsku; no more GSM stuff o move Conformance Test Limit (CTL) state from private channel to a lookup using per-band pointers cached in the private state block o remove regulatory class id support; was unused and belongs in net80211 o fix channel list construction to set IEEE80211_CHAN_NOADHOC, IEEE80211_CHAN_NOHOSTAP, and IEEE80211_CHAN_4MSXMIT o remove private channel flags CHANNEL_DFS and CHANNEL_4MS_LIMIT; these are now set in the constructed net80211 channel o store CHANNEL_NFCREQUIRED (Noise Floor Required) channel attribute in one of the driver-private flag bits of the net80211 channel o move 900MHz frequency mapping into the hal; the mapped frequency is stored in the private channel and used throughout the hal (no more mapping in the driver and/or net80211) o remove ath_hal_mhz2ieee; it's no longer needed as net80211 does the calculation and available in the net80211 channel o change noise floor calibration logic to work with compacted private channel table setup; this may require revisiting as we no longer can distinguish channel attributes (e.g. 11b vs 11g vs turbo) but since the data is used only to calculate status data we can live with it for now o change ah_getChipPowerLimits internal method to operate on a single channel instead of all channels in the private channel table o add ath_hal_gethwchannel to map a net80211 channel to a h/w frequency (always the same except for 900MHz channels) o add HAL_EEBADREG and HAL_EEBADCC status codes to better identify regulatory problems o remove CTRY_DEBUG and CTRY_DEFAULT enum's; these come from net80211 now o change ath_hal_getwirelessmodes to really return wireless modes supported by the hardware (was previously applying regulatory constraints) o return channel interference status with IEEE80211_CHANSTATE_CWINT (should change to a callback so hal api's can take const pointers) o remove some #define's no longer needed with the inclusion of <net80211/_ieee80211.h> Sponsored by: Carlson Wireless
2009-01-28 18:00:22 +00:00
(void) ath_hal_calreset(ah, sc->sc_curchan);
New periodic calibration scheme needed for 11n parts that have multiple algorithms and potentially collect multiple samples. Instead of a single calibration interval we now have short and long intervals; the long interval roughly corresponds to the previous single interval. The short interval is used to speedup collection of samples and happens much quicker. We make calls using the short interval until we're told the calibration work is complete at which point we fallback to the long interval. In addition there is a much longer reset interval used to flush all calibration state and cause everthing to start anew. With these changes you can also disable calibration entirely by setting the long interval to zero.
2008-12-07 19:26:34 +00:00
sc->sc_lastcalreset = ticks;
ANI changes #1 - split out the ANI polling from the RxMonitor hook. The rxmonitor hook is called on each received packet. This can get very, very busy as the tx/rx/chanbusy registers are thus read each time a packet is received. Instead, shuffle out the true per-packet processing which is needed and move the rest of the ANI processing into a periodic event which runs every 100ms by default.
2011-01-21 05:21:00 +00:00
sc->sc_lastshortcal = ticks;
New periodic calibration scheme needed for 11n parts that have multiple algorithms and potentially collect multiple samples. Instead of a single calibration interval we now have short and long intervals; the long interval roughly corresponds to the previous single interval. The short interval is used to speedup collection of samples and happens much quicker. We make calls using the short interval until we're told the calibration work is complete at which point we fallback to the long interval. In addition there is a much longer reset interval used to flush all calibration state and cause everthing to start anew. With these changes you can also disable calibration entirely by setting the long interval to zero.
2008-12-07 19:26:34 +00:00
sc->sc_resetcal = 0;
ANI changes #1 - split out the ANI polling from the RxMonitor hook. The rxmonitor hook is called on each received packet. This can get very, very busy as the tx/rx/chanbusy registers are thus read each time a packet is received. Instead, shuffle out the true per-packet processing which is needed and move the rest of the ANI processing into a periodic event which runs every 100ms by default.
2011-01-21 05:21:00 +00:00
sc->sc_doresetcal = AH_TRUE;
New periodic calibration scheme needed for 11n parts that have multiple algorithms and potentially collect multiple samples. Instead of a single calibration interval we now have short and long intervals; the long interval roughly corresponds to the previous single interval. The short interval is used to speedup collection of samples and happens much quicker. We make calls using the short interval until we're told the calibration work is complete at which point we fallback to the long interval. In addition there is a much longer reset interval used to flush all calibration state and cause everthing to start anew. With these changes you can also disable calibration entirely by setting the long interval to zero.
2008-12-07 19:26:34 +00:00
}
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
ANI changes #1 - split out the ANI polling from the RxMonitor hook. The rxmonitor hook is called on each received packet. This can get very, very busy as the tx/rx/chanbusy registers are thus read each time a packet is received. Instead, shuffle out the true per-packet processing which is needed and move the rest of the ANI processing into a periodic event which runs every 100ms by default.
2011-01-21 05:21:00 +00:00
/* Only call if we're doing a short/long cal, not for ANI calibration */
if (shortCal || longCal) {
Initialise an uninitialised variable.
2012-10-05 16:44:00 +00:00
isCalDone = AH_FALSE;
ANI changes #1 - split out the ANI polling from the RxMonitor hook. The rxmonitor hook is called on each received packet. This can get very, very busy as the tx/rx/chanbusy registers are thus read each time a packet is received. Instead, shuffle out the true per-packet processing which is needed and move the rest of the ANI processing into a periodic event which runs every 100ms by default.
2011-01-21 05:21:00 +00:00
if (ath_hal_calibrateN(ah, sc->sc_curchan, longCal, &isCalDone)) {
if (longCal) {
/*
* Calibrate noise floor data again in case of change.
*/
ath_hal_process_noisefloor(ah);
}
} else {
DPRINTF(sc, ATH_DEBUG_ANY,
"%s: calibration of channel %u failed\n",
__func__, sc->sc_curchan->ic_freq);
sc->sc_stats.ast_per_calfail++;
New periodic calibration scheme needed for 11n parts that have multiple algorithms and potentially collect multiple samples. Instead of a single calibration interval we now have short and long intervals; the long interval roughly corresponds to the previous single interval. The short interval is used to speedup collection of samples and happens much quicker. We make calls using the short interval until we're told the calibration work is complete at which point we fallback to the long interval. In addition there is a much longer reset interval used to flush all calibration state and cause everthing to start anew. With these changes you can also disable calibration entirely by setting the long interval to zero.
2008-12-07 19:26:34 +00:00
}
[ath] [ath_rate] Fix ANI calibration during non-ACTIVE states; start poking at rate control These are some fun issues I've found with my upstairs wifi link at such a ridiculous low signal level (like, < 5dB.) * Add per-station tx/rx rssi statistics, in potential preparation to use that in the RX rate control. * Call the rate control on each received frame to let it potentially use it as a hint for what rates to potentially use. It's a no-op right now. * Do ANI calibration during scan as well. The ath_newstate() call was disabling the ANI timer and only re-enabling it during transitions to _RUN. This has the unfortunate side-effect that if ANI deafened the NIC because of interference and it disassociated, it wouldn't be reset and the scan would never hear beacons. The ANI configuration is stored at least globally on some HALs and per-channel on others. Because of this a NIC reset wouldn't help; the ANI parameters would simply be programmed back in. Now, I have a feeling I also need to do this during AUTH/ASSOC too and maybe, if I'm feeling clever, I need to reset the ANI parameters on a given channel during a transition through INIT or if the VAP is destroyed/re-created. However for now this gets me out of the immediate weeds with connectivity upstairs (and thus I /can/ commit); I'll keep chipping away at tidying this stuff up in subsequent commits. Tested: * AR9344 (Wasp), 2G STA mode
2019-05-05 04:56:37 +00:00
/*
* XXX TODO: get the NF calibration results from the HAL.
* If we failed NF cal then schedule a hard reset to potentially
* un-freeze the PHY.
*
* Note we have to be careful here to not get stuck in an
* infinite NIC restart. Ideally we'd not restart if we
* failed the first NF cal - that /can/ fail sometimes in
* a noisy environment.
*/
ANI changes #1 - split out the ANI polling from the RxMonitor hook. The rxmonitor hook is called on each received packet. This can get very, very busy as the tx/rx/chanbusy registers are thus read each time a packet is received. Instead, shuffle out the true per-packet processing which is needed and move the rest of the ANI processing into a periodic event which runs every 100ms by default.
2011-01-21 05:21:00 +00:00
if (shortCal)
sc->sc_lastshortcal = ticks;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
New periodic calibration scheme needed for 11n parts that have multiple algorithms and potentially collect multiple samples. Instead of a single calibration interval we now have short and long intervals; the long interval roughly corresponds to the previous single interval. The short interval is used to speedup collection of samples and happens much quicker. We make calls using the short interval until we're told the calibration work is complete at which point we fallback to the long interval. In addition there is a much longer reset interval used to flush all calibration state and cause everthing to start anew. With these changes you can also disable calibration entirely by setting the long interval to zero.
2008-12-07 19:26:34 +00:00
if (!isCalDone) {
don't run the calibration code if scanning, we won't be on the home channel
2009-01-23 03:15:28 +00:00
restart:
New periodic calibration scheme needed for 11n parts that have multiple algorithms and potentially collect multiple samples. Instead of a single calibration interval we now have short and long intervals; the long interval roughly corresponds to the previous single interval. The short interval is used to speedup collection of samples and happens much quicker. We make calls using the short interval until we're told the calibration work is complete at which point we fallback to the long interval. In addition there is a much longer reset interval used to flush all calibration state and cause everthing to start anew. With these changes you can also disable calibration entirely by setting the long interval to zero.
2008-12-07 19:26:34 +00:00
/*
* Use a shorter interval to potentially collect multiple
* data samples required to complete calibration. Once
* we're told the work is done we drop back to a longer
* interval between requests. We're more aggressive doing
* work when operating as an AP to improve operation right
* after startup.
*/
ANI changes #1 - split out the ANI polling from the RxMonitor hook. The rxmonitor hook is called on each received packet. This can get very, very busy as the tx/rx/chanbusy registers are thus read each time a packet is received. Instead, shuffle out the true per-packet processing which is needed and move the rest of the ANI processing into a periodic event which runs every 100ms by default.
2011-01-21 05:21:00 +00:00
sc->sc_lastshortcal = ticks;
nextcal = ath_shortcalinterval*hz/1000;
New periodic calibration scheme needed for 11n parts that have multiple algorithms and potentially collect multiple samples. Instead of a single calibration interval we now have short and long intervals; the long interval roughly corresponds to the previous single interval. The short interval is used to speedup collection of samples and happens much quicker. We make calls using the short interval until we're told the calibration work is complete at which point we fallback to the long interval. In addition there is a much longer reset interval used to flush all calibration state and cause everthing to start anew. With these changes you can also disable calibration entirely by setting the long interval to zero.
2008-12-07 19:26:34 +00:00
if (sc->sc_opmode != HAL_M_HOSTAP)
nextcal *= 10;
ANI changes #1 - split out the ANI polling from the RxMonitor hook. The rxmonitor hook is called on each received packet. This can get very, very busy as the tx/rx/chanbusy registers are thus read each time a packet is received. Instead, shuffle out the true per-packet processing which is needed and move the rest of the ANI processing into a periodic event which runs every 100ms by default.
2011-01-21 05:21:00 +00:00
sc->sc_doresetcal = AH_TRUE;
New periodic calibration scheme needed for 11n parts that have multiple algorithms and potentially collect multiple samples. Instead of a single calibration interval we now have short and long intervals; the long interval roughly corresponds to the previous single interval. The short interval is used to speedup collection of samples and happens much quicker. We make calls using the short interval until we're told the calibration work is complete at which point we fallback to the long interval. In addition there is a much longer reset interval used to flush all calibration state and cause everthing to start anew. With these changes you can also disable calibration entirely by setting the long interval to zero.
2008-12-07 19:26:34 +00:00
} else {
ANI changes #1 - split out the ANI polling from the RxMonitor hook. The rxmonitor hook is called on each received packet. This can get very, very busy as the tx/rx/chanbusy registers are thus read each time a packet is received. Instead, shuffle out the true per-packet processing which is needed and move the rest of the ANI processing into a periodic event which runs every 100ms by default.
2011-01-21 05:21:00 +00:00
/* nextcal should be the shortest time for next event */
New periodic calibration scheme needed for 11n parts that have multiple algorithms and potentially collect multiple samples. Instead of a single calibration interval we now have short and long intervals; the long interval roughly corresponds to the previous single interval. The short interval is used to speedup collection of samples and happens much quicker. We make calls using the short interval until we're told the calibration work is complete at which point we fallback to the long interval. In addition there is a much longer reset interval used to flush all calibration state and cause everthing to start anew. With these changes you can also disable calibration entirely by setting the long interval to zero.
2008-12-07 19:26:34 +00:00
nextcal = ath_longcalinterval*hz;
if (sc->sc_lastcalreset == 0)
sc->sc_lastcalreset = sc->sc_lastlongcal;
else if (ticks - sc->sc_lastcalreset >= ath_resetcalinterval*hz)
sc->sc_resetcal = 1; /* setup reset next trip */
ANI changes #1 - split out the ANI polling from the RxMonitor hook. The rxmonitor hook is called on each received packet. This can get very, very busy as the tx/rx/chanbusy registers are thus read each time a packet is received. Instead, shuffle out the true per-packet processing which is needed and move the rest of the ANI processing into a periodic event which runs every 100ms by default.
2011-01-21 05:21:00 +00:00
sc->sc_doresetcal = AH_FALSE;
New periodic calibration scheme needed for 11n parts that have multiple algorithms and potentially collect multiple samples. Instead of a single calibration interval we now have short and long intervals; the long interval roughly corresponds to the previous single interval. The short interval is used to speedup collection of samples and happens much quicker. We make calls using the short interval until we're told the calibration work is complete at which point we fallback to the long interval. In addition there is a much longer reset interval used to flush all calibration state and cause everthing to start anew. With these changes you can also disable calibration entirely by setting the long interval to zero.
2008-12-07 19:26:34 +00:00
}
ANI changes #1 - split out the ANI polling from the RxMonitor hook. The rxmonitor hook is called on each received packet. This can get very, very busy as the tx/rx/chanbusy registers are thus read each time a packet is received. Instead, shuffle out the true per-packet processing which is needed and move the rest of the ANI processing into a periodic event which runs every 100ms by default.
2011-01-21 05:21:00 +00:00
/* ANI calibration may occur more often than short/long/resetcal */
if (ath_anicalinterval > 0)
nextcal = MIN(nextcal, ath_anicalinterval*hz/1000);
New periodic calibration scheme needed for 11n parts that have multiple algorithms and potentially collect multiple samples. Instead of a single calibration interval we now have short and long intervals; the long interval roughly corresponds to the previous single interval. The short interval is used to speedup collection of samples and happens much quicker. We make calls using the short interval until we're told the calibration work is complete at which point we fallback to the long interval. In addition there is a much longer reset interval used to flush all calibration state and cause everthing to start anew. With these changes you can also disable calibration entirely by setting the long interval to zero.
2008-12-07 19:26:34 +00:00
if (nextcal != 0) {
DPRINTF(sc, ATH_DEBUG_CALIBRATE, "%s: next +%u (%sisCalDone)\n",
__func__, nextcal, isCalDone ? "" : "!");
callout_reset(&sc->sc_cal_ch, nextcal, ath_calibrate, sc);
} else {
DPRINTF(sc, ATH_DEBUG_CALIBRATE, "%s: calibration disabled\n",
__func__);
/* NB: don't rearm timer */
Update for rev 0.9.16.16 hal: o add dfs+radar hooks; DFS is presently disabled in the hal o channel and mode handling changes o various api changes o be more aggressive about iq calibration settling so ap mode operation is better immediately after startup o rfkill/rfsilent sysctl support o tpc ack/cts sysctl support MFC after: 2 weeks
2006-02-10 19:07:08 +00:00
}
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
/*
* Restore power state now that we're done.
*/
ath_power_restore_power_state(sc);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
static void
ath_scan_start(struct ieee80211com *ic)
{
Remove most of the references of ifp->if_softc and replace with references to ic->ic_softc. This is in preparation for gleb's ifnet work. Tested: * ath(4), STA mode * ath(4), hostap mode * make universe
2015-08-17 02:04:11 +00:00
struct ath_softc *sc = ic->ic_softc;
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
struct ath_hal *ah = sc->sc_ah;
u_int32_t rfilt;
/* XXX calibration timer? */
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
/* XXXGL: is constant ieee80211broadcastaddr a correct choice? */
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
Wrap the scan code state change stuff behind ATH_LOCK and the PCU fiddling behind the PCU lock. sc_scanning is being checked without ATH_LOCK behind held and could in theory run from multiple threads.
2012-03-02 02:57:10 +00:00
ATH_LOCK(sc);
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
sc->sc_scanning = 1;
sc->sc_syncbeacon = 0;
rfilt = ath_calcrxfilter(sc);
Wrap the scan code state change stuff behind ATH_LOCK and the PCU fiddling behind the PCU lock. sc_scanning is being checked without ATH_LOCK behind held and could in theory run from multiple threads.
2012-03-02 02:57:10 +00:00
ATH_UNLOCK(sc);
ATH_PCU_LOCK(sc);
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
ath_hal_setrxfilter(ah, rfilt);
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
ath_hal_setassocid(ah, ieee80211broadcastaddr, 0);
Wrap the scan code state change stuff behind ATH_LOCK and the PCU fiddling behind the PCU lock. sc_scanning is being checked without ATH_LOCK behind held and could in theory run from multiple threads.
2012-03-02 02:57:10 +00:00
ATH_PCU_UNLOCK(sc);
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
DPRINTF(sc, ATH_DEBUG_STATE, "%s: RX filter 0x%x bssid %s aid 0\n",
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
__func__, rfilt, ether_sprintf(ieee80211broadcastaddr));
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
}
static void
ath_scan_end(struct ieee80211com *ic)
{
Remove most of the references of ifp->if_softc and replace with references to ic->ic_softc. This is in preparation for gleb's ifnet work. Tested: * ath(4), STA mode * ath(4), hostap mode * make universe
2015-08-17 02:04:11 +00:00
struct ath_softc *sc = ic->ic_softc;
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
struct ath_hal *ah = sc->sc_ah;
u_int32_t rfilt;
Wrap the scan code state change stuff behind ATH_LOCK and the PCU fiddling behind the PCU lock. sc_scanning is being checked without ATH_LOCK behind held and could in theory run from multiple threads.
2012-03-02 02:57:10 +00:00
ATH_LOCK(sc);
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
sc->sc_scanning = 0;
rfilt = ath_calcrxfilter(sc);
Wrap the scan code state change stuff behind ATH_LOCK and the PCU fiddling behind the PCU lock. sc_scanning is being checked without ATH_LOCK behind held and could in theory run from multiple threads.
2012-03-02 02:57:10 +00:00
ATH_UNLOCK(sc);
ATH_PCU_LOCK(sc);
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
ath_hal_setrxfilter(ah, rfilt);
ath_hal_setassocid(ah, sc->sc_curbssid, sc->sc_curaid);
ath_hal_process_noisefloor(ah);
Wrap the scan code state change stuff behind ATH_LOCK and the PCU fiddling behind the PCU lock. sc_scanning is being checked without ATH_LOCK behind held and could in theory run from multiple threads.
2012-03-02 02:57:10 +00:00
ATH_PCU_UNLOCK(sc);
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
DPRINTF(sc, ATH_DEBUG_STATE, "%s: RX filter 0x%x bssid %s aid 0x%x\n",
__func__, rfilt, ether_sprintf(sc->sc_curbssid),
sc->sc_curaid);
}
* Since the API changed along the -CURRENT path (december 2011), add a FreeBSD_version check. It should work fine for compiling on -HEAD, 9.x and 8.x. * Conditionally compile the 11n options only when 11n is enabled. The above changes allow the ath(4) driver to compile and run on 8.1-RELEASE (Hi old PC-BSD!) but with the 11n stuff disabled. I've done a test against the net80211 and tools in 8.1-RELEASE. The NIC used in testing is the AR2427 in an EEEPC. Just to be clear - this change is to allow the -HEAD ath/hal/rate code to run on 9.x _and_ 8.x with no source changes. However, when running on earlier kernels, it should only be used for legacy mode. (Don't define ATH_ENABLE_11N.)
2012-04-10 06:25:11 +00:00
#ifdef ATH_ENABLE_11N
Add the new channel width change field to the ath(4) driver. This is not entirely correct as it simply resets the channel, flushing whatever is in the TX/RX queue. This can and will break aggregation BAW tracking. But the alternative (HT40 frames being sent with the hardware in HT20 mode) is even worse. There's still a small window between the htinfo being received (and the ni_chw field being updated) which could cause problems. I'll look at fleshing this out in follow-up commits. PR: kern/166286
2012-03-25 03:14:31 +00:00
/*
* For now, just do a channel change.
*
* Later, we'll go through the hard slog of suspending tx/rx, changing rate
* control state and resetting the hardware without dropping frames out
* of the queue.
*
* The unfortunate trouble here is making absolutely sure that the
* channel width change has propagated enough so the hardware
* absolutely isn't handed bogus frames for it's current operating
* mode. (Eg, 40MHz frames in 20MHz mode.) Since TX and RX can and
* does occur in parallel, we need to make certain we've blocked
* any further ongoing TX (and RX, that can cause raw TX)
* before we do this.
*/
static void
ath_update_chw(struct ieee80211com *ic)
{
Remove most of the references of ifp->if_softc and replace with references to ic->ic_softc. This is in preparation for gleb's ifnet work. Tested: * ath(4), STA mode * ath(4), hostap mode * make universe
2015-08-17 02:04:11 +00:00
struct ath_softc *sc = ic->ic_softc;
Add the new channel width change field to the ath(4) driver. This is not entirely correct as it simply resets the channel, flushing whatever is in the TX/RX queue. This can and will break aggregation BAW tracking. But the alternative (HT40 frames being sent with the hardware in HT20 mode) is even worse. There's still a small window between the htinfo being received (and the ni_chw field being updated) which could cause problems. I'll look at fleshing this out in follow-up commits. PR: kern/166286
2012-03-25 03:14:31 +00:00
[ath] initial station side quiet IE support. This implements hardware assisted quiet IE support. Quiet time is an optional interval on DFS channels (but doesn't have to be DFS only channels! sigh) where the station and AP can be quiet in order to allow for channel utilisation measurements. Typically that's stuff like radar detection, spectral scan, other-BSS frame sniffing, checking how busy the air is, etc. The hardware implements it as one of the generic timers, which is supplied a period, offset from the trigger period and duration to stay quiet. The AP can announce quiet time configurations which change, and so this code also tracks that. Implementation details: * track the current quiet time IE * compare the new one against the previous one - if only the TBTT counter changes, don't update things * If tbttcount=1 then program it into the hardware - that is when it is easiest to program the correct starting offset (one TBTT + configured offset). * .. later on check to see if it can be done on any tbttcount * If the IE goes away then remove the quiet timer and clear the config * Upon reset, state change, new beacon - clear quiet time IE and just let it resync from the next beacon. History: This was work done initially by sibridgetech.com in 2011/2012/2013 as part of some FreeBSD wifi DFS contracting work they had for a third party. They implemented the net80211 quiet time IE pieces and had some test code for the station side which didn't entirely use the timers correctly. I figured out how to use the timers correctly without stopping/starting the transmit DMA engine each time. When done correctly, the timer just needs to be programmed once and left alone until the next configuration change. So, thanks to Himali Patel and Parthiv Shah for their work way back then. I finally figured it out and finished it! TODO: * Now, I'd rather net80211 did the quiet time IE tracking and parsing, pushing configurations into the driver is needed. I'll look at doing that in a subsequent update. * This doesn't handle multiple quiet time IEs, which will currently just mess things up. I'll look into supporting that in the future (at least by only obeying "one" of them, and then ignoring subsequent IEs in a beacon/probe frame.) * This also implements the STA side and not the AP side - the AP side will come later, and involves taking various other intervals into account (eg the beacon offset for multi-VAP modes, the SWBA time, etc, etc) as well as obtaining the configuration when a beacon is configured/generated rather than "hearing" an IE. * .. investigate supporting quiet IE in mesh, tdma, ibss modes * .. investigate supporting quiet IE for non-DFS channels (so this can be done for say, 2GHz channels.) * Chances are i should commit NULL methods for the ar5210, ar5211 HALs.. Tested: * AR9380, STA mode - announcing quiet, removing quiet, changing quite time config, whilst doing iperf testing; * AR9380, AP mode.
2017-02-09 23:15:11 +00:00
//DPRINTF(sc, ATH_DEBUG_STATE, "%s: called\n", __func__);
device_printf(sc->sc_dev, "%s: called\n", __func__);
/*
* XXX TODO: schedule a tasklet that stops things without freeing,
* walks the now stopped TX queue(s) looking for frames to retry
* as if we TX filtered them (whch may mean dropping non-ampdu frames!)
* but okay) then place them back on the software queue so they
* can have the rate control lookup done again.
*/
Add the new channel width change field to the ath(4) driver. This is not entirely correct as it simply resets the channel, flushing whatever is in the TX/RX queue. This can and will break aggregation BAW tracking. But the alternative (HT40 frames being sent with the hardware in HT20 mode) is even worse. There's still a small window between the htinfo being received (and the ni_chw field being updated) which could cause problems. I'll look at fleshing this out in follow-up commits. PR: kern/166286
2012-03-25 03:14:31 +00:00
ath_set_channel(ic);
}
* Since the API changed along the -CURRENT path (december 2011), add a FreeBSD_version check. It should work fine for compiling on -HEAD, 9.x and 8.x. * Conditionally compile the 11n options only when 11n is enabled. The above changes allow the ath(4) driver to compile and run on 8.1-RELEASE (Hi old PC-BSD!) but with the 11n stuff disabled. I've done a test against the net80211 and tools in 8.1-RELEASE. The NIC used in testing is the AR2427 in an EEEPC. Just to be clear - this change is to allow the -HEAD ath/hal/rate code to run on 9.x _and_ 8.x with no source changes. However, when running on earlier kernels, it should only be used for legacy mode. (Don't define ATH_ENABLE_11N.)
2012-04-10 06:25:11 +00:00
#endif /* ATH_ENABLE_11N */
Add the new channel width change field to the ath(4) driver. This is not entirely correct as it simply resets the channel, flushing whatever is in the TX/RX queue. This can and will break aggregation BAW tracking. But the alternative (HT40 frames being sent with the hardware in HT20 mode) is even worse. There's still a small window between the htinfo being received (and the ni_chw field being updated) which could cause problems. I'll look at fleshing this out in follow-up commits. PR: kern/166286
2012-03-25 03:14:31 +00:00
[ath] initial station side quiet IE support. This implements hardware assisted quiet IE support. Quiet time is an optional interval on DFS channels (but doesn't have to be DFS only channels! sigh) where the station and AP can be quiet in order to allow for channel utilisation measurements. Typically that's stuff like radar detection, spectral scan, other-BSS frame sniffing, checking how busy the air is, etc. The hardware implements it as one of the generic timers, which is supplied a period, offset from the trigger period and duration to stay quiet. The AP can announce quiet time configurations which change, and so this code also tracks that. Implementation details: * track the current quiet time IE * compare the new one against the previous one - if only the TBTT counter changes, don't update things * If tbttcount=1 then program it into the hardware - that is when it is easiest to program the correct starting offset (one TBTT + configured offset). * .. later on check to see if it can be done on any tbttcount * If the IE goes away then remove the quiet timer and clear the config * Upon reset, state change, new beacon - clear quiet time IE and just let it resync from the next beacon. History: This was work done initially by sibridgetech.com in 2011/2012/2013 as part of some FreeBSD wifi DFS contracting work they had for a third party. They implemented the net80211 quiet time IE pieces and had some test code for the station side which didn't entirely use the timers correctly. I figured out how to use the timers correctly without stopping/starting the transmit DMA engine each time. When done correctly, the timer just needs to be programmed once and left alone until the next configuration change. So, thanks to Himali Patel and Parthiv Shah for their work way back then. I finally figured it out and finished it! TODO: * Now, I'd rather net80211 did the quiet time IE tracking and parsing, pushing configurations into the driver is needed. I'll look at doing that in a subsequent update. * This doesn't handle multiple quiet time IEs, which will currently just mess things up. I'll look into supporting that in the future (at least by only obeying "one" of them, and then ignoring subsequent IEs in a beacon/probe frame.) * This also implements the STA side and not the AP side - the AP side will come later, and involves taking various other intervals into account (eg the beacon offset for multi-VAP modes, the SWBA time, etc, etc) as well as obtaining the configuration when a beacon is configured/generated rather than "hearing" an IE. * .. investigate supporting quiet IE in mesh, tdma, ibss modes * .. investigate supporting quiet IE for non-DFS channels (so this can be done for say, 2GHz channels.) * Chances are i should commit NULL methods for the ar5210, ar5211 HALs.. Tested: * AR9380, STA mode - announcing quiet, removing quiet, changing quite time config, whilst doing iperf testing; * AR9380, AP mode.
2017-02-09 23:15:11 +00:00
/*
* This is called by the beacon parsing routine in the receive
* path to update the current quiet time information provided by
* an AP.
*
* This is STA specific, it doesn't take the AP TBTT/beacon slot
* offset into account.
*
* The quiet IE doesn't control the /now/ beacon interval - it
* controls the upcoming beacon interval. So, when tbtt=1,
* the quiet element programming shall be for the next beacon
* interval. There's no tbtt=0 behaviour defined, so don't.
*
* Since we're programming the next quiet interval, we have
* to keep in mind what we will see when the next beacon
* is received with potentially a quiet IE. For example, if
* quiet_period is 1, then we are always getting a quiet interval
* each TBTT - so if we just program it in upon each beacon received,
* it will constantly reflect the "next" TBTT and we will never
* let the counter stay programmed correctly.
*
* So:
* + the first time we see the quiet IE, program it and store
* the details somewhere;
* + if the quiet parameters don't change (ie, period/duration/offset)
* then just leave the programming enabled;
* + (we can "skip" beacons, so don't try to enforce tbttcount unless
* you're willing to also do the skipped beacon math);
* + if the quiet IE is removed, then halt quiet time.
*/
static int
ath_set_quiet_ie(struct ieee80211_node *ni, uint8_t *ie)
{
struct ieee80211_quiet_ie *q;
struct ieee80211vap *vap = ni->ni_vap;
struct ath_vap *avp = ATH_VAP(vap);
struct ieee80211com *ic = vap->iv_ic;
struct ath_softc *sc = ic->ic_softc;
if (vap->iv_opmode != IEEE80211_M_STA)
return (0);
/* Verify we have a quiet time IE */
if (ie == NULL) {
DPRINTF(sc, ATH_DEBUG_QUIETIE,
"%s: called; NULL IE, disabling\n", __func__);
ath_hal_set_quiet(sc->sc_ah, 0, 0, 0, HAL_QUIET_DISABLE);
memset(&avp->quiet_ie, 0, sizeof(avp->quiet_ie));
return (0);
}
/* If we do, verify it's actually legit */
if (ie[0] != IEEE80211_ELEMID_QUIET)
return 0;
if (ie[1] != 6)
return 0;
/* Note: this belongs in net80211, parsed out and everything */
q = (void *) ie;
/*
* Compare what we have stored to what we last saw.
* If they're the same then don't program in anything.
*/
if ((q->period == avp->quiet_ie.period) &&
(le16dec(&q->duration) == le16dec(&avp->quiet_ie.duration)) &&
(le16dec(&q->offset) == le16dec(&avp->quiet_ie.offset)))
return (0);
DPRINTF(sc, ATH_DEBUG_QUIETIE,
"%s: called; tbttcount=%d, period=%d, duration=%d, offset=%d\n",
__func__,
(int) q->tbttcount,
(int) q->period,
(int) le16dec(&q->duration),
(int) le16dec(&q->offset));
/*
* Don't program in garbage values.
*/
if ((le16dec(&q->duration) == 0) ||
(le16dec(&q->duration) >= ni->ni_intval)) {
DPRINTF(sc, ATH_DEBUG_QUIETIE,
"%s: invalid duration (%d)\n", __func__,
le16dec(&q->duration));
return (0);
}
/*
* Can have a 0 offset, but not a duration - so just check
* they don't exceed the intval.
*/
if (le16dec(&q->duration) + le16dec(&q->offset) >= ni->ni_intval) {
DPRINTF(sc, ATH_DEBUG_QUIETIE,
"%s: invalid duration + offset (%d+%d)\n", __func__,
le16dec(&q->duration),
le16dec(&q->offset));
return (0);
}
if (q->tbttcount == 0) {
DPRINTF(sc, ATH_DEBUG_QUIETIE,
"%s: invalid tbttcount (0)\n", __func__);
return (0);
}
if (q->period == 0) {
DPRINTF(sc, ATH_DEBUG_QUIETIE,
"%s: invalid period (0)\n", __func__);
return (0);
}
/*
* This is a new quiet time IE config, so wait until tbttcount
* is equal to 1, and program it in.
*/
if (q->tbttcount == 1) {
DPRINTF(sc, ATH_DEBUG_QUIETIE,
"%s: programming\n", __func__);
ath_hal_set_quiet(sc->sc_ah,
q->period * ni->ni_intval, /* convert to TU */
le16dec(&q->duration), /* already in TU */
le16dec(&q->offset) + ni->ni_intval,
HAL_QUIET_ENABLE | HAL_QUIET_ADD_CURRENT_TSF);
/*
* Note: no HAL_QUIET_ADD_SWBA_RESP_TIME; as this is for
* STA mode
*/
/* Update local state */
memcpy(&avp->quiet_ie, ie, sizeof(struct ieee80211_quiet_ie));
}
return (0);
}
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
static void
ath_set_channel(struct ieee80211com *ic)
{
Remove most of the references of ifp->if_softc and replace with references to ic->ic_softc. This is in preparation for gleb's ifnet work. Tested: * ath(4), STA mode * ath(4), hostap mode * make universe
2015-08-17 02:04:11 +00:00
struct ath_softc *sc = ic->ic_softc;
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ATH_LOCK(sc);
ath_power_set_power_state(sc, HAL_PM_AWAKE);
ATH_UNLOCK(sc);
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
(void) ath_chan_set(sc, ic->ic_curchan);
/*
* If we are returning to our bss channel then mark state
* so the next recv'd beacon's tsf will be used to sync the
* beacon timers. Note that since we only hear beacons in
* sta/ibss mode this has no effect in other operating modes.
*/
Wrap another ATH_LOCK around the scanning flag. PR: kern/163318
2012-03-02 03:11:53 +00:00
ATH_LOCK(sc);
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
if (!sc->sc_scanning && ic->ic_curchan == ic->ic_bsschan)
sc->sc_syncbeacon = 1;
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ath_power_restore_power_state(sc);
Wrap another ATH_LOCK around the scanning flag. PR: kern/163318
2012-03-02 03:11:53 +00:00
ATH_UNLOCK(sc);
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
}
Correct spelling of reseting (found while researching the "bb hang detected" messages that are plaguing me). While I'm here, delete trailing whitespace.
2010-02-19 18:23:45 +00:00
/*
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
* Walk the vap list and check if there any vap's in RUN state.
*/
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
static int
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
ath_isanyrunningvaps(struct ieee80211vap *this)
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
{
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
struct ieee80211com *ic = this->iv_ic;
struct ieee80211vap *vap;
IEEE80211_LOCK_ASSERT(ic);
TAILQ_FOREACH(vap, &ic->ic_vaps, iv_next) {
treat IEEE80211_S_CSA as a "running state"; this fixes ap mode 11h channel switch announcements
2009-06-03 17:25:19 +00:00
if (vap != this && vap->iv_state >= IEEE80211_S_RUN)
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
return 1;
}
return 0;
}
static int
ath_newstate(struct ieee80211vap *vap, enum ieee80211_state nstate, int arg)
{
struct ieee80211com *ic = vap->iv_ic;
Remove most of the references of ifp->if_softc and replace with references to ic->ic_softc. This is in preparation for gleb's ifnet work. Tested: * ath(4), STA mode * ath(4), hostap mode * make universe
2015-08-17 02:04:11 +00:00
struct ath_softc *sc = ic->ic_softc;
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
struct ath_vap *avp = ATH_VAP(vap);
track changes to 802.11 code: o override new_state method per new model o use ieee80211_state_name instead of private copy
2003-07-20 21:38:20 +00:00
struct ath_hal *ah = sc->sc_ah;
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
struct ieee80211_node *ni = NULL;
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
int i, error, stamode;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
u_int32_t rfilt;
Fix a corner case in STA beacon processing when a CSA is received but the AP doesn't transmit beacons. If the AP requests a CSA (ie, a channel switch) and then enters CAC (channel availability check) for 60 seconds, it doesn't send beacons and it just listens for radar events (and other things which we don't do yet.) Now, ath_newstate() was not resetting the beacon timer config on a transition to the RUN state when in STA mode - it was setting sc_syncbeacon, which simply updates the beacon config from the contents of the next received beacon. This means the STA never generates beacon miss events. If the AP goes into CAC for 60 seconds and recovers, the STA will happily receive the first beacon and reconfigure timers. But if it gets a radar event after that, it'll change channel again, not notify the station that it's changed channel.. and since the station is happily waiting for the first beacon to configure the beacon timer details from, it won't ever generate a beacon miss interrupt and it'll sit there forever (or until the AP appears on that channel once again.) This change forces the last known beacon timer config to be written to hardware on a transition from CSA->RUN in STA mode. This forces bmiss events to occur and the STA will eventually (after a handful of beacon miss events) begin scanning for another access point.
2011-06-29 13:21:52 +00:00
int csa_run_transition = 0;
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
enum ieee80211_state ostate = vap->iv_state;
Fix hangs (exposed by spectral scan activity) in STA mode when the chip hangs. * Always do a reset in ath_bmiss_proc(), regardless of whether the hardware is "hung" or not. Specifically, for spectral scan, there's likely a whole bunch of potential hangs that we don't (yet) recognise in the HAL. So to avoid staying RX deaf persisting until the station disassociates, just do a no-loss reset. * Set sc_beacons=1 in STA mode. During a reset, the beacon programming isn't done. (It's likely I need to set sc_syncbeacons during a hang reset, but I digress.) Thus after a reset, there's no beacon timer programming to send a BMISS interrupt if beacons aren't heard .. thus if the AP disappears, you won't get notified and you'll have to reset your interface. This hasn't yet fixed all of the hangs that I've seen when debugging spectral scan, but it's certainly reduced the hang frequency and it should improve general STA stability in very noisy environments. Tested: * AR9280, STA mode, spectral scan off/on PR: kern/175227
2013-01-17 16:43:59 +00:00
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
static const HAL_LED_STATE leds[] = {
HAL_LED_INIT, /* IEEE80211_S_INIT */
HAL_LED_SCAN, /* IEEE80211_S_SCAN */
HAL_LED_AUTH, /* IEEE80211_S_AUTH */
HAL_LED_ASSOC, /* IEEE80211_S_ASSOC */
fix led blinking in RUN state: the addition of the CAC state moved IEEE80211_S_RUN and broke the array lookup used to find the LED flags Approved by: re (blanket wireless)
2007-09-17 05:12:19 +00:00
HAL_LED_RUN, /* IEEE80211_S_CAC */
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
HAL_LED_RUN, /* IEEE80211_S_RUN */
fix led blinking in RUN state: the addition of the CAC state moved IEEE80211_S_RUN and broke the array lookup used to find the LED flags Approved by: re (blanket wireless)
2007-09-17 05:12:19 +00:00
HAL_LED_RUN, /* IEEE80211_S_CSA */
HAL_LED_RUN, /* IEEE80211_S_SLEEP */
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
};
Update with last year of work.
2004-12-08 17:34:36 +00:00
DPRINTF(sc, ATH_DEBUG_STATE, "%s: %s -> %s\n", __func__,
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ieee80211_state_name[ostate],
Update with last year of work.
2004-12-08 17:34:36 +00:00
ieee80211_state_name[nstate]);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
Try to ensure that ieee80211_newstate() and the vap_newstate methods hold the lock. This is part of my series of work to try and capture when net80211 locking isn't. ObNote: it'd be nice to be able to mark a lock as "assert if the lock is dropped", so I could capture functions which decide that dropping and reacquiring the lock is a good idea (without re-checking the sanity of the state protected by the lock.)
2012-02-18 09:18:06 +00:00
/*
* net80211 _should_ have the comlock asserted at this point.
* There are some comments around the calls to vap->iv_newstate
* which indicate that it (newstate) may end up dropping the
* lock. This and the subsequent lock assert check after newstate
* are an attempt to catch these and figure out how/why.
*/
IEEE80211_LOCK_ASSERT(ic);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
/* Before we touch the hardware - wake it up */
ATH_LOCK(sc);
Add tracking for self-generated frames when the VAP is in sleep state. The hardware can generate its own frames (eg RTS/CTS exchanges, other kinds of 802.11 management stuff, especially when it comes to 802.11n) and these also have PWRMGT flags. So if the VAP is asleep but the NIC is in force-awake for some reason, ensure that the self-generated frames have PWRMGT set to 1. Now, this (like basically everything to do with powersave) is still racy - the only way to guarantee that it's all actually consistent is to pause transmit and let it finish before transitioning the VAP to sleep, but this at least gets the basic method of tracking and updating the state debugged. Tested: * AR5416, STA mode * AR9380, STA mode
2014-05-02 00:48:09 +00:00
/*
* If the NIC is in anything other than SLEEP state,
* we need to ensure that self-generated frames are
* set for PWRMGT=0. Otherwise we may end up with
* strange situations.
*
* XXX TODO: is this actually the case? :-)
*/
if (nstate != IEEE80211_S_SLEEP)
ath_power_setselfgen(sc, HAL_PM_AWAKE);
/*
* Now, wake the thing up.
*/
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ath_power_set_power_state(sc, HAL_PM_AWAKE);
Migrate the callouts from using mutex locks to being mpsafe with the locks being held by the callers. Kill callout_drain() and use callout_stop().
2014-11-14 04:26:26 +00:00
/*
* And stop the calibration callout whilst we have
* ATH_LOCK held.
*/
callout_stop(&sc->sc_cal_ch);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ATH_UNLOCK(sc);
if (ostate == IEEE80211_S_CSA && nstate == IEEE80211_S_RUN)
Fix a corner case in STA beacon processing when a CSA is received but the AP doesn't transmit beacons. If the AP requests a CSA (ie, a channel switch) and then enters CAC (channel availability check) for 60 seconds, it doesn't send beacons and it just listens for radar events (and other things which we don't do yet.) Now, ath_newstate() was not resetting the beacon timer config on a transition to the RUN state when in STA mode - it was setting sc_syncbeacon, which simply updates the beacon config from the contents of the next received beacon. This means the STA never generates beacon miss events. If the AP goes into CAC for 60 seconds and recovers, the STA will happily receive the first beacon and reconfigure timers. But if it gets a radar event after that, it'll change channel again, not notify the station that it's changed channel.. and since the station is happily waiting for the first beacon to configure the beacon timer details from, it won't ever generate a beacon miss interrupt and it'll sit there forever (or until the AP appears on that channel once again.) This change forces the last known beacon timer config to be written to hardware on a transition from CSA->RUN in STA mode. This forces bmiss events to occur and the STA will eventually (after a handful of beacon miss events) begin scanning for another access point.
2011-06-29 13:21:52 +00:00
csa_run_transition = 1;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
ath_hal_setledstate(ah, leds[nstate]); /* set LED */
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
if (nstate == IEEE80211_S_SCAN) {
disable interrupts when transitioning to INIT state so we don't rx frames
2005-01-18 19:31:31 +00:00
/*
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
* Scanning: turn off beacon miss and don't beacon.
* Mark beacon state so when we reach RUN state we'll
* [re]setup beacons. Unblock the task q thread so
* deferred interrupt processing is done.
disable interrupts when transitioning to INIT state so we don't rx frames
2005-01-18 19:31:31 +00:00
*/
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
/* Ensure we stay awake during scan */
ATH_LOCK(sc);
Add tracking for self-generated frames when the VAP is in sleep state. The hardware can generate its own frames (eg RTS/CTS exchanges, other kinds of 802.11 management stuff, especially when it comes to 802.11n) and these also have PWRMGT flags. So if the VAP is asleep but the NIC is in force-awake for some reason, ensure that the self-generated frames have PWRMGT set to 1. Now, this (like basically everything to do with powersave) is still racy - the only way to guarantee that it's all actually consistent is to pause transmit and let it finish before transitioning the VAP to sleep, but this at least gets the basic method of tracking and updating the state debugged. Tested: * AR5416, STA mode * AR9380, STA mode
2014-05-02 00:48:09 +00:00
ath_power_setselfgen(sc, HAL_PM_AWAKE);
[ath] force wake the hardware if we see a missed beacon. This adds a workaround to incorrectly behaving APs (ie, FreeBSD APs) which don't beacon out exactly when they should (at TBTT multiples of beacon intervals.) It forces the hardware awake (but leaves it in network-sleep so self generated frames still state that the hardware is asleep!) and will remain awake until the next sleep transition driven by net80211. That way if the beacons are just at the wrong interval, we get a much better chance of hearing more consecutive beacons before we go to sleep, thus not constantly disconnecting. Tested: * AR9485, STA mode, against a misbehaving FreeBSD AP.
2016-11-28 17:54:29 +00:00
ath_power_setpower(sc, HAL_PM_AWAKE, 1);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ATH_UNLOCK(sc);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
ath_hal_intrset(ah,
sc->sc_imask &~ (HAL_INT_SWBA | HAL_INT_BMISS));
Drain task q items when transitioning to INIT state; this closes a race seen on smp laptops when suspending where the rx task can be entered after the interface is detach'd. NB: use of taskqueue_drain while holding the softc mutex is problematic Submitted by: ambrisko MFC after: 1 month
2007-05-29 16:13:59 +00:00
sc->sc_imask &= ~(HAL_INT_SWBA | HAL_INT_BMISS);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
sc->sc_beacons = 0;
taskqueue_unblock(sc->sc_tq);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
Attempt to address some potential vap->iv_bss race conditions. There are unfortunately a number of situations where vap->iv_bss is changed or freed by some code in net80211. Because multiple threads can concurrently be doing work (and the vap->iv_bss access isn't at all done behind any kind of lock), it's quite possible that: * a change will occur in one thread - eg, by a call through ieee80211_sta_join1(); * a state change occurs in another thread - eg an RX is scheduled in the ath tasklet and it calls ieee80211_input_mimo_all(), which does dereference vap->iv_bss; * these two executing concurrently, causing things to explode. Another instance is ath_beacon_alloc() which takes an ieee80211_node *. It's called with the vap->iv_bss node from ath_newstate(). If the node has changed in the meantime (say it's been freed elsewhere) the reference that it grabbed _before_ refcounting it may be stale. I would _prefer_ that these sorts of things were serialised somewhere but that may be a bit much to ask. Instead, the best we can (currently) hope is that the underlying bss node is still (somewhat) valid. There is a related PR (kern/164382) described by the first case above. That should be fixed by properly serialising the RX path and reset path so an RX can't occur at the same time as the vap free/shutdown path. This is inspired by some related fixes in r212127. PR: kern/165060
2012-02-13 00:28:41 +00:00
ni = ieee80211_ref_node(vap->iv_bss);
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
rfilt = ath_calcrxfilter(sc);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
stamode = (vap->iv_opmode == IEEE80211_M_STA ||
install bssid for ahdemo mode too
2008-10-27 17:54:17 +00:00
vap->iv_opmode == IEEE80211_M_AHDEMO ||
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
vap->iv_opmode == IEEE80211_M_IBSS);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
/*
* XXX Dont need to do this (and others) if we've transitioned
* from SLEEP->RUN.
*/
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
if (stamode && nstate == IEEE80211_S_RUN) {
sc->sc_curaid = ni->ni_associd;
IEEE80211_ADDR_COPY(sc->sc_curbssid, ni->ni_bssid);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
ath_hal_setassocid(ah, sc->sc_curbssid, sc->sc_curaid);
}
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
DPRINTF(sc, ATH_DEBUG_STATE, "%s: RX filter 0x%x bssid %s aid 0x%x\n",
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
__func__, rfilt, ether_sprintf(sc->sc_curbssid), sc->sc_curaid);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
ath_hal_setrxfilter(ah, rfilt);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
/* XXX is this to restore keycache on resume? */
if (vap->iv_opmode != IEEE80211_M_STA &&
(vap->iv_flags & IEEE80211_F_PRIVACY)) {
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
for (i = 0; i < IEEE80211_WEP_NKID; i++)
if (ath_hal_keyisvalid(ah, i))
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
ath_hal_keysetmac(ah, i, ni->ni_bssid);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
/*
* Invoke the parent method to do net80211 work.
*/
error = avp->av_newstate(vap, nstate, arg);
if (error != 0)
goto bad;
Update with last year of work.
2004-12-08 17:34:36 +00:00
Try to ensure that ieee80211_newstate() and the vap_newstate methods hold the lock. This is part of my series of work to try and capture when net80211 locking isn't. ObNote: it'd be nice to be able to mark a lock as "assert if the lock is dropped", so I could capture functions which decide that dropping and reacquiring the lock is a good idea (without re-checking the sanity of the state protected by the lock.)
2012-02-18 09:18:06 +00:00
/*
* See above: ensure av_newstate() doesn't drop the lock
* on us.
*/
IEEE80211_LOCK_ASSERT(ic);
[ath] fix "doing stuff before wakeup" warning; add comments for ACK/CTS handling during DFS/PASSIVE channels * Although the hardware is awake, the power state handling doesn't think so. So just explicitly wake it up early in setup so ath_hal calls don't complain. * We shouldn't be transmitting or ACKing frames during DFS CAC or on passive channels before we hear a beacon. So, start laying down comments in the places where this work has to be done. Note: * The main bit missing from finishing this particular bit of work is a state call to transition a VAP from passive to non-passive when a beacon is heard. CAC is easy, it's an interface state. So, I'll go and add a method to control that soon.
2017-01-27 01:17:00 +00:00
/*
* XXX TODO: if nstate is _S_CAC, then we should disable
* ACK processing until CAC is completed.
*/
/*
* XXX TODO: if we're on a passive channel, then we should
* not allow any ACKs or self-generated frames until we hear
* a beacon. Unfortunately there isn't a notification from
* net80211 so perhaps we could slot that particular check
* into the mgmt receive path and just ensure that we clear
* it on RX of beacons in passive mode (and only clear it
* once, obviously.)
*/
/*
* XXX TODO: net80211 should be tracking whether channels
* have heard beacons and are thus considered "OK" for
* transmitting - and then inform the driver about this
* state change. That way if we hear an AP go quiet
* (and nothing else is beaconing on a channel) the
* channel can go back to being passive until another
* beacon is heard.
*/
/*
* XXX TODO: if nstate is _S_CAC, then we should disable
* ACK processing until CAC is completed.
*/
/*
* XXX TODO: if we're on a passive channel, then we should
* not allow any ACKs or self-generated frames until we hear
* a beacon. Unfortunately there isn't a notification from
* net80211 so perhaps we could slot that particular check
* into the mgmt receive path and just ensure that we clear
* it on RX of beacons in passive mode (and only clear it
* once, obviously.)
*/
/*
* XXX TODO: net80211 should be tracking whether channels
* have heard beacons and are thus considered "OK" for
* transmitting - and then inform the driver about this
* state change. That way if we hear an AP go quiet
* (and nothing else is beaconing on a channel) the
* channel can go back to being passive until another
* beacon is heard.
*/
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
if (nstate == IEEE80211_S_RUN) {
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
/* NB: collect bss node again, it may have changed */
Attempt to address some potential vap->iv_bss race conditions. There are unfortunately a number of situations where vap->iv_bss is changed or freed by some code in net80211. Because multiple threads can concurrently be doing work (and the vap->iv_bss access isn't at all done behind any kind of lock), it's quite possible that: * a change will occur in one thread - eg, by a call through ieee80211_sta_join1(); * a state change occurs in another thread - eg an RX is scheduled in the ath tasklet and it calls ieee80211_input_mimo_all(), which does dereference vap->iv_bss; * these two executing concurrently, causing things to explode. Another instance is ath_beacon_alloc() which takes an ieee80211_node *. It's called with the vap->iv_bss node from ath_newstate(). If the node has changed in the meantime (say it's been freed elsewhere) the reference that it grabbed _before_ refcounting it may be stale. I would _prefer_ that these sorts of things were serialised somewhere but that may be a bit much to ask. Instead, the best we can (currently) hope is that the underlying bss node is still (somewhat) valid. There is a related PR (kern/164382) described by the first case above. That should be fixed by properly serialising the RX path and reset path so an RX can't occur at the same time as the vap free/shutdown path. This is inspired by some related fixes in r212127. PR: kern/165060
2012-02-13 00:28:41 +00:00
ieee80211_free_node(ni);
ni = ieee80211_ref_node(vap->iv_bss);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
Update with last year of work.
2004-12-08 17:34:36 +00:00
DPRINTF(sc, ATH_DEBUG_STATE,
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
"%s(RUN): iv_flags 0x%08x bintvl %d bssid %s "
"capinfo 0x%04x chan %d\n", __func__,
vap->iv_flags, ni->ni_intval, ether_sprintf(ni->ni_bssid),
ni->ni_capinfo, ieee80211_chan2ieee(ic, ic->ic_curchan));
switch (vap->iv_opmode) {
Remove ATH_SUPPORT_TDMA and use IEEE80211_SUPPORT_TDMA instead. It doesn't make much sense to configure driver support w/o net80211. Note this means ath now depends on opt_wlan.h.
2009-03-30 19:23:49 +00:00
#ifdef IEEE80211_SUPPORT_TDMA
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
case IEEE80211_M_AHDEMO:
if ((vap->iv_caps & IEEE80211_C_TDMA) == 0)
break;
/* fall thru... */
#endif
Misc keycache changes: o purge ath_initkeytable; it's not needed o add multicast key search support for supporting multiple group keys (disabled for now; requires updated hal) o create keycache entry for stations using open auth so they get h/w antenna management support o add keycache -> node mapping table; eliminates mac-based lookup in the net80211 layer
2005-06-06 16:39:21 +00:00
case IEEE80211_M_HOSTAP:
case IEEE80211_M_IBSS:
Implementation of the upcoming Wireless Mesh standard, 802.11s, on the net80211 wireless stack. This work is based on the March 2009 D3.0 draft standard. This standard is expected to become final next year. This includes two main net80211 modules, ieee80211_mesh.c which deals with peer link management, link metric calculation, routing table control and mesh configuration and ieee80211_hwmp.c which deals with the actually routing process on the mesh network. HWMP is the mandatory routing protocol on by the mesh standard, but others, such as RA-OLSR, can be implemented. Authentication and encryption are not implemented. There are several scripts under tools/tools/net80211/scripts that can be used to test different mesh network topologies and they also teach you how to setup a mesh vap (for the impatient: ifconfig wlan0 create wlandev ... wlanmode mesh). A new build option is available: IEEE80211_SUPPORT_MESH and it's enabled by default on GENERIC kernels for i386, amd64, sparc64 and pc98. Drivers that support mesh networks right now are: ath, ral and mwl. More information at: http://wiki.freebsd.org/WifiMesh Please note that this work is experimental. Also, please note that bridging a mesh vap with another network interface is not yet supported. Many thanks to the FreeBSD Foundation for sponsoring this project and to Sam Leffler for his support. Also, I would like to thank Gateworks Corporation for sending me a Cambria board which was used during the development of this project. Reviewed by: sam Approved by: re (kensmith) Obtained from: projects/mesh11s
2009-07-11 15:02:45 +00:00
case IEEE80211_M_MBSS:
[ath] fix "doing stuff before wakeup" warning; add comments for ACK/CTS handling during DFS/PASSIVE channels * Although the hardware is awake, the power state handling doesn't think so. So just explicitly wake it up early in setup so ath_hal calls don't complain. * We shouldn't be transmitting or ACKing frames during DFS CAC or on passive channels before we hear a beacon. So, start laying down comments in the places where this work has to be done. Note: * The main bit missing from finishing this particular bit of work is a state call to transition a VAP from passive to non-passive when a beacon is heard. CAC is easy, it's an interface state. So, I'll go and add a method to control that soon.
2017-01-27 01:17:00 +00:00
/*
* TODO: Enable ACK processing (ie, clear AR_DIAG_ACK_DIS.)
* For channels that are in CAC, we may have disabled
* this during CAC to ensure we don't ACK frames
* sent to us.
*/
beacon handling fixups for adhoc mode: o don't reclaim any previous beacon state in ath_beacon_alloc; do it explicitly in ath_newstate o reference count the node held in the beacon frame state block o process ibss merge more intelligently; let the state machine do the right thing instead of explicitly setting the new bssi id o explicitly stop tx dma before doing beacon setup to handle the ibss merge case
2005-01-24 20:05:03 +00:00
/*
Misc keycache changes: o purge ath_initkeytable; it's not needed o add multicast key search support for supporting multiple group keys (disabled for now; requires updated hal) o create keycache entry for stations using open auth so they get h/w antenna management support o add keycache -> node mapping table; eliminates mac-based lookup in the net80211 layer
2005-06-06 16:39:21 +00:00
* Allocate and setup the beacon frame.
*
beacon handling fixups for adhoc mode: o don't reclaim any previous beacon state in ath_beacon_alloc; do it explicitly in ath_newstate o reference count the node held in the beacon frame state block o process ibss merge more intelligently; let the state machine do the right thing instead of explicitly setting the new bssi id o explicitly stop tx dma before doing beacon setup to handle the ibss merge case
2005-01-24 20:05:03 +00:00
* Stop any previous beacon DMA. This may be
* necessary, for example, when an ibss merge
* causes reconfiguration; there will be a state
* transition from RUN->RUN that means we may
* be called with beacon transmission active.
*/
ath_hal_stoptxdma(ah, sc->sc_bhalq);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
error = ath_beacon_alloc(sc, ni);
if (error != 0)
goto bad;
add adhoc demo mode support MFC after: 2 weeks
2006-02-09 21:42:53 +00:00
/*
Beacon timer setup fixes: o pull nexttbtt forward in adhoc mode too o resync beacon timers on joining a bss or ibss as the tstamp we collected while scanning is almost certainly out of date Note we may need to refine the ibss mode check in ath_recv_mgmt. Reviewed by: avatar, dyoung Obtained from: atheros MFC after: 2 weeks
2006-02-09 22:21:53 +00:00
* If joining an adhoc network defer beacon timer
* configuration to the next beacon frame so we
* have a current TSF to use. Otherwise we're
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
* starting an ibss/bss so there's no need to delay;
* if this is the first vap moving to RUN state, then
* beacon state needs to be [re]configured.
add adhoc demo mode support MFC after: 2 weeks
2006-02-09 21:42:53 +00:00
*/
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
if (vap->iv_opmode == IEEE80211_M_IBSS &&
ni->ni_tstamp.tsf != 0) {
Beacon timer setup fixes: o pull nexttbtt forward in adhoc mode too o resync beacon timers on joining a bss or ibss as the tstamp we collected while scanning is almost certainly out of date Note we may need to refine the ibss mode check in ath_recv_mgmt. Reviewed by: avatar, dyoung Obtained from: atheros MFC after: 2 weeks
2006-02-09 22:21:53 +00:00
sc->sc_syncbeacon = 1;
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
} else if (!sc->sc_beacons) {
Remove ATH_SUPPORT_TDMA and use IEEE80211_SUPPORT_TDMA instead. It doesn't make much sense to configure driver support w/o net80211. Note this means ath now depends on opt_wlan.h.
2009-03-30 19:23:49 +00:00
#ifdef IEEE80211_SUPPORT_TDMA
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
if (vap->iv_caps & IEEE80211_C_TDMA)
ath_tdma_config(sc, vap);
else
#endif
ath_beacon_config(sc, vap);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
sc->sc_beacons = 1;
}
Misc keycache changes: o purge ath_initkeytable; it's not needed o add multicast key search support for supporting multiple group keys (disabled for now; requires updated hal) o create keycache entry for stations using open auth so they get h/w antenna management support o add keycache -> node mapping table; eliminates mac-based lookup in the net80211 layer
2005-06-06 16:39:21 +00:00
break;
case IEEE80211_M_STA:
add adhoc demo mode support MFC after: 2 weeks
2006-02-09 21:42:53 +00:00
/*
Beacon timer setup fixes: o pull nexttbtt forward in adhoc mode too o resync beacon timers on joining a bss or ibss as the tstamp we collected while scanning is almost certainly out of date Note we may need to refine the ibss mode check in ath_recv_mgmt. Reviewed by: avatar, dyoung Obtained from: atheros MFC after: 2 weeks
2006-02-09 22:21:53 +00:00
* Defer beacon timer configuration to the next
* beacon frame so we have a current TSF to use
* (any TSF collected when scanning is likely old).
Fix a corner case in STA beacon processing when a CSA is received but the AP doesn't transmit beacons. If the AP requests a CSA (ie, a channel switch) and then enters CAC (channel availability check) for 60 seconds, it doesn't send beacons and it just listens for radar events (and other things which we don't do yet.) Now, ath_newstate() was not resetting the beacon timer config on a transition to the RUN state when in STA mode - it was setting sc_syncbeacon, which simply updates the beacon config from the contents of the next received beacon. This means the STA never generates beacon miss events. If the AP goes into CAC for 60 seconds and recovers, the STA will happily receive the first beacon and reconfigure timers. But if it gets a radar event after that, it'll change channel again, not notify the station that it's changed channel.. and since the station is happily waiting for the first beacon to configure the beacon timer details from, it won't ever generate a beacon miss interrupt and it'll sit there forever (or until the AP appears on that channel once again.) This change forces the last known beacon timer config to be written to hardware on a transition from CSA->RUN in STA mode. This forces bmiss events to occur and the STA will eventually (after a handful of beacon miss events) begin scanning for another access point.
2011-06-29 13:21:52 +00:00
* However if it's due to a CSA -> RUN transition,
* force a beacon update so we pick up a lack of
* beacons from an AP in CAC and thus force a
* scan.
Fix hangs (exposed by spectral scan activity) in STA mode when the chip hangs. * Always do a reset in ath_bmiss_proc(), regardless of whether the hardware is "hung" or not. Specifically, for spectral scan, there's likely a whole bunch of potential hangs that we don't (yet) recognise in the HAL. So to avoid staying RX deaf persisting until the station disassociates, just do a no-loss reset. * Set sc_beacons=1 in STA mode. During a reset, the beacon programming isn't done. (It's likely I need to set sc_syncbeacons during a hang reset, but I digress.) Thus after a reset, there's no beacon timer programming to send a BMISS interrupt if beacons aren't heard .. thus if the AP disappears, you won't get notified and you'll have to reset your interface. This hasn't yet fixed all of the hangs that I've seen when debugging spectral scan, but it's certainly reduced the hang frequency and it should improve general STA stability in very noisy environments. Tested: * AR9280, STA mode, spectral scan off/on PR: kern/175227
2013-01-17 16:43:59 +00:00
*
* And, there's also corner cases here where
* after a scan, the AP may have disappeared.
* In that case, we may not receive an actual
* beacon to update the beacon timer and thus we
* won't get notified of the missing beacons.
add adhoc demo mode support MFC after: 2 weeks
2006-02-09 21:42:53 +00:00
*/
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
if (ostate != IEEE80211_S_RUN &&
ostate != IEEE80211_S_SLEEP) {
DPRINTF(sc, ATH_DEBUG_BEACON,
"%s: STA; syncbeacon=1\n", __func__);
sc->sc_syncbeacon = 1;
[ath] initial station side quiet IE support. This implements hardware assisted quiet IE support. Quiet time is an optional interval on DFS channels (but doesn't have to be DFS only channels! sigh) where the station and AP can be quiet in order to allow for channel utilisation measurements. Typically that's stuff like radar detection, spectral scan, other-BSS frame sniffing, checking how busy the air is, etc. The hardware implements it as one of the generic timers, which is supplied a period, offset from the trigger period and duration to stay quiet. The AP can announce quiet time configurations which change, and so this code also tracks that. Implementation details: * track the current quiet time IE * compare the new one against the previous one - if only the TBTT counter changes, don't update things * If tbttcount=1 then program it into the hardware - that is when it is easiest to program the correct starting offset (one TBTT + configured offset). * .. later on check to see if it can be done on any tbttcount * If the IE goes away then remove the quiet timer and clear the config * Upon reset, state change, new beacon - clear quiet time IE and just let it resync from the next beacon. History: This was work done initially by sibridgetech.com in 2011/2012/2013 as part of some FreeBSD wifi DFS contracting work they had for a third party. They implemented the net80211 quiet time IE pieces and had some test code for the station side which didn't entirely use the timers correctly. I figured out how to use the timers correctly without stopping/starting the transmit DMA engine each time. When done correctly, the timer just needs to be programmed once and left alone until the next configuration change. So, thanks to Himali Patel and Parthiv Shah for their work way back then. I finally figured it out and finished it! TODO: * Now, I'd rather net80211 did the quiet time IE tracking and parsing, pushing configurations into the driver is needed. I'll look at doing that in a subsequent update. * This doesn't handle multiple quiet time IEs, which will currently just mess things up. I'll look into supporting that in the future (at least by only obeying "one" of them, and then ignoring subsequent IEs in a beacon/probe frame.) * This also implements the STA side and not the AP side - the AP side will come later, and involves taking various other intervals into account (eg the beacon offset for multi-VAP modes, the SWBA time, etc, etc) as well as obtaining the configuration when a beacon is configured/generated rather than "hearing" an IE. * .. investigate supporting quiet IE in mesh, tdma, ibss modes * .. investigate supporting quiet IE for non-DFS channels (so this can be done for say, 2GHz channels.) * Chances are i should commit NULL methods for the ar5210, ar5211 HALs.. Tested: * AR9380, STA mode - announcing quiet, removing quiet, changing quite time config, whilst doing iperf testing; * AR9380, AP mode.
2017-02-09 23:15:11 +00:00
/* Quiet time handling - ensure we resync */
memset(&avp->quiet_ie, 0, sizeof(avp->quiet_ie));
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
if (csa_run_transition)
ath_beacon_config(sc, vap);
Fix hangs (exposed by spectral scan activity) in STA mode when the chip hangs. * Always do a reset in ath_bmiss_proc(), regardless of whether the hardware is "hung" or not. Specifically, for spectral scan, there's likely a whole bunch of potential hangs that we don't (yet) recognise in the HAL. So to avoid staying RX deaf persisting until the station disassociates, just do a no-loss reset. * Set sc_beacons=1 in STA mode. During a reset, the beacon programming isn't done. (It's likely I need to set sc_syncbeacons during a hang reset, but I digress.) Thus after a reset, there's no beacon timer programming to send a BMISS interrupt if beacons aren't heard .. thus if the AP disappears, you won't get notified and you'll have to reset your interface. This hasn't yet fixed all of the hangs that I've seen when debugging spectral scan, but it's certainly reduced the hang frequency and it should improve general STA stability in very noisy environments. Tested: * AR9280, STA mode, spectral scan off/on PR: kern/175227
2013-01-17 16:43:59 +00:00
/*
* PR: kern/175227
*
* Reconfigure beacons during reset; as otherwise
* we won't get the beacon timers reprogrammed
* after a reset and thus we won't pick up a
* beacon miss interrupt.
*
* Hopefully we'll see a beacon before the BMISS
* timer fires (too often), leading to a STA
* disassociation.
*/
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
sc->sc_beacons = 1;
}
Misc keycache changes: o purge ath_initkeytable; it's not needed o add multicast key search support for supporting multiple group keys (disabled for now; requires updated hal) o create keycache entry for stations using open auth so they get h/w antenna management support o add keycache -> node mapping table; eliminates mac-based lookup in the net80211 layer
2005-06-06 16:39:21 +00:00
break;
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
case IEEE80211_M_MONITOR:
/*
* Monitor mode vaps have only INIT->RUN and RUN->RUN
* transitions so we must re-enable interrupts here to
* handle the case of a single monitor mode vap.
*/
ath_hal_intrset(ah, sc->sc_imask);
break;
case IEEE80211_M_WDS:
break;
Misc keycache changes: o purge ath_initkeytable; it's not needed o add multicast key search support for supporting multiple group keys (disabled for now; requires updated hal) o create keycache entry for stations using open auth so they get h/w antenna management support o add keycache -> node mapping table; eliminates mac-based lookup in the net80211 layer
2005-06-06 16:39:21 +00:00
default:
break;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
Update monitoring support: o record tsf in tx+rx frames o switch from raw rssi to dbm for signal data and record both signal and noise floor data (hacked for now to assume a fixed noise floor; is correct with new hal) o add monpass sysctl to control which rx'd frames are passed up with errors; especially useful to see frames with CRC errors o mark 'd packets w/ a CRC error with radiotap's BADFCS flag Also add placeholder code for calibrating the noise floor when using newer hals. Reviewed by: avatar MFC after: 1 week
2006-01-09 17:13:20 +00:00
/*
* Let the hal process statistics collected during a
* scan so it can provide calibrated noise floor data.
*/
ath_hal_process_noisefloor(ah);
move hal statistics to softc; the per-node stats are overkill, they're only used when operating in station mode MFC after: 2 weeks
2006-02-09 21:23:44 +00:00
/*
* Reset rssi stats; maybe not the best place...
*/
sc->sc_halstats.ns_avgbrssi = ATH_RSSI_DUMMY_MARKER;
sc->sc_halstats.ns_avgrssi = ATH_RSSI_DUMMY_MARKER;
sc->sc_halstats.ns_avgtxrssi = ATH_RSSI_DUMMY_MARKER;
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
/*
* Force awake for RUN mode.
*/
ATH_LOCK(sc);
Add tracking for self-generated frames when the VAP is in sleep state. The hardware can generate its own frames (eg RTS/CTS exchanges, other kinds of 802.11 management stuff, especially when it comes to 802.11n) and these also have PWRMGT flags. So if the VAP is asleep but the NIC is in force-awake for some reason, ensure that the self-generated frames have PWRMGT set to 1. Now, this (like basically everything to do with powersave) is still racy - the only way to guarantee that it's all actually consistent is to pause transmit and let it finish before transitioning the VAP to sleep, but this at least gets the basic method of tracking and updating the state debugged. Tested: * AR5416, STA mode * AR9380, STA mode
2014-05-02 00:48:09 +00:00
ath_power_setselfgen(sc, HAL_PM_AWAKE);
[ath] force wake the hardware if we see a missed beacon. This adds a workaround to incorrectly behaving APs (ie, FreeBSD APs) which don't beacon out exactly when they should (at TBTT multiples of beacon intervals.) It forces the hardware awake (but leaves it in network-sleep so self generated frames still state that the hardware is asleep!) and will remain awake until the next sleep transition driven by net80211. That way if the beacons are just at the wrong interval, we get a much better chance of hearing more consecutive beacons before we go to sleep, thus not constantly disconnecting. Tested: * AR9485, STA mode, against a misbehaving FreeBSD AP.
2016-11-28 17:54:29 +00:00
ath_power_setpower(sc, HAL_PM_AWAKE, 1);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
/*
* Finally, start any timers and the task q thread
* (in case we didn't go through SCAN state).
*/
New periodic calibration scheme needed for 11n parts that have multiple algorithms and potentially collect multiple samples. Instead of a single calibration interval we now have short and long intervals; the long interval roughly corresponds to the previous single interval. The short interval is used to speedup collection of samples and happens much quicker. We make calls using the short interval until we're told the calibration work is complete at which point we fallback to the long interval. In addition there is a much longer reset interval used to flush all calibration state and cause everthing to start anew. With these changes you can also disable calibration entirely by setting the long interval to zero.
2008-12-07 19:26:34 +00:00
if (ath_longcalinterval != 0) {
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
/* start periodic recalibration timer */
New periodic calibration scheme needed for 11n parts that have multiple algorithms and potentially collect multiple samples. Instead of a single calibration interval we now have short and long intervals; the long interval roughly corresponds to the previous single interval. The short interval is used to speedup collection of samples and happens much quicker. We make calls using the short interval until we're told the calibration work is complete at which point we fallback to the long interval. In addition there is a much longer reset interval used to flush all calibration state and cause everthing to start anew. With these changes you can also disable calibration entirely by setting the long interval to zero.
2008-12-07 19:26:34 +00:00
callout_reset(&sc->sc_cal_ch, 1, ath_calibrate, sc);
} else {
DPRINTF(sc, ATH_DEBUG_CALIBRATE,
"%s: calibration disabled\n", __func__);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
}
Migrate the callouts from using mutex locks to being mpsafe with the locks being held by the callers. Kill callout_drain() and use callout_stop().
2014-11-14 04:26:26 +00:00
ATH_UNLOCK(sc);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
taskqueue_unblock(sc->sc_tq);
} else if (nstate == IEEE80211_S_INIT) {
[ath] initial station side quiet IE support. This implements hardware assisted quiet IE support. Quiet time is an optional interval on DFS channels (but doesn't have to be DFS only channels! sigh) where the station and AP can be quiet in order to allow for channel utilisation measurements. Typically that's stuff like radar detection, spectral scan, other-BSS frame sniffing, checking how busy the air is, etc. The hardware implements it as one of the generic timers, which is supplied a period, offset from the trigger period and duration to stay quiet. The AP can announce quiet time configurations which change, and so this code also tracks that. Implementation details: * track the current quiet time IE * compare the new one against the previous one - if only the TBTT counter changes, don't update things * If tbttcount=1 then program it into the hardware - that is when it is easiest to program the correct starting offset (one TBTT + configured offset). * .. later on check to see if it can be done on any tbttcount * If the IE goes away then remove the quiet timer and clear the config * Upon reset, state change, new beacon - clear quiet time IE and just let it resync from the next beacon. History: This was work done initially by sibridgetech.com in 2011/2012/2013 as part of some FreeBSD wifi DFS contracting work they had for a third party. They implemented the net80211 quiet time IE pieces and had some test code for the station side which didn't entirely use the timers correctly. I figured out how to use the timers correctly without stopping/starting the transmit DMA engine each time. When done correctly, the timer just needs to be programmed once and left alone until the next configuration change. So, thanks to Himali Patel and Parthiv Shah for their work way back then. I finally figured it out and finished it! TODO: * Now, I'd rather net80211 did the quiet time IE tracking and parsing, pushing configurations into the driver is needed. I'll look at doing that in a subsequent update. * This doesn't handle multiple quiet time IEs, which will currently just mess things up. I'll look into supporting that in the future (at least by only obeying "one" of them, and then ignoring subsequent IEs in a beacon/probe frame.) * This also implements the STA side and not the AP side - the AP side will come later, and involves taking various other intervals into account (eg the beacon offset for multi-VAP modes, the SWBA time, etc, etc) as well as obtaining the configuration when a beacon is configured/generated rather than "hearing" an IE. * .. investigate supporting quiet IE in mesh, tdma, ibss modes * .. investigate supporting quiet IE for non-DFS channels (so this can be done for say, 2GHz channels.) * Chances are i should commit NULL methods for the ar5210, ar5211 HALs.. Tested: * AR9380, STA mode - announcing quiet, removing quiet, changing quite time config, whilst doing iperf testing; * AR9380, AP mode.
2017-02-09 23:15:11 +00:00
/* Quiet time handling - ensure we resync */
memset(&avp->quiet_ie, 0, sizeof(avp->quiet_ie));
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
/*
* If there are no vaps left in RUN state then
* shutdown host/driver operation:
* o disable interrupts
* o disable the task queue thread
* o mark beacon processing as stopped
*/
if (!ath_isanyrunningvaps(vap)) {
sc->sc_imask &= ~(HAL_INT_SWBA | HAL_INT_BMISS);
/* disable interrupts */
ath_hal_intrset(ah, sc->sc_imask &~ HAL_INT_GLOBAL);
taskqueue_block(sc->sc_tq);
sc->sc_beacons = 0;
}
[ath] [ath_rate] Fix ANI calibration during non-ACTIVE states; start poking at rate control These are some fun issues I've found with my upstairs wifi link at such a ridiculous low signal level (like, < 5dB.) * Add per-station tx/rx rssi statistics, in potential preparation to use that in the RX rate control. * Call the rate control on each received frame to let it potentially use it as a hint for what rates to potentially use. It's a no-op right now. * Do ANI calibration during scan as well. The ath_newstate() call was disabling the ANI timer and only re-enabling it during transitions to _RUN. This has the unfortunate side-effect that if ANI deafened the NIC because of interference and it disassociated, it wouldn't be reset and the scan would never hear beacons. The ANI configuration is stored at least globally on some HALs and per-channel on others. Because of this a NIC reset wouldn't help; the ANI parameters would simply be programmed back in. Now, I have a feeling I also need to do this during AUTH/ASSOC too and maybe, if I'm feeling clever, I need to reset the ANI parameters on a given channel during a transition through INIT or if the VAP is destroyed/re-created. However for now this gets me out of the immediate weeds with connectivity upstairs (and thus I /can/ commit); I'll keep chipping away at tidying this stuff up in subsequent commits. Tested: * AR9344 (Wasp), 2G STA mode
2019-05-05 04:56:37 +00:00
/*
* For at least STA mode we likely should clear the ANI
* and NF calibration state and allow the NIC/HAL to figure
* out optimal parameters at runtime. Otherwise if we
* disassociate due to interference / deafness it may persist
* when we reconnect.
*
* Note: may need to do this for other states too, not just
* _S_INIT.
*/
Remove ATH_SUPPORT_TDMA and use IEEE80211_SUPPORT_TDMA instead. It doesn't make much sense to configure driver support w/o net80211. Note this means ath now depends on opt_wlan.h.
2009-03-30 19:23:49 +00:00
#ifdef IEEE80211_SUPPORT_TDMA
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
ath_hal_setcca(ah, AH_TRUE);
#endif
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
} else if (nstate == IEEE80211_S_SLEEP) {
/* We're going to sleep, so transition appropriately */
/* For now, only do this if we're a single STA vap */
if (sc->sc_nvaps == 1 &&
vap->iv_opmode == IEEE80211_M_STA) {
DPRINTF(sc, ATH_DEBUG_BEACON, "%s: syncbeacon=%d\n", __func__, sc->sc_syncbeacon);
ATH_LOCK(sc);
/*
* Always at least set the self-generated
Add tracking for self-generated frames when the VAP is in sleep state. The hardware can generate its own frames (eg RTS/CTS exchanges, other kinds of 802.11 management stuff, especially when it comes to 802.11n) and these also have PWRMGT flags. So if the VAP is asleep but the NIC is in force-awake for some reason, ensure that the self-generated frames have PWRMGT set to 1. Now, this (like basically everything to do with powersave) is still racy - the only way to guarantee that it's all actually consistent is to pause transmit and let it finish before transitioning the VAP to sleep, but this at least gets the basic method of tracking and updating the state debugged. Tested: * AR5416, STA mode * AR9380, STA mode
2014-05-02 00:48:09 +00:00
* frame config to set PWRMGT=1.
*/
ath_power_setselfgen(sc, HAL_PM_NETWORK_SLEEP);
/*
* If we're not syncing beacons, transition
* to NETWORK_SLEEP.
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
*
Add tracking for self-generated frames when the VAP is in sleep state. The hardware can generate its own frames (eg RTS/CTS exchanges, other kinds of 802.11 management stuff, especially when it comes to 802.11n) and these also have PWRMGT flags. So if the VAP is asleep but the NIC is in force-awake for some reason, ensure that the self-generated frames have PWRMGT set to 1. Now, this (like basically everything to do with powersave) is still racy - the only way to guarantee that it's all actually consistent is to pause transmit and let it finish before transitioning the VAP to sleep, but this at least gets the basic method of tracking and updating the state debugged. Tested: * AR5416, STA mode * AR9380, STA mode
2014-05-02 00:48:09 +00:00
* We stay awake if syncbeacon > 0 in case
* we need to listen for some beacons otherwise
* our beacon timer config may be wrong.
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
*/
Add tracking for self-generated frames when the VAP is in sleep state. The hardware can generate its own frames (eg RTS/CTS exchanges, other kinds of 802.11 management stuff, especially when it comes to 802.11n) and these also have PWRMGT flags. So if the VAP is asleep but the NIC is in force-awake for some reason, ensure that the self-generated frames have PWRMGT set to 1. Now, this (like basically everything to do with powersave) is still racy - the only way to guarantee that it's all actually consistent is to pause transmit and let it finish before transitioning the VAP to sleep, but this at least gets the basic method of tracking and updating the state debugged. Tested: * AR5416, STA mode * AR9380, STA mode
2014-05-02 00:48:09 +00:00
if (sc->sc_syncbeacon == 0) {
[ath] force wake the hardware if we see a missed beacon. This adds a workaround to incorrectly behaving APs (ie, FreeBSD APs) which don't beacon out exactly when they should (at TBTT multiples of beacon intervals.) It forces the hardware awake (but leaves it in network-sleep so self generated frames still state that the hardware is asleep!) and will remain awake until the next sleep transition driven by net80211. That way if the beacons are just at the wrong interval, we get a much better chance of hearing more consecutive beacons before we go to sleep, thus not constantly disconnecting. Tested: * AR9485, STA mode, against a misbehaving FreeBSD AP.
2016-11-28 17:54:29 +00:00
ath_power_setpower(sc, HAL_PM_NETWORK_SLEEP, 1);
Add tracking for self-generated frames when the VAP is in sleep state. The hardware can generate its own frames (eg RTS/CTS exchanges, other kinds of 802.11 management stuff, especially when it comes to 802.11n) and these also have PWRMGT flags. So if the VAP is asleep but the NIC is in force-awake for some reason, ensure that the self-generated frames have PWRMGT set to 1. Now, this (like basically everything to do with powersave) is still racy - the only way to guarantee that it's all actually consistent is to pause transmit and let it finish before transitioning the VAP to sleep, but this at least gets the basic method of tracking and updating the state debugged. Tested: * AR5416, STA mode * AR9380, STA mode
2014-05-02 00:48:09 +00:00
}
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ATH_UNLOCK(sc);
}
[ath] [ath_rate] Fix ANI calibration during non-ACTIVE states; start poking at rate control These are some fun issues I've found with my upstairs wifi link at such a ridiculous low signal level (like, < 5dB.) * Add per-station tx/rx rssi statistics, in potential preparation to use that in the RX rate control. * Call the rate control on each received frame to let it potentially use it as a hint for what rates to potentially use. It's a no-op right now. * Do ANI calibration during scan as well. The ath_newstate() call was disabling the ANI timer and only re-enabling it during transitions to _RUN. This has the unfortunate side-effect that if ANI deafened the NIC because of interference and it disassociated, it wouldn't be reset and the scan would never hear beacons. The ANI configuration is stored at least globally on some HALs and per-channel on others. Because of this a NIC reset wouldn't help; the ANI parameters would simply be programmed back in. Now, I have a feeling I also need to do this during AUTH/ASSOC too and maybe, if I'm feeling clever, I need to reset the ANI parameters on a given channel during a transition through INIT or if the VAP is destroyed/re-created. However for now this gets me out of the immediate weeds with connectivity upstairs (and thus I /can/ commit); I'll keep chipping away at tidying this stuff up in subsequent commits. Tested: * AR9344 (Wasp), 2G STA mode
2019-05-05 04:56:37 +00:00
/*
* Note - the ANI/calibration timer isn't re-enabled during
* network sleep for now. One unfortunate side-effect is that
* the PHY/airtime statistics aren't gathered on the channel
* but I haven't yet tested to see if reading those registers
* CAN occur during network sleep.
*
* This should be revisited in a future commit, even if it's
* just to split out the airtime polling from ANI/calibration.
*/
[ath] initial station side quiet IE support. This implements hardware assisted quiet IE support. Quiet time is an optional interval on DFS channels (but doesn't have to be DFS only channels! sigh) where the station and AP can be quiet in order to allow for channel utilisation measurements. Typically that's stuff like radar detection, spectral scan, other-BSS frame sniffing, checking how busy the air is, etc. The hardware implements it as one of the generic timers, which is supplied a period, offset from the trigger period and duration to stay quiet. The AP can announce quiet time configurations which change, and so this code also tracks that. Implementation details: * track the current quiet time IE * compare the new one against the previous one - if only the TBTT counter changes, don't update things * If tbttcount=1 then program it into the hardware - that is when it is easiest to program the correct starting offset (one TBTT + configured offset). * .. later on check to see if it can be done on any tbttcount * If the IE goes away then remove the quiet timer and clear the config * Upon reset, state change, new beacon - clear quiet time IE and just let it resync from the next beacon. History: This was work done initially by sibridgetech.com in 2011/2012/2013 as part of some FreeBSD wifi DFS contracting work they had for a third party. They implemented the net80211 quiet time IE pieces and had some test code for the station side which didn't entirely use the timers correctly. I figured out how to use the timers correctly without stopping/starting the transmit DMA engine each time. When done correctly, the timer just needs to be programmed once and left alone until the next configuration change. So, thanks to Himali Patel and Parthiv Shah for their work way back then. I finally figured it out and finished it! TODO: * Now, I'd rather net80211 did the quiet time IE tracking and parsing, pushing configurations into the driver is needed. I'll look at doing that in a subsequent update. * This doesn't handle multiple quiet time IEs, which will currently just mess things up. I'll look into supporting that in the future (at least by only obeying "one" of them, and then ignoring subsequent IEs in a beacon/probe frame.) * This also implements the STA side and not the AP side - the AP side will come later, and involves taking various other intervals into account (eg the beacon offset for multi-VAP modes, the SWBA time, etc, etc) as well as obtaining the configuration when a beacon is configured/generated rather than "hearing" an IE. * .. investigate supporting quiet IE in mesh, tdma, ibss modes * .. investigate supporting quiet IE for non-DFS channels (so this can be done for say, 2GHz channels.) * Chances are i should commit NULL methods for the ar5210, ar5211 HALs.. Tested: * AR9380, STA mode - announcing quiet, removing quiet, changing quite time config, whilst doing iperf testing; * AR9380, AP mode.
2017-02-09 23:15:11 +00:00
} else if (nstate == IEEE80211_S_SCAN) {
/* Quiet time handling - ensure we resync */
memset(&avp->quiet_ie, 0, sizeof(avp->quiet_ie));
[ath] [ath_rate] Fix ANI calibration during non-ACTIVE states; start poking at rate control These are some fun issues I've found with my upstairs wifi link at such a ridiculous low signal level (like, < 5dB.) * Add per-station tx/rx rssi statistics, in potential preparation to use that in the RX rate control. * Call the rate control on each received frame to let it potentially use it as a hint for what rates to potentially use. It's a no-op right now. * Do ANI calibration during scan as well. The ath_newstate() call was disabling the ANI timer and only re-enabling it during transitions to _RUN. This has the unfortunate side-effect that if ANI deafened the NIC because of interference and it disassociated, it wouldn't be reset and the scan would never hear beacons. The ANI configuration is stored at least globally on some HALs and per-channel on others. Because of this a NIC reset wouldn't help; the ANI parameters would simply be programmed back in. Now, I have a feeling I also need to do this during AUTH/ASSOC too and maybe, if I'm feeling clever, I need to reset the ANI parameters on a given channel during a transition through INIT or if the VAP is destroyed/re-created. However for now this gets me out of the immediate weeds with connectivity upstairs (and thus I /can/ commit); I'll keep chipping away at tidying this stuff up in subsequent commits. Tested: * AR9344 (Wasp), 2G STA mode
2019-05-05 04:56:37 +00:00
/*
* If we're in scan mode then startpcureceive() is
* hopefully being called with "reset ANI" for this channel;
* but once we attempt to reassociate we program in the previous
* ANI values and.. not do any calibration until we're running.
* This may mean we stay deaf unless we can associate successfully.
*
* So do kick off the cal timer to get NF/ANI going.
*/
ATH_LOCK(sc);
if (ath_longcalinterval != 0) {
/* start periodic recalibration timer */
callout_reset(&sc->sc_cal_ch, 1, ath_calibrate, sc);
} else {
DPRINTF(sc, ATH_DEBUG_CALIBRATE,
"%s: calibration disabled\n", __func__);
}
ATH_UNLOCK(sc);
Update with last year of work.
2004-12-08 17:34:36 +00:00
}
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
bad:
Attempt to address some potential vap->iv_bss race conditions. There are unfortunately a number of situations where vap->iv_bss is changed or freed by some code in net80211. Because multiple threads can concurrently be doing work (and the vap->iv_bss access isn't at all done behind any kind of lock), it's quite possible that: * a change will occur in one thread - eg, by a call through ieee80211_sta_join1(); * a state change occurs in another thread - eg an RX is scheduled in the ath tasklet and it calls ieee80211_input_mimo_all(), which does dereference vap->iv_bss; * these two executing concurrently, causing things to explode. Another instance is ath_beacon_alloc() which takes an ieee80211_node *. It's called with the vap->iv_bss node from ath_newstate(). If the node has changed in the meantime (say it's been freed elsewhere) the reference that it grabbed _before_ refcounting it may be stale. I would _prefer_ that these sorts of things were serialised somewhere but that may be a bit much to ask. Instead, the best we can (currently) hope is that the underlying bss node is still (somewhat) valid. There is a related PR (kern/164382) described by the first case above. That should be fixed by properly serialising the RX path and reset path so an RX can't occur at the same time as the vap free/shutdown path. This is inspired by some related fixes in r212127. PR: kern/165060
2012-02-13 00:28:41 +00:00
ieee80211_free_node(ni);
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
/*
* Restore the power state - either to what it was, or
* to network_sleep if it's alright.
*/
ATH_LOCK(sc);
ath_power_restore_power_state(sc);
ATH_UNLOCK(sc);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
return error;
}
Misc keycache changes: o purge ath_initkeytable; it's not needed o add multicast key search support for supporting multiple group keys (disabled for now; requires updated hal) o create keycache entry for stations using open auth so they get h/w antenna management support o add keycache -> node mapping table; eliminates mac-based lookup in the net80211 layer
2005-06-06 16:39:21 +00:00
/*
* Allocate a key cache slot to the station so we can
* setup a mapping from key index to node. The key cache
* slot is needed for managing antenna state and for
* compression when stations do not use crypto. We do
* it uniliaterally here; if crypto is employed this slot
* will be reassigned.
*/
static void
ath_setup_stationkey(struct ieee80211_node *ni)
{
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
struct ieee80211vap *vap = ni->ni_vap;
Remove most of the references of ifp->if_softc and replace with references to ic->ic_softc. This is in preparation for gleb's ifnet work. Tested: * ath(4), STA mode * ath(4), hostap mode * make universe
2015-08-17 02:04:11 +00:00
struct ath_softc *sc = vap->iv_ic->ic_softc;
Split crypto tx+rx key indices and add a key index -> node mapping table: Crypto changes: o change driver/net80211 key_alloc api to return tx+rx key indices; a driver can leave the rx key index set to IEEE80211_KEYIX_NONE or set it to be the same as the tx key index (the former disables use of the key index in building the keyix->node mapping table and is the default setup for naive drivers by null_key_alloc) o add cs_max_keyid to crypto state to specify the max h/w key index a driver will return; this is used to allocate the key index mapping table and to bounds check table loookups o while here introduce ieee80211_keyix (finally) for the type of a h/w key index o change crypto notifiers for rx failures to pass the rx key index up as appropriate (michael failure, replay, etc.) Node table changes: o optionally allocate a h/w key index to node mapping table for the station table using the max key index setting supplied by drivers (note the scan table does not get a map) o defer node table allocation to lateattach so the driver has a chance to set the max key id to size the key index map o while here also defer the aid bitmap allocation o add new ieee80211_find_rxnode_withkey api to find a sta/node entry on frame receive with an optional h/w key index to use in checking mapping table; also updates the map if it does a hash lookup and the found node has a rx key index set in the unicast key; note this work is separated from the old ieee80211_find_rxnode call so drivers do not need to be aware of the new mechanism o move some node table manipulation under the node table lock to close a race on node delete o add ieee80211_node_delucastkey to do the dirty work of deleting unicast key state for a node (deletes any key and handles key map references) Ath driver: o nuke private sc_keyixmap mechansim in favor of net80211 support o update key alloc api These changes close several race conditions for the ath driver operating in ap mode. Other drivers should see no change. Station mode operation for ath no longer uses the key index map but performance tests show no noticeable change and this will be fixed when the scan table is eliminated with the new scanning support. Tested by: Michal Mertl, avatar, others Reviewed by: avatar, others MFC after: 2 weeks
2005-08-08 18:46:36 +00:00
ieee80211_keyix keyix, rxkeyix;
Misc keycache changes: o purge ath_initkeytable; it's not needed o add multicast key search support for supporting multiple group keys (disabled for now; requires updated hal) o create keycache entry for stations using open auth so they get h/w antenna management support o add keycache -> node mapping table; eliminates mac-based lookup in the net80211 layer
2005-06-06 16:39:21 +00:00
Attempt to address some potential vap->iv_bss race conditions. There are unfortunately a number of situations where vap->iv_bss is changed or freed by some code in net80211. Because multiple threads can concurrently be doing work (and the vap->iv_bss access isn't at all done behind any kind of lock), it's quite possible that: * a change will occur in one thread - eg, by a call through ieee80211_sta_join1(); * a state change occurs in another thread - eg an RX is scheduled in the ath tasklet and it calls ieee80211_input_mimo_all(), which does dereference vap->iv_bss; * these two executing concurrently, causing things to explode. Another instance is ath_beacon_alloc() which takes an ieee80211_node *. It's called with the vap->iv_bss node from ath_newstate(). If the node has changed in the meantime (say it's been freed elsewhere) the reference that it grabbed _before_ refcounting it may be stale. I would _prefer_ that these sorts of things were serialised somewhere but that may be a bit much to ask. Instead, the best we can (currently) hope is that the underlying bss node is still (somewhat) valid. There is a related PR (kern/164382) described by the first case above. That should be fixed by properly serialising the RX path and reset path so an RX can't occur at the same time as the vap free/shutdown path. This is inspired by some related fixes in r212127. PR: kern/165060
2012-02-13 00:28:41 +00:00
/* XXX should take a locked ref to vap->iv_bss */
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
if (!ath_key_alloc(vap, &ni->ni_ucastkey, &keyix, &rxkeyix)) {
Misc keycache changes: o purge ath_initkeytable; it's not needed o add multicast key search support for supporting multiple group keys (disabled for now; requires updated hal) o create keycache entry for stations using open auth so they get h/w antenna management support o add keycache -> node mapping table; eliminates mac-based lookup in the net80211 layer
2005-06-06 16:39:21 +00:00
/*
* Key cache is full; we'll fall back to doing
* the more expensive lookup in software. Note
* this also means no h/w compression.
*/
/* XXX msg+statistic */
} else {
Split crypto tx+rx key indices and add a key index -> node mapping table: Crypto changes: o change driver/net80211 key_alloc api to return tx+rx key indices; a driver can leave the rx key index set to IEEE80211_KEYIX_NONE or set it to be the same as the tx key index (the former disables use of the key index in building the keyix->node mapping table and is the default setup for naive drivers by null_key_alloc) o add cs_max_keyid to crypto state to specify the max h/w key index a driver will return; this is used to allocate the key index mapping table and to bounds check table loookups o while here introduce ieee80211_keyix (finally) for the type of a h/w key index o change crypto notifiers for rx failures to pass the rx key index up as appropriate (michael failure, replay, etc.) Node table changes: o optionally allocate a h/w key index to node mapping table for the station table using the max key index setting supplied by drivers (note the scan table does not get a map) o defer node table allocation to lateattach so the driver has a chance to set the max key id to size the key index map o while here also defer the aid bitmap allocation o add new ieee80211_find_rxnode_withkey api to find a sta/node entry on frame receive with an optional h/w key index to use in checking mapping table; also updates the map if it does a hash lookup and the found node has a rx key index set in the unicast key; note this work is separated from the old ieee80211_find_rxnode call so drivers do not need to be aware of the new mechanism o move some node table manipulation under the node table lock to close a race on node delete o add ieee80211_node_delucastkey to do the dirty work of deleting unicast key state for a node (deletes any key and handles key map references) Ath driver: o nuke private sc_keyixmap mechansim in favor of net80211 support o update key alloc api These changes close several race conditions for the ath driver operating in ap mode. Other drivers should see no change. Station mode operation for ath no longer uses the key index map but performance tests show no noticeable change and this will be fixed when the scan table is eliminated with the new scanning support. Tested by: Michal Mertl, avatar, others Reviewed by: avatar, others MFC after: 2 weeks
2005-08-08 18:46:36 +00:00
/* XXX locking? */
Misc keycache changes: o purge ath_initkeytable; it's not needed o add multicast key search support for supporting multiple group keys (disabled for now; requires updated hal) o create keycache entry for stations using open auth so they get h/w antenna management support o add keycache -> node mapping table; eliminates mac-based lookup in the net80211 layer
2005-06-06 16:39:21 +00:00
ni->ni_ucastkey.wk_keyix = keyix;
Split crypto tx+rx key indices and add a key index -> node mapping table: Crypto changes: o change driver/net80211 key_alloc api to return tx+rx key indices; a driver can leave the rx key index set to IEEE80211_KEYIX_NONE or set it to be the same as the tx key index (the former disables use of the key index in building the keyix->node mapping table and is the default setup for naive drivers by null_key_alloc) o add cs_max_keyid to crypto state to specify the max h/w key index a driver will return; this is used to allocate the key index mapping table and to bounds check table loookups o while here introduce ieee80211_keyix (finally) for the type of a h/w key index o change crypto notifiers for rx failures to pass the rx key index up as appropriate (michael failure, replay, etc.) Node table changes: o optionally allocate a h/w key index to node mapping table for the station table using the max key index setting supplied by drivers (note the scan table does not get a map) o defer node table allocation to lateattach so the driver has a chance to set the max key id to size the key index map o while here also defer the aid bitmap allocation o add new ieee80211_find_rxnode_withkey api to find a sta/node entry on frame receive with an optional h/w key index to use in checking mapping table; also updates the map if it does a hash lookup and the found node has a rx key index set in the unicast key; note this work is separated from the old ieee80211_find_rxnode call so drivers do not need to be aware of the new mechanism o move some node table manipulation under the node table lock to close a race on node delete o add ieee80211_node_delucastkey to do the dirty work of deleting unicast key state for a node (deletes any key and handles key map references) Ath driver: o nuke private sc_keyixmap mechansim in favor of net80211 support o update key alloc api These changes close several race conditions for the ath driver operating in ap mode. Other drivers should see no change. Station mode operation for ath no longer uses the key index map but performance tests show no noticeable change and this will be fixed when the scan table is eliminated with the new scanning support. Tested by: Michal Mertl, avatar, others Reviewed by: avatar, others MFC after: 2 weeks
2005-08-08 18:46:36 +00:00
ni->ni_ucastkey.wk_rxkeyix = rxkeyix;
mark the CLR key installed for open auth stations such that it is reclaimed when net80211 tears down station state; without this we leak keycache slots
2009-02-10 19:27:50 +00:00
/* NB: must mark device key to get called back on delete */
ni->ni_ucastkey.wk_flags |= IEEE80211_KEY_DEVKEY;
Cleanup power handling and fix suspend/resume: o do not put the chip into full sleep in ath_stop as it gains nothing and causes many parts to hang in ath_detach because we may touch the chip during vap teardown; this may also fix issues with unloading the module o add a note in ath_detach to explain ath_hal_detach puts the chip in low power mode; this is useful to know as it means unloading the module will place a pci device in the lowest possible power state o leave an #ifdef notyet marker for powering down the chip when a device is marked down; we can't do that until we handle all the ways the driver may be entered and touch the chip o fix resume by reloading the h/w key cache as it's been clobbered (for pci) by the socket being powered off; for station mode we directly stop+init the chip and then simulate a beacon miss to get the upper layers sync'd up; for other configs we must brute force stop+start the vaps so they go through the state machine
2008-05-29 00:10:48 +00:00
IEEE80211_ADDR_COPY(ni->ni_ucastkey.wk_macaddr, ni->ni_macaddr);
Misc keycache changes: o purge ath_initkeytable; it's not needed o add multicast key search support for supporting multiple group keys (disabled for now; requires updated hal) o create keycache entry for stations using open auth so they get h/w antenna management support o add keycache -> node mapping table; eliminates mac-based lookup in the net80211 layer
2005-06-06 16:39:21 +00:00
/* NB: this will create a pass-thru key entry */
Add a 'vap' to ath_keyset(). Add some code (which is currently disabled) which modifies the group multicast key cache behaviour. I haven't yet figured out what the exact/correct behaviour is so I'm leaving it disabled. It's worth investigating and "correcting", especially for future work with mesh/ibss and encryption. Sponsored by: Hobnob, Inc.
2011-11-08 19:25:52 +00:00
ath_keyset(sc, vap, &ni->ni_ucastkey, vap->iv_bss);
Misc keycache changes: o purge ath_initkeytable; it's not needed o add multicast key search support for supporting multiple group keys (disabled for now; requires updated hal) o create keycache entry for stations using open auth so they get h/w antenna management support o add keycache -> node mapping table; eliminates mac-based lookup in the net80211 layer
2005-06-06 16:39:21 +00:00
}
}
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
/*
* Setup driver-specific state for a newly associated node.
* Note that we're called also on a re-associate, the isnew
* param tells us if this is the first time or not.
*/
static void
simplify ic_newassoc callback MFC after: 3 days
2005-07-22 17:57:16 +00:00
ath_newassoc(struct ieee80211_node *ni, int isnew)
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
{
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
struct ath_node *an = ATH_NODE(ni);
struct ieee80211vap *vap = ni->ni_vap;
Remove most of the references of ifp->if_softc and replace with references to ic->ic_softc. This is in preparation for gleb's ifnet work. Tested: * ath(4), STA mode * ath(4), hostap mode * make universe
2015-08-17 02:04:11 +00:00
struct ath_softc *sc = vap->iv_ic->ic_softc;
remove driver-private equivalent of ni_txparms; it's now superfluous
2008-10-27 17:03:24 +00:00
const struct ieee80211_txparam *tp = ni->ni_txparms;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
optimize ath_tx_findrix: there's no need to walk the rates table as sc_rixmap is an inverse map NB: could eliminate the check for an invalid rate by filling in 0 for invalid entries but the rate control modules use it to identify bogus rates so leave it for now
2009-05-07 00:35:32 +00:00
an->an_mcastrix = ath_tx_findrix(sc, tp->mcastrate);
an->an_mgmtrix = ath_tx_findrix(sc, tp->mgmtrate);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
DPRINTF(sc, ATH_DEBUG_NODE, "%s: %6D: reassoc; isnew=%d, is_powersave=%d\n",
__func__,
ni->ni_macaddr,
":",
isnew,
an->an_is_powersave);
Wrap the rate control re-init code in a lock, to serialise it with concurrent updates from any completing transmits in other threads. This was exposed when doing power save work - net80211 is constantly doing reassociations and it's causing the rate control state to get blanked out. This could cause the rate control code to assert. This should be MFCed to stable/10 as it's a stability fix. Tested: * AR5416, STA MFC after: 7 days
2014-04-23 05:19:45 +00:00
ATH_NODE_LOCK(an);
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
ath_rate_newassoc(sc, an, isnew);
Wrap the rate control re-init code in a lock, to serialise it with concurrent updates from any completing transmits in other threads. This was exposed when doing power save work - net80211 is constantly doing reassociations and it's causing the rate control state to get blanked out. This could cause the rate control code to assert. This should be MFCed to stable/10 as it's a stability fix. Tested: * AR5416, STA MFC after: 7 days
2014-04-23 05:19:45 +00:00
ATH_NODE_UNLOCK(an);
Turn the reassociate debug print into a DPRINTF.
2013-05-29 05:10:11 +00:00
Correct spelling of reseting (found while researching the "bb hang detected" messages that are plaguing me). While I'm here, delete trailing whitespace.
2010-02-19 18:23:45 +00:00
if (isnew &&
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
(vap->iv_flags & IEEE80211_F_PRIVACY) == 0 && sc->sc_hasclrkey &&
ni->ni_ucastkey.wk_keyix == IEEE80211_KEYIX_NONE)
Misc keycache changes: o purge ath_initkeytable; it's not needed o add multicast key search support for supporting multiple group keys (disabled for now; requires updated hal) o create keycache entry for stations using open auth so they get h/w antenna management support o add keycache -> node mapping table; eliminates mac-based lookup in the net80211 layer
2005-06-06 16:39:21 +00:00
ath_setup_stationkey(ni);
Begin tidying up the reassociation and node sleep/wakeup paths. * Move the node sleep/wake state under the TX lock rather than the node lock. Let's leave the node lock protecting rate control only for now. * When reassociating, various state needs to be cleared. For example, the aggregate session needs to be torn down, including any pending aggregation negotiation and BAR TX waiting. * .. and we need to do a "cleanup" pass since frames in the hardware TX queue need to be transmitted. Modify ath_tx_tid_cleanup() to be called with the TX lock held and push frames into a completion list. This allows for the cleanup to be done atomically for all TIDs in a node rather than grabbing and releasing the TX lock each time.
2013-05-13 18:56:04 +00:00
/*
* If we're reassociating, make sure that any paused queues
* get unpaused.
*
dev/ath: minor spelling fixes in comments. No functional change. Reviewed by: adrian
2016-05-02 19:56:48 +00:00
* Now, we may have frames in the hardware queue for this node.
Begin tidying up the reassociation and node sleep/wakeup paths. * Move the node sleep/wake state under the TX lock rather than the node lock. Let's leave the node lock protecting rate control only for now. * When reassociating, various state needs to be cleared. For example, the aggregate session needs to be torn down, including any pending aggregation negotiation and BAR TX waiting. * .. and we need to do a "cleanup" pass since frames in the hardware TX queue need to be transmitted. Modify ath_tx_tid_cleanup() to be called with the TX lock held and push frames into a completion list. This allows for the cleanup to be done atomically for all TIDs in a node rather than grabbing and releasing the TX lock each time.
2013-05-13 18:56:04 +00:00
* So if we are reassociating and there are frames in the queue,
* we need to go through the cleanup path to ensure that they're
* marked as non-aggregate.
*/
if (! isnew) {
Turn the reassociate debug print into a DPRINTF.
2013-05-29 05:10:11 +00:00
DPRINTF(sc, ATH_DEBUG_NODE,
Begin tidying up the reassociation and node sleep/wakeup paths. * Move the node sleep/wake state under the TX lock rather than the node lock. Let's leave the node lock protecting rate control only for now. * When reassociating, various state needs to be cleared. For example, the aggregate session needs to be torn down, including any pending aggregation negotiation and BAR TX waiting. * .. and we need to do a "cleanup" pass since frames in the hardware TX queue need to be transmitted. Modify ath_tx_tid_cleanup() to be called with the TX lock held and push frames into a completion list. This allows for the cleanup to be done atomically for all TIDs in a node rather than grabbing and releasing the TX lock each time.
2013-05-13 18:56:04 +00:00
"%s: %6D: reassoc; is_powersave=%d\n",
__func__,
ni->ni_macaddr,
":",
an->an_is_powersave);
/* XXX for now, we can't hold the lock across assoc */
ath_tx_node_reassoc(sc, an);
/* XXX for now, we can't hold the lock across wakeup */
if (an->an_is_powersave)
ath_tx_node_wakeup(sc, an);
}
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
static int
Overhaul regulatory support: o remove HAL_CHANNEL; convert the hal to use net80211 channels; this mostly involves mechanical changes to variable names and channel attribute macros o gut HAL_CHANNEL_PRIVATE as most of the contents are now redundant with the net80211 channel available o change api for ath_hal_init_channels: no more reglass id's, no more outdoor indication (was a noop), anM contents o add ath_hal_getchannels to have the hal construct a channel list without altering runtime state; this is used to retrieve the calibration list for the device in ath_getradiocaps o add ath_hal_set_channels to take a channel list and regulatory data from above and construct internal state to match (maps frequencies for 900MHz cards, setup for CTL lookups, etc) o compact the private channel table: we keep one private channel per frequency instead of one per HAL_CHANNEL; this gives a big space savings and potentially improves ani and calibration by sharing state (to be seen; didn't see anything in testing); a new config option AH_MAXCHAN controls the table size (default to 96 which was chosen to be ~3x the largest expected size) o shrink ani state and change to mirror private channel table (one entry per frequency indexed by ic_devdata) o move ani state flags to private channel state o remove country codes; use net80211 definitions instead o remove GSM regulatory support; it's no longer needed now that we pass in channel lists from above o consolidate ADHOC_NO_11A attribute with DISALLOW_ADHOC_11A o simplify initial channel list construction based on the EEPROM contents; we preserve country code support for now but may want to just fallback to a WWR sku and dispatch the discovered country code up to user space so the channel list can be constructed using the master regdomain tables o defer to net80211 for max antenna gain o eliminate sorting of internal channel table; now that we use ic_devdata as an index, table lookups are O(1) o remove internal copy of the country code; the public one is sufficient o remove AH_SUPPORT_11D conditional compilation; we always support 11d o remove ath_hal_ispublicsafetysku; not needed any more o remove ath_hal_isgsmsku; no more GSM stuff o move Conformance Test Limit (CTL) state from private channel to a lookup using per-band pointers cached in the private state block o remove regulatory class id support; was unused and belongs in net80211 o fix channel list construction to set IEEE80211_CHAN_NOADHOC, IEEE80211_CHAN_NOHOSTAP, and IEEE80211_CHAN_4MSXMIT o remove private channel flags CHANNEL_DFS and CHANNEL_4MS_LIMIT; these are now set in the constructed net80211 channel o store CHANNEL_NFCREQUIRED (Noise Floor Required) channel attribute in one of the driver-private flag bits of the net80211 channel o move 900MHz frequency mapping into the hal; the mapped frequency is stored in the private channel and used throughout the hal (no more mapping in the driver and/or net80211) o remove ath_hal_mhz2ieee; it's no longer needed as net80211 does the calculation and available in the net80211 channel o change noise floor calibration logic to work with compacted private channel table setup; this may require revisiting as we no longer can distinguish channel attributes (e.g. 11b vs 11g vs turbo) but since the data is used only to calculate status data we can live with it for now o change ah_getChipPowerLimits internal method to operate on a single channel instead of all channels in the private channel table o add ath_hal_gethwchannel to map a net80211 channel to a h/w frequency (always the same except for 900MHz channels) o add HAL_EEBADREG and HAL_EEBADCC status codes to better identify regulatory problems o remove CTRY_DEBUG and CTRY_DEFAULT enum's; these come from net80211 now o change ath_hal_getwirelessmodes to really return wireless modes supported by the hardware (was previously applying regulatory constraints) o return channel interference status with IEEE80211_CHANSTATE_CWINT (should change to a callback so hal api's can take const pointers) o remove some #define's no longer needed with the inclusion of <net80211/_ieee80211.h> Sponsored by: Carlson Wireless
2009-01-28 18:00:22 +00:00
ath_setregdomain(struct ieee80211com *ic, struct ieee80211_regdomain *reg,
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
int nchans, struct ieee80211_channel chans[])
{
Remove most of the references of ifp->if_softc and replace with references to ic->ic_softc. This is in preparation for gleb's ifnet work. Tested: * ath(4), STA mode * ath(4), hostap mode * make universe
2015-08-17 02:04:11 +00:00
struct ath_softc *sc = ic->ic_softc;
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
struct ath_hal *ah = sc->sc_ah;
Overhaul regulatory support: o remove HAL_CHANNEL; convert the hal to use net80211 channels; this mostly involves mechanical changes to variable names and channel attribute macros o gut HAL_CHANNEL_PRIVATE as most of the contents are now redundant with the net80211 channel available o change api for ath_hal_init_channels: no more reglass id's, no more outdoor indication (was a noop), anM contents o add ath_hal_getchannels to have the hal construct a channel list without altering runtime state; this is used to retrieve the calibration list for the device in ath_getradiocaps o add ath_hal_set_channels to take a channel list and regulatory data from above and construct internal state to match (maps frequencies for 900MHz cards, setup for CTL lookups, etc) o compact the private channel table: we keep one private channel per frequency instead of one per HAL_CHANNEL; this gives a big space savings and potentially improves ani and calibration by sharing state (to be seen; didn't see anything in testing); a new config option AH_MAXCHAN controls the table size (default to 96 which was chosen to be ~3x the largest expected size) o shrink ani state and change to mirror private channel table (one entry per frequency indexed by ic_devdata) o move ani state flags to private channel state o remove country codes; use net80211 definitions instead o remove GSM regulatory support; it's no longer needed now that we pass in channel lists from above o consolidate ADHOC_NO_11A attribute with DISALLOW_ADHOC_11A o simplify initial channel list construction based on the EEPROM contents; we preserve country code support for now but may want to just fallback to a WWR sku and dispatch the discovered country code up to user space so the channel list can be constructed using the master regdomain tables o defer to net80211 for max antenna gain o eliminate sorting of internal channel table; now that we use ic_devdata as an index, table lookups are O(1) o remove internal copy of the country code; the public one is sufficient o remove AH_SUPPORT_11D conditional compilation; we always support 11d o remove ath_hal_ispublicsafetysku; not needed any more o remove ath_hal_isgsmsku; no more GSM stuff o move Conformance Test Limit (CTL) state from private channel to a lookup using per-band pointers cached in the private state block o remove regulatory class id support; was unused and belongs in net80211 o fix channel list construction to set IEEE80211_CHAN_NOADHOC, IEEE80211_CHAN_NOHOSTAP, and IEEE80211_CHAN_4MSXMIT o remove private channel flags CHANNEL_DFS and CHANNEL_4MS_LIMIT; these are now set in the constructed net80211 channel o store CHANNEL_NFCREQUIRED (Noise Floor Required) channel attribute in one of the driver-private flag bits of the net80211 channel o move 900MHz frequency mapping into the hal; the mapped frequency is stored in the private channel and used throughout the hal (no more mapping in the driver and/or net80211) o remove ath_hal_mhz2ieee; it's no longer needed as net80211 does the calculation and available in the net80211 channel o change noise floor calibration logic to work with compacted private channel table setup; this may require revisiting as we no longer can distinguish channel attributes (e.g. 11b vs 11g vs turbo) but since the data is used only to calculate status data we can live with it for now o change ah_getChipPowerLimits internal method to operate on a single channel instead of all channels in the private channel table o add ath_hal_gethwchannel to map a net80211 channel to a h/w frequency (always the same except for 900MHz channels) o add HAL_EEBADREG and HAL_EEBADCC status codes to better identify regulatory problems o remove CTRY_DEBUG and CTRY_DEFAULT enum's; these come from net80211 now o change ath_hal_getwirelessmodes to really return wireless modes supported by the hardware (was previously applying regulatory constraints) o return channel interference status with IEEE80211_CHANSTATE_CWINT (should change to a callback so hal api's can take const pointers) o remove some #define's no longer needed with the inclusion of <net80211/_ieee80211.h> Sponsored by: Carlson Wireless
2009-01-28 18:00:22 +00:00
HAL_STATUS status;
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
add regdomain debug msgs
2008-10-27 17:35:09 +00:00
DPRINTF(sc, ATH_DEBUG_REGDOMAIN,
Overhaul regulatory support: o remove HAL_CHANNEL; convert the hal to use net80211 channels; this mostly involves mechanical changes to variable names and channel attribute macros o gut HAL_CHANNEL_PRIVATE as most of the contents are now redundant with the net80211 channel available o change api for ath_hal_init_channels: no more reglass id's, no more outdoor indication (was a noop), anM contents o add ath_hal_getchannels to have the hal construct a channel list without altering runtime state; this is used to retrieve the calibration list for the device in ath_getradiocaps o add ath_hal_set_channels to take a channel list and regulatory data from above and construct internal state to match (maps frequencies for 900MHz cards, setup for CTL lookups, etc) o compact the private channel table: we keep one private channel per frequency instead of one per HAL_CHANNEL; this gives a big space savings and potentially improves ani and calibration by sharing state (to be seen; didn't see anything in testing); a new config option AH_MAXCHAN controls the table size (default to 96 which was chosen to be ~3x the largest expected size) o shrink ani state and change to mirror private channel table (one entry per frequency indexed by ic_devdata) o move ani state flags to private channel state o remove country codes; use net80211 definitions instead o remove GSM regulatory support; it's no longer needed now that we pass in channel lists from above o consolidate ADHOC_NO_11A attribute with DISALLOW_ADHOC_11A o simplify initial channel list construction based on the EEPROM contents; we preserve country code support for now but may want to just fallback to a WWR sku and dispatch the discovered country code up to user space so the channel list can be constructed using the master regdomain tables o defer to net80211 for max antenna gain o eliminate sorting of internal channel table; now that we use ic_devdata as an index, table lookups are O(1) o remove internal copy of the country code; the public one is sufficient o remove AH_SUPPORT_11D conditional compilation; we always support 11d o remove ath_hal_ispublicsafetysku; not needed any more o remove ath_hal_isgsmsku; no more GSM stuff o move Conformance Test Limit (CTL) state from private channel to a lookup using per-band pointers cached in the private state block o remove regulatory class id support; was unused and belongs in net80211 o fix channel list construction to set IEEE80211_CHAN_NOADHOC, IEEE80211_CHAN_NOHOSTAP, and IEEE80211_CHAN_4MSXMIT o remove private channel flags CHANNEL_DFS and CHANNEL_4MS_LIMIT; these are now set in the constructed net80211 channel o store CHANNEL_NFCREQUIRED (Noise Floor Required) channel attribute in one of the driver-private flag bits of the net80211 channel o move 900MHz frequency mapping into the hal; the mapped frequency is stored in the private channel and used throughout the hal (no more mapping in the driver and/or net80211) o remove ath_hal_mhz2ieee; it's no longer needed as net80211 does the calculation and available in the net80211 channel o change noise floor calibration logic to work with compacted private channel table setup; this may require revisiting as we no longer can distinguish channel attributes (e.g. 11b vs 11g vs turbo) but since the data is used only to calculate status data we can live with it for now o change ah_getChipPowerLimits internal method to operate on a single channel instead of all channels in the private channel table o add ath_hal_gethwchannel to map a net80211 channel to a h/w frequency (always the same except for 900MHz channels) o add HAL_EEBADREG and HAL_EEBADCC status codes to better identify regulatory problems o remove CTRY_DEBUG and CTRY_DEFAULT enum's; these come from net80211 now o change ath_hal_getwirelessmodes to really return wireless modes supported by the hardware (was previously applying regulatory constraints) o return channel interference status with IEEE80211_CHANSTATE_CWINT (should change to a callback so hal api's can take const pointers) o remove some #define's no longer needed with the inclusion of <net80211/_ieee80211.h> Sponsored by: Carlson Wireless
2009-01-28 18:00:22 +00:00
"%s: rd %u cc %u location %c%s\n",
__func__, reg->regdomain, reg->country, reg->location,
reg->ecm ? " ecm" : "");
status = ath_hal_set_channels(ah, chans, nchans,
reg->country, reg->regdomain);
if (status != HAL_OK) {
DPRINTF(sc, ATH_DEBUG_REGDOMAIN, "%s: failed, status %u\n",
__func__, status);
return EINVAL; /* XXX */
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
}
Introduce some more DFS related hooks, inspired both by local work and the Atheros reference code. The radar detection code needs to know what the current DFS domain is. Since net80211 doesn't currently know this information, it's extracted from the HAL regulatory domain information. The specifics: * add a new ath_dfs API hook, ath_dfs_init_radar_filters(), which updates the radar filters whenever the regulatory domain changes. * add HAL_DFS_DOMAIN which describes the currently configured DFS domain . * add a new HAL internal variable which tracks the currently configured HAL DFS domain. * add a new HAL capability, HAL_CAP_DFS_DMN, which returns the currently configured HAL DFS domain setting. * update the HAL DFS domain setting whenever the channel setting is updated. Since this isn't currently used by any radar code, these should all be no-ops for existing users. Obtained from: Atheros Submitted by: KBC Networks, sibridge Approved by: re (kib, blanket)
2011-08-08 16:22:42 +00:00
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
return 0;
}
static void
ath_getradiocaps(struct ieee80211com *ic,
change ic_getradiocaps driver callback to include the max # channels so callers know the size of the array passed down
2009-01-27 23:19:36 +00:00
int maxchans, int *nchans, struct ieee80211_channel chans[])
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
{
Remove most of the references of ifp->if_softc and replace with references to ic->ic_softc. This is in preparation for gleb's ifnet work. Tested: * ath(4), STA mode * ath(4), hostap mode * make universe
2015-08-17 02:04:11 +00:00
struct ath_softc *sc = ic->ic_softc;
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
struct ath_hal *ah = sc->sc_ah;
add regdomain debug msgs
2008-10-27 17:35:09 +00:00
Overhaul regulatory support: o remove HAL_CHANNEL; convert the hal to use net80211 channels; this mostly involves mechanical changes to variable names and channel attribute macros o gut HAL_CHANNEL_PRIVATE as most of the contents are now redundant with the net80211 channel available o change api for ath_hal_init_channels: no more reglass id's, no more outdoor indication (was a noop), anM contents o add ath_hal_getchannels to have the hal construct a channel list without altering runtime state; this is used to retrieve the calibration list for the device in ath_getradiocaps o add ath_hal_set_channels to take a channel list and regulatory data from above and construct internal state to match (maps frequencies for 900MHz cards, setup for CTL lookups, etc) o compact the private channel table: we keep one private channel per frequency instead of one per HAL_CHANNEL; this gives a big space savings and potentially improves ani and calibration by sharing state (to be seen; didn't see anything in testing); a new config option AH_MAXCHAN controls the table size (default to 96 which was chosen to be ~3x the largest expected size) o shrink ani state and change to mirror private channel table (one entry per frequency indexed by ic_devdata) o move ani state flags to private channel state o remove country codes; use net80211 definitions instead o remove GSM regulatory support; it's no longer needed now that we pass in channel lists from above o consolidate ADHOC_NO_11A attribute with DISALLOW_ADHOC_11A o simplify initial channel list construction based on the EEPROM contents; we preserve country code support for now but may want to just fallback to a WWR sku and dispatch the discovered country code up to user space so the channel list can be constructed using the master regdomain tables o defer to net80211 for max antenna gain o eliminate sorting of internal channel table; now that we use ic_devdata as an index, table lookups are O(1) o remove internal copy of the country code; the public one is sufficient o remove AH_SUPPORT_11D conditional compilation; we always support 11d o remove ath_hal_ispublicsafetysku; not needed any more o remove ath_hal_isgsmsku; no more GSM stuff o move Conformance Test Limit (CTL) state from private channel to a lookup using per-band pointers cached in the private state block o remove regulatory class id support; was unused and belongs in net80211 o fix channel list construction to set IEEE80211_CHAN_NOADHOC, IEEE80211_CHAN_NOHOSTAP, and IEEE80211_CHAN_4MSXMIT o remove private channel flags CHANNEL_DFS and CHANNEL_4MS_LIMIT; these are now set in the constructed net80211 channel o store CHANNEL_NFCREQUIRED (Noise Floor Required) channel attribute in one of the driver-private flag bits of the net80211 channel o move 900MHz frequency mapping into the hal; the mapped frequency is stored in the private channel and used throughout the hal (no more mapping in the driver and/or net80211) o remove ath_hal_mhz2ieee; it's no longer needed as net80211 does the calculation and available in the net80211 channel o change noise floor calibration logic to work with compacted private channel table setup; this may require revisiting as we no longer can distinguish channel attributes (e.g. 11b vs 11g vs turbo) but since the data is used only to calculate status data we can live with it for now o change ah_getChipPowerLimits internal method to operate on a single channel instead of all channels in the private channel table o add ath_hal_gethwchannel to map a net80211 channel to a h/w frequency (always the same except for 900MHz channels) o add HAL_EEBADREG and HAL_EEBADCC status codes to better identify regulatory problems o remove CTRY_DEBUG and CTRY_DEFAULT enum's; these come from net80211 now o change ath_hal_getwirelessmodes to really return wireless modes supported by the hardware (was previously applying regulatory constraints) o return channel interference status with IEEE80211_CHANSTATE_CWINT (should change to a callback so hal api's can take const pointers) o remove some #define's no longer needed with the inclusion of <net80211/_ieee80211.h> Sponsored by: Carlson Wireless
2009-01-28 18:00:22 +00:00
DPRINTF(sc, ATH_DEBUG_REGDOMAIN, "%s: use rd %u cc %d\n",
__func__, SKU_DEBUG, CTRY_DEFAULT);
add regdomain debug msgs
2008-10-27 17:35:09 +00:00
Overhaul regulatory support: o remove HAL_CHANNEL; convert the hal to use net80211 channels; this mostly involves mechanical changes to variable names and channel attribute macros o gut HAL_CHANNEL_PRIVATE as most of the contents are now redundant with the net80211 channel available o change api for ath_hal_init_channels: no more reglass id's, no more outdoor indication (was a noop), anM contents o add ath_hal_getchannels to have the hal construct a channel list without altering runtime state; this is used to retrieve the calibration list for the device in ath_getradiocaps o add ath_hal_set_channels to take a channel list and regulatory data from above and construct internal state to match (maps frequencies for 900MHz cards, setup for CTL lookups, etc) o compact the private channel table: we keep one private channel per frequency instead of one per HAL_CHANNEL; this gives a big space savings and potentially improves ani and calibration by sharing state (to be seen; didn't see anything in testing); a new config option AH_MAXCHAN controls the table size (default to 96 which was chosen to be ~3x the largest expected size) o shrink ani state and change to mirror private channel table (one entry per frequency indexed by ic_devdata) o move ani state flags to private channel state o remove country codes; use net80211 definitions instead o remove GSM regulatory support; it's no longer needed now that we pass in channel lists from above o consolidate ADHOC_NO_11A attribute with DISALLOW_ADHOC_11A o simplify initial channel list construction based on the EEPROM contents; we preserve country code support for now but may want to just fallback to a WWR sku and dispatch the discovered country code up to user space so the channel list can be constructed using the master regdomain tables o defer to net80211 for max antenna gain o eliminate sorting of internal channel table; now that we use ic_devdata as an index, table lookups are O(1) o remove internal copy of the country code; the public one is sufficient o remove AH_SUPPORT_11D conditional compilation; we always support 11d o remove ath_hal_ispublicsafetysku; not needed any more o remove ath_hal_isgsmsku; no more GSM stuff o move Conformance Test Limit (CTL) state from private channel to a lookup using per-band pointers cached in the private state block o remove regulatory class id support; was unused and belongs in net80211 o fix channel list construction to set IEEE80211_CHAN_NOADHOC, IEEE80211_CHAN_NOHOSTAP, and IEEE80211_CHAN_4MSXMIT o remove private channel flags CHANNEL_DFS and CHANNEL_4MS_LIMIT; these are now set in the constructed net80211 channel o store CHANNEL_NFCREQUIRED (Noise Floor Required) channel attribute in one of the driver-private flag bits of the net80211 channel o move 900MHz frequency mapping into the hal; the mapped frequency is stored in the private channel and used throughout the hal (no more mapping in the driver and/or net80211) o remove ath_hal_mhz2ieee; it's no longer needed as net80211 does the calculation and available in the net80211 channel o change noise floor calibration logic to work with compacted private channel table setup; this may require revisiting as we no longer can distinguish channel attributes (e.g. 11b vs 11g vs turbo) but since the data is used only to calculate status data we can live with it for now o change ah_getChipPowerLimits internal method to operate on a single channel instead of all channels in the private channel table o add ath_hal_gethwchannel to map a net80211 channel to a h/w frequency (always the same except for 900MHz channels) o add HAL_EEBADREG and HAL_EEBADCC status codes to better identify regulatory problems o remove CTRY_DEBUG and CTRY_DEFAULT enum's; these come from net80211 now o change ath_hal_getwirelessmodes to really return wireless modes supported by the hardware (was previously applying regulatory constraints) o return channel interference status with IEEE80211_CHANSTATE_CWINT (should change to a callback so hal api's can take const pointers) o remove some #define's no longer needed with the inclusion of <net80211/_ieee80211.h> Sponsored by: Carlson Wireless
2009-01-28 18:00:22 +00:00
/* XXX check return */
(void) ath_hal_getchannels(ah, chans, maxchans, nchans,
HAL_MODE_ALL, CTRY_DEFAULT, SKU_DEBUG, AH_TRUE);
restore the hal's channel list when doing getradiocaps so it's in sync with the 802.11 layer's list
2008-04-27 22:03:56 +00:00
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
}
static int
ath_getchannels(struct ath_softc *sc)
{
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
struct ieee80211com *ic = &sc->sc_ic;
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
struct ath_hal *ah = sc->sc_ah;
Overhaul regulatory support: o remove HAL_CHANNEL; convert the hal to use net80211 channels; this mostly involves mechanical changes to variable names and channel attribute macros o gut HAL_CHANNEL_PRIVATE as most of the contents are now redundant with the net80211 channel available o change api for ath_hal_init_channels: no more reglass id's, no more outdoor indication (was a noop), anM contents o add ath_hal_getchannels to have the hal construct a channel list without altering runtime state; this is used to retrieve the calibration list for the device in ath_getradiocaps o add ath_hal_set_channels to take a channel list and regulatory data from above and construct internal state to match (maps frequencies for 900MHz cards, setup for CTL lookups, etc) o compact the private channel table: we keep one private channel per frequency instead of one per HAL_CHANNEL; this gives a big space savings and potentially improves ani and calibration by sharing state (to be seen; didn't see anything in testing); a new config option AH_MAXCHAN controls the table size (default to 96 which was chosen to be ~3x the largest expected size) o shrink ani state and change to mirror private channel table (one entry per frequency indexed by ic_devdata) o move ani state flags to private channel state o remove country codes; use net80211 definitions instead o remove GSM regulatory support; it's no longer needed now that we pass in channel lists from above o consolidate ADHOC_NO_11A attribute with DISALLOW_ADHOC_11A o simplify initial channel list construction based on the EEPROM contents; we preserve country code support for now but may want to just fallback to a WWR sku and dispatch the discovered country code up to user space so the channel list can be constructed using the master regdomain tables o defer to net80211 for max antenna gain o eliminate sorting of internal channel table; now that we use ic_devdata as an index, table lookups are O(1) o remove internal copy of the country code; the public one is sufficient o remove AH_SUPPORT_11D conditional compilation; we always support 11d o remove ath_hal_ispublicsafetysku; not needed any more o remove ath_hal_isgsmsku; no more GSM stuff o move Conformance Test Limit (CTL) state from private channel to a lookup using per-band pointers cached in the private state block o remove regulatory class id support; was unused and belongs in net80211 o fix channel list construction to set IEEE80211_CHAN_NOADHOC, IEEE80211_CHAN_NOHOSTAP, and IEEE80211_CHAN_4MSXMIT o remove private channel flags CHANNEL_DFS and CHANNEL_4MS_LIMIT; these are now set in the constructed net80211 channel o store CHANNEL_NFCREQUIRED (Noise Floor Required) channel attribute in one of the driver-private flag bits of the net80211 channel o move 900MHz frequency mapping into the hal; the mapped frequency is stored in the private channel and used throughout the hal (no more mapping in the driver and/or net80211) o remove ath_hal_mhz2ieee; it's no longer needed as net80211 does the calculation and available in the net80211 channel o change noise floor calibration logic to work with compacted private channel table setup; this may require revisiting as we no longer can distinguish channel attributes (e.g. 11b vs 11g vs turbo) but since the data is used only to calculate status data we can live with it for now o change ah_getChipPowerLimits internal method to operate on a single channel instead of all channels in the private channel table o add ath_hal_gethwchannel to map a net80211 channel to a h/w frequency (always the same except for 900MHz channels) o add HAL_EEBADREG and HAL_EEBADCC status codes to better identify regulatory problems o remove CTRY_DEBUG and CTRY_DEFAULT enum's; these come from net80211 now o change ath_hal_getwirelessmodes to really return wireless modes supported by the hardware (was previously applying regulatory constraints) o return channel interference status with IEEE80211_CHANSTATE_CWINT (should change to a callback so hal api's can take const pointers) o remove some #define's no longer needed with the inclusion of <net80211/_ieee80211.h> Sponsored by: Carlson Wireless
2009-01-28 18:00:22 +00:00
HAL_STATUS status;
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
/*
Overhaul regulatory support: o remove HAL_CHANNEL; convert the hal to use net80211 channels; this mostly involves mechanical changes to variable names and channel attribute macros o gut HAL_CHANNEL_PRIVATE as most of the contents are now redundant with the net80211 channel available o change api for ath_hal_init_channels: no more reglass id's, no more outdoor indication (was a noop), anM contents o add ath_hal_getchannels to have the hal construct a channel list without altering runtime state; this is used to retrieve the calibration list for the device in ath_getradiocaps o add ath_hal_set_channels to take a channel list and regulatory data from above and construct internal state to match (maps frequencies for 900MHz cards, setup for CTL lookups, etc) o compact the private channel table: we keep one private channel per frequency instead of one per HAL_CHANNEL; this gives a big space savings and potentially improves ani and calibration by sharing state (to be seen; didn't see anything in testing); a new config option AH_MAXCHAN controls the table size (default to 96 which was chosen to be ~3x the largest expected size) o shrink ani state and change to mirror private channel table (one entry per frequency indexed by ic_devdata) o move ani state flags to private channel state o remove country codes; use net80211 definitions instead o remove GSM regulatory support; it's no longer needed now that we pass in channel lists from above o consolidate ADHOC_NO_11A attribute with DISALLOW_ADHOC_11A o simplify initial channel list construction based on the EEPROM contents; we preserve country code support for now but may want to just fallback to a WWR sku and dispatch the discovered country code up to user space so the channel list can be constructed using the master regdomain tables o defer to net80211 for max antenna gain o eliminate sorting of internal channel table; now that we use ic_devdata as an index, table lookups are O(1) o remove internal copy of the country code; the public one is sufficient o remove AH_SUPPORT_11D conditional compilation; we always support 11d o remove ath_hal_ispublicsafetysku; not needed any more o remove ath_hal_isgsmsku; no more GSM stuff o move Conformance Test Limit (CTL) state from private channel to a lookup using per-band pointers cached in the private state block o remove regulatory class id support; was unused and belongs in net80211 o fix channel list construction to set IEEE80211_CHAN_NOADHOC, IEEE80211_CHAN_NOHOSTAP, and IEEE80211_CHAN_4MSXMIT o remove private channel flags CHANNEL_DFS and CHANNEL_4MS_LIMIT; these are now set in the constructed net80211 channel o store CHANNEL_NFCREQUIRED (Noise Floor Required) channel attribute in one of the driver-private flag bits of the net80211 channel o move 900MHz frequency mapping into the hal; the mapped frequency is stored in the private channel and used throughout the hal (no more mapping in the driver and/or net80211) o remove ath_hal_mhz2ieee; it's no longer needed as net80211 does the calculation and available in the net80211 channel o change noise floor calibration logic to work with compacted private channel table setup; this may require revisiting as we no longer can distinguish channel attributes (e.g. 11b vs 11g vs turbo) but since the data is used only to calculate status data we can live with it for now o change ah_getChipPowerLimits internal method to operate on a single channel instead of all channels in the private channel table o add ath_hal_gethwchannel to map a net80211 channel to a h/w frequency (always the same except for 900MHz channels) o add HAL_EEBADREG and HAL_EEBADCC status codes to better identify regulatory problems o remove CTRY_DEBUG and CTRY_DEFAULT enum's; these come from net80211 now o change ath_hal_getwirelessmodes to really return wireless modes supported by the hardware (was previously applying regulatory constraints) o return channel interference status with IEEE80211_CHANSTATE_CWINT (should change to a callback so hal api's can take const pointers) o remove some #define's no longer needed with the inclusion of <net80211/_ieee80211.h> Sponsored by: Carlson Wireless
2009-01-28 18:00:22 +00:00
* Collect channel set based on EEPROM contents.
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
*/
Overhaul regulatory support: o remove HAL_CHANNEL; convert the hal to use net80211 channels; this mostly involves mechanical changes to variable names and channel attribute macros o gut HAL_CHANNEL_PRIVATE as most of the contents are now redundant with the net80211 channel available o change api for ath_hal_init_channels: no more reglass id's, no more outdoor indication (was a noop), anM contents o add ath_hal_getchannels to have the hal construct a channel list without altering runtime state; this is used to retrieve the calibration list for the device in ath_getradiocaps o add ath_hal_set_channels to take a channel list and regulatory data from above and construct internal state to match (maps frequencies for 900MHz cards, setup for CTL lookups, etc) o compact the private channel table: we keep one private channel per frequency instead of one per HAL_CHANNEL; this gives a big space savings and potentially improves ani and calibration by sharing state (to be seen; didn't see anything in testing); a new config option AH_MAXCHAN controls the table size (default to 96 which was chosen to be ~3x the largest expected size) o shrink ani state and change to mirror private channel table (one entry per frequency indexed by ic_devdata) o move ani state flags to private channel state o remove country codes; use net80211 definitions instead o remove GSM regulatory support; it's no longer needed now that we pass in channel lists from above o consolidate ADHOC_NO_11A attribute with DISALLOW_ADHOC_11A o simplify initial channel list construction based on the EEPROM contents; we preserve country code support for now but may want to just fallback to a WWR sku and dispatch the discovered country code up to user space so the channel list can be constructed using the master regdomain tables o defer to net80211 for max antenna gain o eliminate sorting of internal channel table; now that we use ic_devdata as an index, table lookups are O(1) o remove internal copy of the country code; the public one is sufficient o remove AH_SUPPORT_11D conditional compilation; we always support 11d o remove ath_hal_ispublicsafetysku; not needed any more o remove ath_hal_isgsmsku; no more GSM stuff o move Conformance Test Limit (CTL) state from private channel to a lookup using per-band pointers cached in the private state block o remove regulatory class id support; was unused and belongs in net80211 o fix channel list construction to set IEEE80211_CHAN_NOADHOC, IEEE80211_CHAN_NOHOSTAP, and IEEE80211_CHAN_4MSXMIT o remove private channel flags CHANNEL_DFS and CHANNEL_4MS_LIMIT; these are now set in the constructed net80211 channel o store CHANNEL_NFCREQUIRED (Noise Floor Required) channel attribute in one of the driver-private flag bits of the net80211 channel o move 900MHz frequency mapping into the hal; the mapped frequency is stored in the private channel and used throughout the hal (no more mapping in the driver and/or net80211) o remove ath_hal_mhz2ieee; it's no longer needed as net80211 does the calculation and available in the net80211 channel o change noise floor calibration logic to work with compacted private channel table setup; this may require revisiting as we no longer can distinguish channel attributes (e.g. 11b vs 11g vs turbo) but since the data is used only to calculate status data we can live with it for now o change ah_getChipPowerLimits internal method to operate on a single channel instead of all channels in the private channel table o add ath_hal_gethwchannel to map a net80211 channel to a h/w frequency (always the same except for 900MHz channels) o add HAL_EEBADREG and HAL_EEBADCC status codes to better identify regulatory problems o remove CTRY_DEBUG and CTRY_DEFAULT enum's; these come from net80211 now o change ath_hal_getwirelessmodes to really return wireless modes supported by the hardware (was previously applying regulatory constraints) o return channel interference status with IEEE80211_CHANSTATE_CWINT (should change to a callback so hal api's can take const pointers) o remove some #define's no longer needed with the inclusion of <net80211/_ieee80211.h> Sponsored by: Carlson Wireless
2009-01-28 18:00:22 +00:00
status = ath_hal_init_channels(ah, ic->ic_channels, IEEE80211_CHAN_MAX,
&ic->ic_nchans, HAL_MODE_ALL, CTRY_DEFAULT, SKU_NONE, AH_TRUE);
if (status != HAL_OK) {
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
device_printf(sc->sc_dev,
"%s: unable to collect channel list from hal, status %d\n",
__func__, status);
Overhaul regulatory support: o remove HAL_CHANNEL; convert the hal to use net80211 channels; this mostly involves mechanical changes to variable names and channel attribute macros o gut HAL_CHANNEL_PRIVATE as most of the contents are now redundant with the net80211 channel available o change api for ath_hal_init_channels: no more reglass id's, no more outdoor indication (was a noop), anM contents o add ath_hal_getchannels to have the hal construct a channel list without altering runtime state; this is used to retrieve the calibration list for the device in ath_getradiocaps o add ath_hal_set_channels to take a channel list and regulatory data from above and construct internal state to match (maps frequencies for 900MHz cards, setup for CTL lookups, etc) o compact the private channel table: we keep one private channel per frequency instead of one per HAL_CHANNEL; this gives a big space savings and potentially improves ani and calibration by sharing state (to be seen; didn't see anything in testing); a new config option AH_MAXCHAN controls the table size (default to 96 which was chosen to be ~3x the largest expected size) o shrink ani state and change to mirror private channel table (one entry per frequency indexed by ic_devdata) o move ani state flags to private channel state o remove country codes; use net80211 definitions instead o remove GSM regulatory support; it's no longer needed now that we pass in channel lists from above o consolidate ADHOC_NO_11A attribute with DISALLOW_ADHOC_11A o simplify initial channel list construction based on the EEPROM contents; we preserve country code support for now but may want to just fallback to a WWR sku and dispatch the discovered country code up to user space so the channel list can be constructed using the master regdomain tables o defer to net80211 for max antenna gain o eliminate sorting of internal channel table; now that we use ic_devdata as an index, table lookups are O(1) o remove internal copy of the country code; the public one is sufficient o remove AH_SUPPORT_11D conditional compilation; we always support 11d o remove ath_hal_ispublicsafetysku; not needed any more o remove ath_hal_isgsmsku; no more GSM stuff o move Conformance Test Limit (CTL) state from private channel to a lookup using per-band pointers cached in the private state block o remove regulatory class id support; was unused and belongs in net80211 o fix channel list construction to set IEEE80211_CHAN_NOADHOC, IEEE80211_CHAN_NOHOSTAP, and IEEE80211_CHAN_4MSXMIT o remove private channel flags CHANNEL_DFS and CHANNEL_4MS_LIMIT; these are now set in the constructed net80211 channel o store CHANNEL_NFCREQUIRED (Noise Floor Required) channel attribute in one of the driver-private flag bits of the net80211 channel o move 900MHz frequency mapping into the hal; the mapped frequency is stored in the private channel and used throughout the hal (no more mapping in the driver and/or net80211) o remove ath_hal_mhz2ieee; it's no longer needed as net80211 does the calculation and available in the net80211 channel o change noise floor calibration logic to work with compacted private channel table setup; this may require revisiting as we no longer can distinguish channel attributes (e.g. 11b vs 11g vs turbo) but since the data is used only to calculate status data we can live with it for now o change ah_getChipPowerLimits internal method to operate on a single channel instead of all channels in the private channel table o add ath_hal_gethwchannel to map a net80211 channel to a h/w frequency (always the same except for 900MHz channels) o add HAL_EEBADREG and HAL_EEBADCC status codes to better identify regulatory problems o remove CTRY_DEBUG and CTRY_DEFAULT enum's; these come from net80211 now o change ath_hal_getwirelessmodes to really return wireless modes supported by the hardware (was previously applying regulatory constraints) o return channel interference status with IEEE80211_CHANSTATE_CWINT (should change to a callback so hal api's can take const pointers) o remove some #define's no longer needed with the inclusion of <net80211/_ieee80211.h> Sponsored by: Carlson Wireless
2009-01-28 18:00:22 +00:00
return EINVAL;
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
}
Overhaul regulatory support: o remove HAL_CHANNEL; convert the hal to use net80211 channels; this mostly involves mechanical changes to variable names and channel attribute macros o gut HAL_CHANNEL_PRIVATE as most of the contents are now redundant with the net80211 channel available o change api for ath_hal_init_channels: no more reglass id's, no more outdoor indication (was a noop), anM contents o add ath_hal_getchannels to have the hal construct a channel list without altering runtime state; this is used to retrieve the calibration list for the device in ath_getradiocaps o add ath_hal_set_channels to take a channel list and regulatory data from above and construct internal state to match (maps frequencies for 900MHz cards, setup for CTL lookups, etc) o compact the private channel table: we keep one private channel per frequency instead of one per HAL_CHANNEL; this gives a big space savings and potentially improves ani and calibration by sharing state (to be seen; didn't see anything in testing); a new config option AH_MAXCHAN controls the table size (default to 96 which was chosen to be ~3x the largest expected size) o shrink ani state and change to mirror private channel table (one entry per frequency indexed by ic_devdata) o move ani state flags to private channel state o remove country codes; use net80211 definitions instead o remove GSM regulatory support; it's no longer needed now that we pass in channel lists from above o consolidate ADHOC_NO_11A attribute with DISALLOW_ADHOC_11A o simplify initial channel list construction based on the EEPROM contents; we preserve country code support for now but may want to just fallback to a WWR sku and dispatch the discovered country code up to user space so the channel list can be constructed using the master regdomain tables o defer to net80211 for max antenna gain o eliminate sorting of internal channel table; now that we use ic_devdata as an index, table lookups are O(1) o remove internal copy of the country code; the public one is sufficient o remove AH_SUPPORT_11D conditional compilation; we always support 11d o remove ath_hal_ispublicsafetysku; not needed any more o remove ath_hal_isgsmsku; no more GSM stuff o move Conformance Test Limit (CTL) state from private channel to a lookup using per-band pointers cached in the private state block o remove regulatory class id support; was unused and belongs in net80211 o fix channel list construction to set IEEE80211_CHAN_NOADHOC, IEEE80211_CHAN_NOHOSTAP, and IEEE80211_CHAN_4MSXMIT o remove private channel flags CHANNEL_DFS and CHANNEL_4MS_LIMIT; these are now set in the constructed net80211 channel o store CHANNEL_NFCREQUIRED (Noise Floor Required) channel attribute in one of the driver-private flag bits of the net80211 channel o move 900MHz frequency mapping into the hal; the mapped frequency is stored in the private channel and used throughout the hal (no more mapping in the driver and/or net80211) o remove ath_hal_mhz2ieee; it's no longer needed as net80211 does the calculation and available in the net80211 channel o change noise floor calibration logic to work with compacted private channel table setup; this may require revisiting as we no longer can distinguish channel attributes (e.g. 11b vs 11g vs turbo) but since the data is used only to calculate status data we can live with it for now o change ah_getChipPowerLimits internal method to operate on a single channel instead of all channels in the private channel table o add ath_hal_gethwchannel to map a net80211 channel to a h/w frequency (always the same except for 900MHz channels) o add HAL_EEBADREG and HAL_EEBADCC status codes to better identify regulatory problems o remove CTRY_DEBUG and CTRY_DEFAULT enum's; these come from net80211 now o change ath_hal_getwirelessmodes to really return wireless modes supported by the hardware (was previously applying regulatory constraints) o return channel interference status with IEEE80211_CHANSTATE_CWINT (should change to a callback so hal api's can take const pointers) o remove some #define's no longer needed with the inclusion of <net80211/_ieee80211.h> Sponsored by: Carlson Wireless
2009-01-28 18:00:22 +00:00
(void) ath_hal_getregdomain(ah, &sc->sc_eerd);
ath_hal_getcountrycode(ah, &sc->sc_eecc); /* NB: cannot fail */
/* XXX map Atheros sku's to net80211 SKU's */
/* XXX net80211 types too small */
ic->ic_regdomain.regdomain = (uint16_t) sc->sc_eerd;
ic->ic_regdomain.country = (uint16_t) sc->sc_eecc;
ic->ic_regdomain.isocc[0] = ' '; /* XXX don't know */
ic->ic_regdomain.isocc[1] = ' ';
Multi-bss (aka vap) support for 802.11 devices. Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
2008-04-20 20:35:46 +00:00
ic->ic_regdomain.ecm = 1;
ic->ic_regdomain.location = 'I';
add regdomain debug msgs
2008-10-27 17:35:09 +00:00
DPRINTF(sc, ATH_DEBUG_REGDOMAIN,
Overhaul regulatory support: o remove HAL_CHANNEL; convert the hal to use net80211 channels; this mostly involves mechanical changes to variable names and channel attribute macros o gut HAL_CHANNEL_PRIVATE as most of the contents are now redundant with the net80211 channel available o change api for ath_hal_init_channels: no more reglass id's, no more outdoor indication (was a noop), anM contents o add ath_hal_getchannels to have the hal construct a channel list without altering runtime state; this is used to retrieve the calibration list for the device in ath_getradiocaps o add ath_hal_set_channels to take a channel list and regulatory data from above and construct internal state to match (maps frequencies for 900MHz cards, setup for CTL lookups, etc) o compact the private channel table: we keep one private channel per frequency instead of one per HAL_CHANNEL; this gives a big space savings and potentially improves ani and calibration by sharing state (to be seen; didn't see anything in testing); a new config option AH_MAXCHAN controls the table size (default to 96 which was chosen to be ~3x the largest expected size) o shrink ani state and change to mirror private channel table (one entry per frequency indexed by ic_devdata) o move ani state flags to private channel state o remove country codes; use net80211 definitions instead o remove GSM regulatory support; it's no longer needed now that we pass in channel lists from above o consolidate ADHOC_NO_11A attribute with DISALLOW_ADHOC_11A o simplify initial channel list construction based on the EEPROM contents; we preserve country code support for now but may want to just fallback to a WWR sku and dispatch the discovered country code up to user space so the channel list can be constructed using the master regdomain tables o defer to net80211 for max antenna gain o eliminate sorting of internal channel table; now that we use ic_devdata as an index, table lookups are O(1) o remove internal copy of the country code; the public one is sufficient o remove AH_SUPPORT_11D conditional compilation; we always support 11d o remove ath_hal_ispublicsafetysku; not needed any more o remove ath_hal_isgsmsku; no more GSM stuff o move Conformance Test Limit (CTL) state from private channel to a lookup using per-band pointers cached in the private state block o remove regulatory class id support; was unused and belongs in net80211 o fix channel list construction to set IEEE80211_CHAN_NOADHOC, IEEE80211_CHAN_NOHOSTAP, and IEEE80211_CHAN_4MSXMIT o remove private channel flags CHANNEL_DFS and CHANNEL_4MS_LIMIT; these are now set in the constructed net80211 channel o store CHANNEL_NFCREQUIRED (Noise Floor Required) channel attribute in one of the driver-private flag bits of the net80211 channel o move 900MHz frequency mapping into the hal; the mapped frequency is stored in the private channel and used throughout the hal (no more mapping in the driver and/or net80211) o remove ath_hal_mhz2ieee; it's no longer needed as net80211 does the calculation and available in the net80211 channel o change noise floor calibration logic to work with compacted private channel table setup; this may require revisiting as we no longer can distinguish channel attributes (e.g. 11b vs 11g vs turbo) but since the data is used only to calculate status data we can live with it for now o change ah_getChipPowerLimits internal method to operate on a single channel instead of all channels in the private channel table o add ath_hal_gethwchannel to map a net80211 channel to a h/w frequency (always the same except for 900MHz channels) o add HAL_EEBADREG and HAL_EEBADCC status codes to better identify regulatory problems o remove CTRY_DEBUG and CTRY_DEFAULT enum's; these come from net80211 now o change ath_hal_getwirelessmodes to really return wireless modes supported by the hardware (was previously applying regulatory constraints) o return channel interference status with IEEE80211_CHANSTATE_CWINT (should change to a callback so hal api's can take const pointers) o remove some #define's no longer needed with the inclusion of <net80211/_ieee80211.h> Sponsored by: Carlson Wireless
2009-01-28 18:00:22 +00:00
"%s: eeprom rd %u cc %u (mapped rd %u cc %u) location %c%s\n",
add regdomain debug msgs
2008-10-27 17:35:09 +00:00
__func__, sc->sc_eerd, sc->sc_eecc,
ic->ic_regdomain.regdomain, ic->ic_regdomain.country,
Overhaul regulatory support: o remove HAL_CHANNEL; convert the hal to use net80211 channels; this mostly involves mechanical changes to variable names and channel attribute macros o gut HAL_CHANNEL_PRIVATE as most of the contents are now redundant with the net80211 channel available o change api for ath_hal_init_channels: no more reglass id's, no more outdoor indication (was a noop), anM contents o add ath_hal_getchannels to have the hal construct a channel list without altering runtime state; this is used to retrieve the calibration list for the device in ath_getradiocaps o add ath_hal_set_channels to take a channel list and regulatory data from above and construct internal state to match (maps frequencies for 900MHz cards, setup for CTL lookups, etc) o compact the private channel table: we keep one private channel per frequency instead of one per HAL_CHANNEL; this gives a big space savings and potentially improves ani and calibration by sharing state (to be seen; didn't see anything in testing); a new config option AH_MAXCHAN controls the table size (default to 96 which was chosen to be ~3x the largest expected size) o shrink ani state and change to mirror private channel table (one entry per frequency indexed by ic_devdata) o move ani state flags to private channel state o remove country codes; use net80211 definitions instead o remove GSM regulatory support; it's no longer needed now that we pass in channel lists from above o consolidate ADHOC_NO_11A attribute with DISALLOW_ADHOC_11A o simplify initial channel list construction based on the EEPROM contents; we preserve country code support for now but may want to just fallback to a WWR sku and dispatch the discovered country code up to user space so the channel list can be constructed using the master regdomain tables o defer to net80211 for max antenna gain o eliminate sorting of internal channel table; now that we use ic_devdata as an index, table lookups are O(1) o remove internal copy of the country code; the public one is sufficient o remove AH_SUPPORT_11D conditional compilation; we always support 11d o remove ath_hal_ispublicsafetysku; not needed any more o remove ath_hal_isgsmsku; no more GSM stuff o move Conformance Test Limit (CTL) state from private channel to a lookup using per-band pointers cached in the private state block o remove regulatory class id support; was unused and belongs in net80211 o fix channel list construction to set IEEE80211_CHAN_NOADHOC, IEEE80211_CHAN_NOHOSTAP, and IEEE80211_CHAN_4MSXMIT o remove private channel flags CHANNEL_DFS and CHANNEL_4MS_LIMIT; these are now set in the constructed net80211 channel o store CHANNEL_NFCREQUIRED (Noise Floor Required) channel attribute in one of the driver-private flag bits of the net80211 channel o move 900MHz frequency mapping into the hal; the mapped frequency is stored in the private channel and used throughout the hal (no more mapping in the driver and/or net80211) o remove ath_hal_mhz2ieee; it's no longer needed as net80211 does the calculation and available in the net80211 channel o change noise floor calibration logic to work with compacted private channel table setup; this may require revisiting as we no longer can distinguish channel attributes (e.g. 11b vs 11g vs turbo) but since the data is used only to calculate status data we can live with it for now o change ah_getChipPowerLimits internal method to operate on a single channel instead of all channels in the private channel table o add ath_hal_gethwchannel to map a net80211 channel to a h/w frequency (always the same except for 900MHz channels) o add HAL_EEBADREG and HAL_EEBADCC status codes to better identify regulatory problems o remove CTRY_DEBUG and CTRY_DEFAULT enum's; these come from net80211 now o change ath_hal_getwirelessmodes to really return wireless modes supported by the hardware (was previously applying regulatory constraints) o return channel interference status with IEEE80211_CHANSTATE_CWINT (should change to a callback so hal api's can take const pointers) o remove some #define's no longer needed with the inclusion of <net80211/_ieee80211.h> Sponsored by: Carlson Wireless
2009-01-28 18:00:22 +00:00
ic->ic_regdomain.location, ic->ic_regdomain.ecm ? " ecm" : "");
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
return 0;
}
static int
ath_rate_setup(struct ath_softc *sc, u_int mode)
{
struct ath_hal *ah = sc->sc_ah;
const HAL_RATE_TABLE *rt;
switch (mode) {
case IEEE80211_MODE_11A:
cleanup rate setup MFC after: 2 weeks
2006-02-09 21:31:48 +00:00
rt = ath_hal_getratetable(ah, HAL_MODE_11A);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
break;
Add initial support for 900MHz cards like the Ubiquiti SR9: o eliminate assumptions that half/quarter rate channels on exist in 11a o handle frequency mapping between hal and net80211; hal gives us freq's in the range 2422..2437 that we remap MFC after: 1 month
2007-01-15 01:15:57 +00:00
case IEEE80211_MODE_HALF:
Add half/quarter rate 11a channel support: o change handling of regdomain-related mib knobs so they can be set post-attach: regdomain, countrycode, outdoor, and xchanmode; the hal will not permit changing the regdomain but we expose it for now o on regdomain/countrycode change recalculate the channel list and push it to the net80211 layer (NB: looks to need more tweaking) o setup rate tables for half/quarter rate channels o honor half/quarter rate channel configs when changing channels o honor half/quarter rate channel configs when setting the slot time o use hack/nonstandard channel numbering scheme for the public safety band to avoid overlapping 2.4G channels on dual-band cards o remove setup of ic_sup_rates; the net80211 layer can do this for us and it simplifies handling of half/quarter rate channels Tested only in Public Safety Band with cards that have RF5112.
2006-12-27 19:07:09 +00:00
rt = ath_hal_getratetable(ah, HAL_MODE_11A_HALF_RATE);
break;
Add initial support for 900MHz cards like the Ubiquiti SR9: o eliminate assumptions that half/quarter rate channels on exist in 11a o handle frequency mapping between hal and net80211; hal gives us freq's in the range 2422..2437 that we remap MFC after: 1 month
2007-01-15 01:15:57 +00:00
case IEEE80211_MODE_QUARTER:
Add half/quarter rate 11a channel support: o change handling of regdomain-related mib knobs so they can be set post-attach: regdomain, countrycode, outdoor, and xchanmode; the hal will not permit changing the regdomain but we expose it for now o on regdomain/countrycode change recalculate the channel list and push it to the net80211 layer (NB: looks to need more tweaking) o setup rate tables for half/quarter rate channels o honor half/quarter rate channel configs when changing channels o honor half/quarter rate channel configs when setting the slot time o use hack/nonstandard channel numbering scheme for the public safety band to avoid overlapping 2.4G channels on dual-band cards o remove setup of ic_sup_rates; the net80211 layer can do this for us and it simplifies handling of half/quarter rate channels Tested only in Public Safety Band with cards that have RF5112.
2006-12-27 19:07:09 +00:00
rt = ath_hal_getratetable(ah, HAL_MODE_11A_QUARTER_RATE);
break;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
case IEEE80211_MODE_11B:
cleanup rate setup MFC after: 2 weeks
2006-02-09 21:31:48 +00:00
rt = ath_hal_getratetable(ah, HAL_MODE_11B);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
break;
case IEEE80211_MODE_11G:
cleanup rate setup MFC after: 2 weeks
2006-02-09 21:31:48 +00:00
rt = ath_hal_getratetable(ah, HAL_MODE_11G);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
break;
Update with last year of work.
2004-12-08 17:34:36 +00:00
case IEEE80211_MODE_TURBO_A:
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
rt = ath_hal_getratetable(ah, HAL_MODE_108A);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
break;
Update with last year of work.
2004-12-08 17:34:36 +00:00
case IEEE80211_MODE_TURBO_G:
cleanup rate setup MFC after: 2 weeks
2006-02-09 21:31:48 +00:00
rt = ath_hal_getratetable(ah, HAL_MODE_108G);
Update with last year of work.
2004-12-08 17:34:36 +00:00
break;
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
case IEEE80211_MODE_STURBO_A:
rt = ath_hal_getratetable(ah, HAL_MODE_TURBO);
break;
case IEEE80211_MODE_11NA:
rt = ath_hal_getratetable(ah, HAL_MODE_11NA_HT20);
break;
case IEEE80211_MODE_11NG:
rt = ath_hal_getratetable(ah, HAL_MODE_11NG_HT20);
break;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
default:
Update with last year of work.
2004-12-08 17:34:36 +00:00
DPRINTF(sc, ATH_DEBUG_ANY, "%s: invalid mode %u\n",
__func__, mode);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
return 0;
}
cleanup rate setup MFC after: 2 weeks
2006-02-09 21:31:48 +00:00
sc->sc_rates[mode] = rt;
Add half/quarter rate 11a channel support: o change handling of regdomain-related mib knobs so they can be set post-attach: regdomain, countrycode, outdoor, and xchanmode; the hal will not permit changing the regdomain but we expose it for now o on regdomain/countrycode change recalculate the channel list and push it to the net80211 layer (NB: looks to need more tweaking) o setup rate tables for half/quarter rate channels o honor half/quarter rate channel configs when changing channels o honor half/quarter rate channel configs when setting the slot time o use hack/nonstandard channel numbering scheme for the public safety band to avoid overlapping 2.4G channels on dual-band cards o remove setup of ic_sup_rates; the net80211 layer can do this for us and it simplifies handling of half/quarter rate channels Tested only in Public Safety Band with cards that have RF5112.
2006-12-27 19:07:09 +00:00
return (rt != NULL);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
static void
ath_setcurmode(struct ath_softc *sc, enum ieee80211_phymode mode)
{
better led blinking
2005-01-18 19:03:04 +00:00
/* NB: on/off times from the Atheros NDIS driver, w/ permission */
static const struct {
u_int rate; /* tx/rx 802.11 rate */
u_int16_t timeOn; /* LED on time (ms) */
u_int16_t timeOff; /* LED off time (ms) */
} blinkrates[] = {
{ 108, 40, 10 },
{ 96, 44, 11 },
{ 72, 50, 13 },
{ 48, 57, 14 },
{ 36, 67, 16 },
{ 24, 80, 20 },
{ 22, 100, 25 },
{ 18, 133, 34 },
{ 12, 160, 40 },
{ 10, 200, 50 },
{ 6, 240, 58 },
{ 4, 267, 66 },
{ 2, 400, 100 },
{ 0, 500, 130 },
Add initial support for 900MHz cards like the Ubiquiti SR9: o eliminate assumptions that half/quarter rate channels on exist in 11a o handle frequency mapping between hal and net80211; hal gives us freq's in the range 2422..2437 that we remap MFC after: 1 month
2007-01-15 01:15:57 +00:00
/* XXX half/quarter rates */
better led blinking
2005-01-18 19:03:04 +00:00
};
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
const HAL_RATE_TABLE *rt;
better led blinking
2005-01-18 19:03:04 +00:00
int i, j;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
memset(sc->sc_rixmap, 0xff, sizeof(sc->sc_rixmap));
rt = sc->sc_rates[mode];
KASSERT(rt != NULL, ("no h/w rate set for phy mode %u", mode));
fix handling of HT rates; these overlap legacy rates and need to be marked as MCS in the inverse mapping table
2008-10-27 18:02:47 +00:00
for (i = 0; i < rt->rateCount; i++) {
uint8_t ieeerate = rt->info[i].dot11Rate & IEEE80211_RATE_VAL;
if (rt->info[i].phy != IEEE80211_T_HT)
sc->sc_rixmap[ieeerate] = i;
else
sc->sc_rixmap[ieeerate | IEEE80211_RATE_MCS] = i;
}
maintain a table for mapping hardware rate codes to 802.11 rates for calculating the rate for each rx'd frame
2003-08-19 21:24:16 +00:00
memset(sc->sc_hwmap, 0, sizeof(sc->sc_hwmap));
net80211 & wireless drivers: remove duplicate defines (noop) * IEEE80211_DIR_DSTODS(wh) -> IEEE80211_IS_DSTODS(wh). * N(a) -> nitems(a). * Remove LE_READ_2(p)/LE_READ_4(p) definitions (and include ieee80211_input.h instead). * <drvname>_TXOP_TO_US(txop) -> IEEE80211_TXOP_TO_US(txop). * Put IEEE80211_RV(v) into ieee80211_proto.h and remove local RV(v) definitions. Submitted by: Andriy Voskoboinyk <s3erios@gmail.com> Differential Revision: https://reviews.freebsd.org/D3705
2015-09-22 02:44:59 +00:00
for (i = 0; i < nitems(sc->sc_hwmap); i++) {
o With the addition of HT rates the set of h/w codes has a much wider range making the use of sc_hwmap to do direct mapping impractical. Switch to indexing by the rate index instead of the rate code and adjust associated state and logic appropriately. This has several benefits including simplification of the led code. o fix radiotap capture of HT rates o fix conditional compilation of HT radiotap support to be based on the hal having 5416 support; not the ABI version as hal builds may or may not include 5416 support
2008-10-27 18:22:44 +00:00
if (i >= rt->rateCount) {
better led blinking
2005-01-18 19:03:04 +00:00
sc->sc_hwmap[i].ledon = (500 * hz) / 1000;
sc->sc_hwmap[i].ledoff = (130 * hz) / 1000;
Radiotap fixups: o catch one place where we were not using ath_chan_change to switch channels; this fixes a problem where the channel settings were not being correctly reported in captured packets o return unique channel identification in the channel flags; ethereal gets confused if you return merged flags (e.g. ofdm, cck, and 2Ghz) (this is workaround and should be removed if we can ever cleanup radiotap consumers) o correct short/long preamble flag state for rx and treat tx the same--use a new hwflags array that gives us the data based on the h/w rate index/cookie o add gross hack to handle radiotap capture of frames that come in with hardware padding; should be replaced by a flag in the radiotap header and more smarts in the apps that decode radiotap data
2004-12-31 20:32:40 +00:00
continue;
better led blinking
2005-01-18 19:03:04 +00:00
}
sc->sc_hwmap[i].ieeerate =
o With the addition of HT rates the set of h/w codes has a much wider range making the use of sc_hwmap to do direct mapping impractical. Switch to indexing by the rate index instead of the rate code and adjust associated state and logic appropriately. This has several benefits including simplification of the led code. o fix radiotap capture of HT rates o fix conditional compilation of HT radiotap support to be based on the hal having 5416 support; not the ABI version as hal builds may or may not include 5416 support
2008-10-27 18:22:44 +00:00
rt->info[i].dot11Rate & IEEE80211_RATE_VAL;
if (rt->info[i].phy == IEEE80211_T_HT)
prefer #define to naked constant
2008-10-27 18:05:26 +00:00
sc->sc_hwmap[i].ieeerate |= IEEE80211_RATE_MCS;
Fixup radiotap handling of FCS and QoS frames per discussion with David Young: o mark rx frames including FCS in the payload with the IEEE80211_RADIOTAP_F_FCS flag o remove hack to copy 802.11 headers with padding out of line; instead mark the frames with IEEE80211_RADIOTAP_F_DATAPAD and require applications to do the work o split precalculated radiotap flags into tx+rx now that they can be different Note the full usefulness of these changes depends on updates to applications that process radiotap data.
2005-01-24 20:31:24 +00:00
sc->sc_hwmap[i].txflags = IEEE80211_RADIOTAP_F_DATAPAD;
o With the addition of HT rates the set of h/w codes has a much wider range making the use of sc_hwmap to do direct mapping impractical. Switch to indexing by the rate index instead of the rate code and adjust associated state and logic appropriately. This has several benefits including simplification of the led code. o fix radiotap capture of HT rates o fix conditional compilation of HT radiotap support to be based on the hal having 5416 support; not the ABI version as hal builds may or may not include 5416 support
2008-10-27 18:22:44 +00:00
if (rt->info[i].shortPreamble ||
rt->info[i].phy == IEEE80211_T_OFDM)
Fixup radiotap handling of FCS and QoS frames per discussion with David Young: o mark rx frames including FCS in the payload with the IEEE80211_RADIOTAP_F_FCS flag o remove hack to copy 802.11 headers with padding out of line; instead mark the frames with IEEE80211_RADIOTAP_F_DATAPAD and require applications to do the work o split precalculated radiotap flags into tx+rx now that they can be different Note the full usefulness of these changes depends on updates to applications that process radiotap data.
2005-01-24 20:31:24 +00:00
sc->sc_hwmap[i].txflags |= IEEE80211_RADIOTAP_F_SHORTPRE;
Overhaul monitor mode handling: o replace DLT_IEEE802_11 support in net80211 with DLT_IEEE802_11_RADIO and remove explicit bpf support from wireless drivers; drivers now use ieee80211_radiotap_attach to setup shared data structures that hold the radiotap header for each packet tx/rx o remove rx timestamp from the rx path; it was used only by the tdma support for debugging and was mostly useless due to it being 32-bits and mostly unavailable o track DLT_IEEE80211_RADIO bpf attachments and maintain per-vap and per-com state when there are active taps o track the number of monitor mode vaps o use bpf tap and monitor mode vap state to decide when to collect radiotap state and dispatch frames; drivers no longer explicitly directly check bpf state or use bpf calls to tap frames o handle radiotap state updates on channel change in net80211; drivers should not do this (unless they bypass net80211 which is almost always a mistake) o update various drivers to be more consistent/correct in handling radiotap o update ral to include TSF in radiotap'd frames o add promisc mode callback to wi Reviewed by: cbzimmer, rpaulo, thompsa
2009-05-20 20:00:40 +00:00
sc->sc_hwmap[i].rxflags = sc->sc_hwmap[i].txflags;
net80211 & wireless drivers: remove duplicate defines (noop) * IEEE80211_DIR_DSTODS(wh) -> IEEE80211_IS_DSTODS(wh). * N(a) -> nitems(a). * Remove LE_READ_2(p)/LE_READ_4(p) definitions (and include ieee80211_input.h instead). * <drvname>_TXOP_TO_US(txop) -> IEEE80211_TXOP_TO_US(txop). * Put IEEE80211_RV(v) into ieee80211_proto.h and remove local RV(v) definitions. Submitted by: Andriy Voskoboinyk <s3erios@gmail.com> Differential Revision: https://reviews.freebsd.org/D3705
2015-09-22 02:44:59 +00:00
for (j = 0; j < nitems(blinkrates)-1; j++)
better led blinking
2005-01-18 19:03:04 +00:00
if (blinkrates[j].rate == sc->sc_hwmap[i].ieeerate)
break;
/* NB: this uses the last entry if the rate isn't found */
/* XXX beware of overlow */
sc->sc_hwmap[i].ledon = (blinkrates[j].timeOn * hz) / 1000;
sc->sc_hwmap[i].ledoff = (blinkrates[j].timeOff * hz) / 1000;
Update with last year of work.
2004-12-08 17:34:36 +00:00
}
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
sc->sc_currates = rt;
sc->sc_curmode = mode;
Update with last year of work.
2004-12-08 17:34:36 +00:00
/*
dev/ath: minor spelling fixes in comments. No functional change. Reviewed by: adrian
2016-05-02 19:56:48 +00:00
* All protection frames are transmitted at 2Mb/s for
Update with last year of work.
2004-12-08 17:34:36 +00:00
* 11g, otherwise at 1Mb/s.
*/
lookup the protection tx rate index in the rate tables instead of using a known value MFC after: 2 weeks
2006-02-09 21:17:28 +00:00
if (mode == IEEE80211_MODE_11G)
optimize ath_tx_findrix: there's no need to walk the rates table as sc_rixmap is an inverse map NB: could eliminate the check for an invalid rate by filling in 0 for invalid entries but the rate control modules use it to identify bogus rates so leave it for now
2009-05-07 00:35:32 +00:00
sc->sc_protrix = ath_tx_findrix(sc, 2*2);
lookup the protection tx rate index in the rate tables instead of using a known value MFC after: 2 weeks
2006-02-09 21:17:28 +00:00
else
optimize ath_tx_findrix: there's no need to walk the rates table as sc_rixmap is an inverse map NB: could eliminate the check for an invalid rate by filling in 0 for invalid entries but the rate control modules use it to identify bogus rates so leave it for now
2009-05-07 00:35:32 +00:00
sc->sc_protrix = ath_tx_findrix(sc, 2*1);
Correct spelling of reseting (found while researching the "bb hang detected" messages that are plaguing me). While I'm here, delete trailing whitespace.
2010-02-19 18:23:45 +00:00
/* NB: caller is responsible for resetting rate control state */
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
Update with last year of work.
2004-12-08 17:34:36 +00:00
static void
replace if_watchdog w/ private callout; probably can merge this with the calibration work sometime in the future
2009-03-09 23:10:19 +00:00
ath_watchdog(void *arg)
Update with last year of work.
2004-12-08 17:34:36 +00:00
{
replace if_watchdog w/ private callout; probably can merge this with the calibration work sometime in the future
2009-03-09 23:10:19 +00:00
struct ath_softc *sc = arg;
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
struct ieee80211com *ic = &sc->sc_ic;
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
int do_reset = 0;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
Convert the callouts back to using mutexes. I did this wrong - I should've included a state flag for each callout to see if it was supposed to run or not. I didn't do that. Instead, just use mutexes anyway. Suggested by: jhb
2014-11-15 01:18:49 +00:00
ATH_LOCK_ASSERT(sc);
Migrate the callouts from using mutex locks to being mpsafe with the locks being held by the callers. Kill callout_drain() and use callout_stop().
2014-11-14 04:26:26 +00:00
replace if_watchdog w/ private callout; probably can merge this with the calibration work sometime in the future
2009-03-09 23:10:19 +00:00
if (sc->sc_wd_timer != 0 && --sc->sc_wd_timer == 0) {
some of the 11n parts can hang under certain conditions without necessary workarounds, add code to detect these hangs and distinguish them from other events; note this code is only invoked for anomalous conditions and (at the moment) is a noop because the hang detection code is in a new hal that's coming shortly
2008-11-30 18:34:27 +00:00
uint32_t hangs;
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ath_power_set_power_state(sc, HAL_PM_AWAKE);
some of the 11n parts can hang under certain conditions without necessary workarounds, add code to detect these hangs and distinguish them from other events; note this code is only invoked for anomalous conditions and (at the moment) is a noop because the hang detection code is in a new hal that's coming shortly
2008-11-30 18:34:27 +00:00
if (ath_hal_gethangstate(sc->sc_ah, 0xffff, &hangs) &&
hangs != 0) {
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
device_printf(sc->sc_dev, "%s hang detected (0x%x)\n",
Correct spelling of reseting (found while researching the "bb hang detected" messages that are plaguing me). While I'm here, delete trailing whitespace.
2010-02-19 18:23:45 +00:00
hangs & 0xff ? "bb" : "mac", hangs);
some of the 11n parts can hang under certain conditions without necessary workarounds, add code to detect these hangs and distinguish them from other events; note this code is only invoked for anomalous conditions and (at the moment) is a noop because the hang detection code is in a new hal that's coming shortly
2008-11-30 18:34:27 +00:00
} else
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
device_printf(sc->sc_dev, "device timeout\n");
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
do_reset = 1;
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
counter_u64_add(ic->ic_oerrors, 1);
Update 802.11 wireless support: o major overhaul of the way channels are handled: channels are now fully enumerated and uniquely identify the operating characteristics; these changes are visible to user applications which require changes o make scanning support independent of the state machine to enable background scanning and roaming o move scanning support into loadable modules based on the operating mode to enable different policies and reduce the memory footprint on systems w/ constrained resources o add background scanning in station mode (no support for adhoc/ibss mode yet) o significantly speedup sta mode scanning with a variety of techniques o add roaming support when background scanning is supported; for now we use a simple algorithm to trigger a roam: we threshold the rssi and tx rate, if either drops too low we try to roam to a new ap o add tx fragmentation support o add first cut at 802.11n support: this code works with forthcoming drivers but is incomplete; it's included now to establish a baseline for other drivers to be developed and for user applications o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates prepending mbufs for traffic generated locally o add support for Atheros protocol extensions; mainly the fast frames encapsulation (note this can be used with any card that can tx+rx large frames correctly) o add sta support for ap's that beacon both WPA1+2 support o change all data types from bsd-style to posix-style o propagate noise floor data from drivers to net80211 and on to user apps o correct various issues in the sta mode state machine related to handling authentication and association failures o enable the addition of sta mode power save support for drivers that need net80211 support (not in this commit) o remove old WI compatibility ioctls (wicontrol is officially dead) o change the data structures returned for get sta info and get scan results so future additions will not break user apps o fixed tx rate is now maintained internally as an ieee rate and not an index into the rate set; this needs to be extended to deal with multi-mode operation o add extended channel specifications to radiotap to enable 11n sniffing Drivers: o ath: add support for bg scanning, tx fragmentation, fast frames, dynamic turbo (lightly tested), 11n (sniffing only and needs new hal) o awi: compile tested only o ndis: lightly tested o ipw: lightly tested o iwi: add support for bg scanning (well tested but may have some rough edges) o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data o wi: lightly tested This work is based on contributions by Atheros, kmacy, sephe, thompsa, mlaier, kevlo, and others. Much of the scanning work was supported by Atheros. The 11n work was supported by Marvell.
2007-06-11 03:36:55 +00:00
sc->sc_stats.ast_watchdog++;
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
2014-04-30 02:19:41 +00:00
ath_power_restore_power_state(sc);
Update with last year of work.
2004-12-08 17:34:36 +00:00
}
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
/*
* We can't hold the lock across the ath_reset() call.
Attempt to further fix some of the concurrency/reset issues that occur. * ath_reset() is being called in softclock context, which may have the thing sleep on a lock. To avoid this, since we really _shouldn't_ be sleeping on any locks, break out the no-loss reset path into a tasklet and call that from: + ath_calibrate() + ath_watchdog() This has the added advantage that it'll end up also doing the frame RX cleanup from within the taskqueue context, rather than the softclock context. * Shuffle around the taskqueue_block() call to be before we grab the lock and disable interrupts. The trouble here is that taskqueue_block() doesn't block currently queued (but not yet running) tasks so calling it doesn't guarantee no further tasks (that weren't running on _A_ CPU at the time of this call) will complete. Calling taskqueue_drain() on these tasks won't work because if any _other_ thread calls taskqueue_enqueue() for whatever reason, everything gets very angry and stops working. This slightly changes the race condition enough to let ath_rx_tasklet() run before we try disabling it, and thus quietens the warnings a bit. The (more) true solution will be doing something like the following: * having a taskqueue_blocked mask in ath_softc; * having an interrupt_blocked mask in ath_softc; * only calling taskqueue_drain() on each individual task _after_ the lock has been acquired - that way no further tasklet scheduling is going to occur. * Then once the tasks have been blocked _and_ the interrupt has been disabled, call taskqueue_drain() on each, ensuring that anything that _was_ scheduled or running is removed. The trouble is if something calls taskqueue_enqueue() on a task after taskqueue_blocked() has been called but BEFORE taskqueue_drain() has been called, ta_pending will be set to 1 and taskqueue_drain() will sit there stuck in msleep() until you hard-kill the machine. PR: kern/165382 PR: kern/165220
2012-02-25 19:12:54 +00:00
*
* And since this routine can't hold a lock and sleep,
* do the reset deferred.
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
*/
if (do_reset) {
Attempt to further fix some of the concurrency/reset issues that occur. * ath_reset() is being called in softclock context, which may have the thing sleep on a lock. To avoid this, since we really _shouldn't_ be sleeping on any locks, break out the no-loss reset path into a tasklet and call that from: + ath_calibrate() + ath_watchdog() This has the added advantage that it'll end up also doing the frame RX cleanup from within the taskqueue context, rather than the softclock context. * Shuffle around the taskqueue_block() call to be before we grab the lock and disable interrupts. The trouble here is that taskqueue_block() doesn't block currently queued (but not yet running) tasks so calling it doesn't guarantee no further tasks (that weren't running on _A_ CPU at the time of this call) will complete. Calling taskqueue_drain() on these tasks won't work because if any _other_ thread calls taskqueue_enqueue() for whatever reason, everything gets very angry and stops working. This slightly changes the race condition enough to let ath_rx_tasklet() run before we try disabling it, and thus quietens the warnings a bit. The (more) true solution will be doing something like the following: * having a taskqueue_blocked mask in ath_softc; * having an interrupt_blocked mask in ath_softc; * only calling taskqueue_drain() on each individual task _after_ the lock has been acquired - that way no further tasklet scheduling is going to occur. * Then once the tasks have been blocked _and_ the interrupt has been disabled, call taskqueue_drain() on each, ensuring that anything that _was_ scheduled or running is removed. The trouble is if something calls taskqueue_enqueue() on a task after taskqueue_blocked() has been called but BEFORE taskqueue_drain() has been called, ta_pending will be set to 1 and taskqueue_drain() will sit there stuck in msleep() until you hard-kill the machine. PR: kern/165382 PR: kern/165220
2012-02-25 19:12:54 +00:00
taskqueue_enqueue(sc->sc_tq, &sc->sc_resettask);
Flesh out some slightly dirty reset/channel change serialisation code for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc.
2011-11-18 05:06:30 +00:00
}
replace if_watchdog w/ private callout; probably can merge this with the calibration work sometime in the future
2009-03-09 23:10:19 +00:00
callout_schedule(&sc->sc_wd_ch, hz);
Update with last year of work.
2004-12-08 17:34:36 +00:00
}
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
static void
ath_parent(struct ieee80211com *ic)
Update with last year of work.
2004-12-08 17:34:36 +00:00
{
Remove most of the references of ifp->if_softc and replace with references to ic->ic_softc. This is in preparation for gleb's ifnet work. Tested: * ath(4), STA mode * ath(4), hostap mode * make universe
2015-08-17 02:04:11 +00:00
struct ath_softc *sc = ic->ic_softc;
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
int error = EDOOFUS;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
ATH_LOCK(sc);
if (ic->ic_nrunning > 0) {
/*
* To avoid rescanning another access point,
* do not call ath_init() here. Instead,
* only reflect promisc mode settings.
*/
if (sc->sc_running) {
Wake up the hardware before calling ath_mode_init() in the ioctl() path. Tested: * AR5416, STA + powersave
2014-05-05 17:06:40 +00:00
ath_power_set_power_state(sc, HAL_PM_AWAKE);
Update with last year of work.
2004-12-08 17:34:36 +00:00
ath_mode_init(sc);
Wake up the hardware before calling ath_mode_init() in the ioctl() path. Tested: * AR5416, STA + powersave
2014-05-05 17:06:40 +00:00
ath_power_restore_power_state(sc);
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
} else if (!sc->sc_invalid) {
Update with last year of work.
2004-12-08 17:34:36 +00:00
/*
* Beware of being called during attach/detach
* to reset promiscuous mode. In that case we
* will still be marked UP but not RUNNING.
* However trying to re-init the interface
* is the wrong thing to do as we've already
* torn down much of our state. There's
* probably a better way to deal with this.
*/
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
error = ath_init(sc);
Cleanup power handling and fix suspend/resume: o do not put the chip into full sleep in ath_stop as it gains nothing and causes many parts to hang in ath_detach because we may touch the chip during vap teardown; this may also fix issues with unloading the module o add a note in ath_detach to explain ath_hal_detach puts the chip in low power mode; this is useful to know as it means unloading the module will place a pci device in the lowest possible power state o leave an #ifdef notyet marker for powering down the chip when a device is marked down; we can't do that until we handle all the ways the driver may be entered and touch the chip o fix resume by reloading the h/w key cache as it's been clobbered (for pci) by the socket being powered off; for station mode we directly stop+init the chip and then simulate a beacon miss to get the upper layers sync'd up; for other configs we must brute force stop+start the vaps so they go through the state machine
2008-05-29 00:10:48 +00:00
}
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
} else {
ath_stop(sc);
if (!sc->sc_invalid)
[ath] force wake the hardware if we see a missed beacon. This adds a workaround to incorrectly behaving APs (ie, FreeBSD APs) which don't beacon out exactly when they should (at TBTT multiples of beacon intervals.) It forces the hardware awake (but leaves it in network-sleep so self generated frames still state that the hardware is asleep!) and will remain awake until the next sleep transition driven by net80211. That way if the beacons are just at the wrong interval, we get a much better chance of hearing more consecutive beacons before we go to sleep, thus not constantly disconnecting. Tested: * AR9485, STA mode, against a misbehaving FreeBSD AP.
2016-11-28 17:54:29 +00:00
ath_power_setpower(sc, HAL_PM_FULL_SLEEP, 1);
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
}
ATH_UNLOCK(sc);
if (error == 0) {
#ifdef ATH_TX99_DIAG
if (sc->sc_tx99 != NULL)
sc->sc_tx99->start(sc->sc_tx99);
else
#endif
ieee80211_start_all(ic);
}
}
Update with last year of work.
2004-12-08 17:34:36 +00:00
/*
* Announce various information on device/driver attach.
*/
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
static void
Update with last year of work.
2004-12-08 17:34:36 +00:00
ath_announce(struct ath_softc *sc)
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
{
Update with last year of work.
2004-12-08 17:34:36 +00:00
struct ath_hal *ah = sc->sc_ah;
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
Fix up the ath(4) device names for QCA chipsets. Submitted by: Tobias Kortkamp <t@tobik.me>
2016-02-29 02:40:58 +00:00
device_printf(sc->sc_dev, "%s mac %d.%d RF%s phy %d.%d\n",
print mac+rf part names; drop the printing 2ghz rf stuff (might come back)
2009-02-23 23:41:12 +00:00
ath_hal_mac_name(ah), ah->ah_macVersion, ah->ah_macRev,
ath_hal_rf_name(ah), ah->ah_phyRev >> 4, ah->ah_phyRev & 0xf);
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
device_printf(sc->sc_dev, "2GHz radio: 0x%.4x; 5GHz radio: 0x%.4x\n",
Print out the radio RF version at startup, so I can better see which RF frontend versions people have when they submit problem reports. Sponsored by: Hobnob, Inc.
2011-12-15 00:55:27 +00:00
ah->ah_analog2GhzRev, ah->ah_analog5GhzRev);
Update with last year of work.
2004-12-08 17:34:36 +00:00
if (bootverbose) {
int i;
for (i = 0; i <= WME_AC_VO; i++) {
struct ath_txq *txq = sc->sc_ac2q[i];
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
device_printf(sc->sc_dev,
"Use hw queue %u for %s traffic\n",
txq->axq_qnum, ieee80211_wme_acnames[i]);
Update with last year of work.
2004-12-08 17:34:36 +00:00
}
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
device_printf(sc->sc_dev, "Use hw queue %u for CAB traffic\n",
sc->sc_cabq->axq_qnum);
device_printf(sc->sc_dev, "Use hw queue %u for beacons\n",
sc->sc_bhalq);
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
allow the size of tx+rx buffer pools to be tuned MFC after: 2 weeks
2006-02-09 21:03:25 +00:00
if (ath_rxbuf != ATH_RXBUF)
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
device_printf(sc->sc_dev, "using %u rx buffers\n", ath_rxbuf);
allow the size of tx+rx buffer pools to be tuned MFC after: 2 weeks
2006-02-09 21:03:25 +00:00
if (ath_txbuf != ATH_TXBUF)
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
device_printf(sc->sc_dev, "using %u tx buffers\n", ath_txbuf);
Add multicast key search support. This fixes corrupted mcast packets when we have more than one hostap vap. Submitted by: Russell Yount <russell.yount at gmail.com> MFC after: 2 weeks
2010-02-08 20:23:20 +00:00
if (sc->sc_mcastkey && bootverbose)
Use device_printf() instead of if_printf(). No functional changes.
2015-05-29 14:35:16 +00:00
device_printf(sc->sc_dev, "using multicast key search\n");
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL). Supported by: Atheros Comunications
2003-06-23 17:01:19 +00:00
}
TDMA support for long distance point-to-point links using ath devices: o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
2009-01-08 17:12:47 +00:00
Flesh out the radar detection related operations for the ath driver. This is in no way a complete DFS/radar detection implementation! It merely creates an abstracted interface which allows for future development of the DFS radar detection code. Note: Net80211 already handles the bulk of the DFS machinery, all we need to do here is figure out that a radar event has occured and inform it as such. It then drives the DFS state engine for us. The "null" DFS radar detection module is included by default; it doesn't require a device line. This commit: * Adds a simple abstracted layer for radar detection state - sys/dev/ath/ath_dfs/; * Implements a null DFS module which doesn't do anything; (ie, implements the exact behaviour at the moment); * Adds hooks to the ath driver to process received radar events and gives the DFS module a chance to determine whether a radar has been detected. Obtained from: Atheros
2011-06-01 20:09:49 +00:00
static void
ath_dfs_tasklet(void *p, int npending)
{
struct ath_softc *sc = (struct ath_softc *) p;
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
2015-08-27 08:56:39 +00:00
struct ieee80211com *ic = &sc->sc_ic;
Flesh out the radar detection related operations for the ath driver. This is in no way a complete DFS/radar detection implementation! It merely creates an abstracted interface which allows for future development of the DFS radar detection code. Note: Net80211 already handles the bulk of the DFS machinery, all we need to do here is figure out that a radar event has occured and inform it as such. It then drives the DFS state engine for us. The "null" DFS radar detection module is included by default; it doesn't require a device line. This commit: * Adds a simple abstracted layer for radar detection state - sys/dev/ath/ath_dfs/; * Implements a null DFS module which doesn't do anything; (ie, implements the exact behaviour at the moment); * Adds hooks to the ath driver to process received radar events and gives the DFS module a chance to determine whether a radar has been detected. Obtained from: Atheros
2011-06-01 20:09:49 +00:00
/*
* If previous processing has found a radar event,
* signal this to the net80211 layer to begin DFS
* processing.
*/
if (ath_dfs_process_radar_event(sc, sc->sc_curchan)) {
/* DFS event found, initiate channel change */
[ath] fix "doing stuff before wakeup" warning; add comments for ACK/CTS handling during DFS/PASSIVE channels * Although the hardware is awake, the power state handling doesn't think so. So just explicitly wake it up early in setup so ath_hal calls don't complain. * We shouldn't be transmitting or ACKing frames during DFS CAC or on passive channels before we hear a beacon. So, start laying down comments in the places where this work has to be done. Note: * The main bit missing from finishing this particular bit of work is a state call to transition a VAP from passive to non-passive when a beacon is heard. CAC is easy, it's an interface state. So, I'll go and add a method to control that soon.
2017-01-27 01:17:00 +00:00
/*
* XXX TODO: immediately disable ACK processing
* on the current channel. This would be done
* by setting AR_DIAG_ACK_DIS (AR5212; may be
* different for others) until we are out of
* CAC.
*/
Two changes from my DFS work: * Grab the net80211com lock when calling ieee80211_dfs_notify_radar(). * Use the tsf extend function to turn the 64 bit base TSF into a per- frame 64 bit TSF. This will improve radiotap logging (which will now have a (more) correct per-frame TSF, rather then the single TSF64 value read at the beginning of ath_rx_proc().
2012-01-28 21:37:33 +00:00
/*
* XXX doesn't currently tell us whether the event
* XXX was found in the primary or extension
* XXX channel!
*/
IEEE80211_LOCK(ic);
Flesh out the radar detection related operations for the ath driver. This is in no way a complete DFS/radar detection implementation! It merely creates an abstracted interface which allows for future development of the DFS radar detection code. Note: Net80211 already handles the bulk of the DFS machinery, all we need to do here is figure out that a radar event has occured and inform it as such. It then drives the DFS state engine for us. The "null" DFS radar detection module is included by default; it doesn't require a device line. This commit: * Adds a simple abstracted layer for radar detection state - sys/dev/ath/ath_dfs/; * Implements a null DFS module which doesn't do anything; (ie, implements the exact behaviour at the moment); * Adds hooks to the ath driver to process received radar events and gives the DFS module a chance to determine whether a radar has been detected. Obtained from: Atheros
2011-06-01 20:09:49 +00:00
ieee80211_dfs_notify_radar(ic, sc->sc_curchan);
Two changes from my DFS work: * Grab the net80211com lock when calling ieee80211_dfs_notify_radar(). * Use the tsf extend function to turn the 64 bit base TSF into a per- frame 64 bit TSF. This will improve radiotap logging (which will now have a (more) correct per-frame TSF, rather then the single TSF64 value read at the beginning of ath_rx_proc().
2012-01-28 21:37:33 +00:00
IEEE80211_UNLOCK(ic);
Flesh out the radar detection related operations for the ath driver. This is in no way a complete DFS/radar detection implementation! It merely creates an abstracted interface which allows for future development of the DFS radar detection code. Note: Net80211 already handles the bulk of the DFS machinery, all we need to do here is figure out that a radar event has occured and inform it as such. It then drives the DFS state engine for us. The "null" DFS radar detection module is included by default; it doesn't require a device line. This commit: * Adds a simple abstracted layer for radar detection state - sys/dev/ath/ath_dfs/; * Implements a null DFS module which doesn't do anything; (ie, implements the exact behaviour at the moment); * Adds hooks to the ath driver to process received radar events and gives the DFS module a chance to determine whether a radar has been detected. Obtained from: Atheros
2011-06-01 20:09:49 +00:00
}
}
Pause and unpause the software queues for a given node based on the net80211 node power save state. * Add an ATH_NODE_UNLOCK_ASSERT() check * Add a new node field - an_is_powersave * Pause/unpause the queue based on the node state * Attempt to handle net80211 concurrency issues so the queue doesn't get paused/unpaused more than once at a time from the net80211 power save code. Whilst here (and breaking my usual rule), set CLRDMASK when a queue is unpaused, regardless of whether the queue has some pending traffic. This means the first frame from that TID (now or later) will hvae CLRDMASK set. Also whilst here, bump the swretrymax counters whenever the filtered frames code expires a frame. Again, breaking my rule, but this is just a statistics thing rather than a functional change. This doesn't fix ps-poll (but it doesn't break it too much worse than it is at the present) or correcting the TID updates. That's next on the list. Tested: * AR9220 AP (Atheros AP96 reference design) * Macbook Pro and LG Optimus 1 Android phone, both setting and clearing power save state (but not using PS-POLL.)
2012-10-03 23:23:45 +00:00
/*
* Enable/disable power save. This must be called with
* no TX driver locks currently held, so it should only
* be called from the RX path (which doesn't hold any
* TX driver locks.)
*/
static void
ath_node_powersave(struct ieee80211_node *ni, int enable)
{
Disable my software queue TIM and PS handling for now. ps-poll is totally broken in its current form. This should unbreak things enough to let people use PS-POLL devices, but leave it in place for me to finish PS-POLL handling.
2012-11-07 06:29:45 +00:00
#ifdef ATH_SW_PSQ
Pause and unpause the software queues for a given node based on the net80211 node power save state. * Add an ATH_NODE_UNLOCK_ASSERT() check * Add a new node field - an_is_powersave * Pause/unpause the queue based on the node state * Attempt to handle net80211 concurrency issues so the queue doesn't get paused/unpaused more than once at a time from the net80211 power save code. Whilst here (and breaking my usual rule), set CLRDMASK when a queue is unpaused, regardless of whether the queue has some pending traffic. This means the first frame from that TID (now or later) will hvae CLRDMASK set. Also whilst here, bump the swretrymax counters whenever the filtered frames code expires a frame. Again, breaking my rule, but this is just a statistics thing rather than a functional change. This doesn't fix ps-poll (but it doesn't break it too much worse than it is at the present) or correcting the TID updates. That's next on the list. Tested: * AR9220 AP (Atheros AP96 reference design) * Macbook Pro and LG Optimus 1 Android phone, both setting and clearing power save state (but not using PS-POLL.)
2012-10-03 23:23:45 +00:00
struct ath_node *an = ATH_NODE(ni);
struct ieee80211com *ic = ni->ni_ic;
Remove most of the references of ifp->if_softc and replace with references to ic->ic_softc. This is in preparation for gleb's ifnet work. Tested: * ath(4), STA mode * ath(4), hostap mode * make universe
2015-08-17 02:04:11 +00:00
struct ath_softc *sc = ic->ic_softc;
Pause and unpause the software queues for a given node based on the net80211 node power save state. * Add an ATH_NODE_UNLOCK_ASSERT() check * Add a new node field - an_is_powersave * Pause/unpause the queue based on the node state * Attempt to handle net80211 concurrency issues so the queue doesn't get paused/unpaused more than once at a time from the net80211 power save code. Whilst here (and breaking my usual rule), set CLRDMASK when a queue is unpaused, regardless of whether the queue has some pending traffic. This means the first frame from that TID (now or later) will hvae CLRDMASK set. Also whilst here, bump the swretrymax counters whenever the filtered frames code expires a frame. Again, breaking my rule, but this is just a statistics thing rather than a functional change. This doesn't fix ps-poll (but it doesn't break it too much worse than it is at the present) or correcting the TID updates. That's next on the list. Tested: * AR9220 AP (Atheros AP96 reference design) * Macbook Pro and LG Optimus 1 Android phone, both setting and clearing power save state (but not using PS-POLL.)
2012-10-03 23:23:45 +00:00
struct ath_vap *avp = ATH_VAP(ni->ni_vap);
/* XXX and no TXQ locks should be held here */
Improve the debugging output - use the MAC address rather than various pointer values everywhere.
2013-05-13 19:52:35 +00:00
DPRINTF(sc, ATH_DEBUG_NODE_PWRSAVE, "%s: %6D: enable=%d\n",
__func__,
ni->ni_macaddr,
":",
!! enable);
Pause and unpause the software queues for a given node based on the net80211 node power save state. * Add an ATH_NODE_UNLOCK_ASSERT() check * Add a new node field - an_is_powersave * Pause/unpause the queue based on the node state * Attempt to handle net80211 concurrency issues so the queue doesn't get paused/unpaused more than once at a time from the net80211 power save code. Whilst here (and breaking my usual rule), set CLRDMASK when a queue is unpaused, regardless of whether the queue has some pending traffic. This means the first frame from that TID (now or later) will hvae CLRDMASK set. Also whilst here, bump the swretrymax counters whenever the filtered frames code expires a frame. Again, breaking my rule, but this is just a statistics thing rather than a functional change. This doesn't fix ps-poll (but it doesn't break it too much worse than it is at the present) or correcting the TID updates. That's next on the list. Tested: * AR9220 AP (Atheros AP96 reference design) * Macbook Pro and LG Optimus 1 Android phone, both setting and clearing power save state (but not using PS-POLL.)
2012-10-03 23:23:45 +00:00
/* Suspend or resume software queue handling */
if (enable)
ath_tx_node_sleep(sc, an);
else
ath_tx_node_wakeup(sc, an);
/* Update net80211 state */
avp->av_node_ps(ni, enable);
Disable my software queue TIM and PS handling for now. ps-poll is totally broken in its current form. This should unbreak things enough to let people use PS-POLL devices, but leave it in place for me to finish PS-POLL handling.
2012-11-07 06:29:45 +00:00
#else
struct ath_vap *avp = ATH_VAP(ni->ni_vap);
/* Update net80211 state */
avp->av_node_ps(ni, enable);
#endif/* ATH_SW_PSQ */
Pause and unpause the software queues for a given node based on the net80211 node power save state. * Add an ATH_NODE_UNLOCK_ASSERT() check * Add a new node field - an_is_powersave * Pause/unpause the queue based on the node state * Attempt to handle net80211 concurrency issues so the queue doesn't get paused/unpaused more than once at a time from the net80211 power save code. Whilst here (and breaking my usual rule), set CLRDMASK when a queue is unpaused, regardless of whether the queue has some pending traffic. This means the first frame from that TID (now or later) will hvae CLRDMASK set. Also whilst here, bump the swretrymax counters whenever the filtered frames code expires a frame. Again, breaking my rule, but this is just a statistics thing rather than a functional change. This doesn't fix ps-poll (but it doesn't break it too much worse than it is at the present) or correcting the TID updates. That's next on the list. Tested: * AR9220 AP (Atheros AP96 reference design) * Macbook Pro and LG Optimus 1 Android phone, both setting and clearing power save state (but not using PS-POLL.)
2012-10-03 23:23:45 +00:00
}
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
/*
* Notification from net80211 that the powersave queue state has
* changed.
*
* Since the software queue also may have some frames:
*
* + if the node software queue has frames and the TID state
* is 0, we set the TIM;
* + if the node and the stack are both empty, we clear the TIM bit.
* + If the stack tries to set the bit, always set it.
* + If the stack tries to clear the bit, only clear it if the
* software queue in question is also cleared.
*
* TODO: this is called during node teardown; so let's ensure this
* is all correctly handled and that the TIM bit is cleared.
* It may be that the node flush is called _AFTER_ the net80211
* stack clears the TIM.
*
* Here is the racy part. Since it's possible >1 concurrent,
* overlapping TXes will appear complete with a TX completion in
* another thread, it's possible that the concurrent TIM calls will
* clash. We can't hold the node lock here because setting the
* TIM grabs the net80211 comlock and this may cause a LOR.
* The solution is either to totally serialise _everything_ at
* this point (ie, all TX, completion and any reset/flush go into
* one taskqueue) or a new "ath TIM lock" needs to be created that
* just wraps the driver state change and this call to avp->av_set_tim().
*
* The same race exists in the net80211 power save queue handling
* as well. Since multiple transmitting threads may queue frames
* into the driver, as well as ps-poll and the driver transmitting
* frames (and thus clearing the psq), it's quite possible that
* a packet entering the PSQ and a ps-poll being handled will
* race, causing the TIM to be cleared and not re-set.
*/
static int
ath_node_set_tim(struct ieee80211_node *ni, int enable)
{
Disable my software queue TIM and PS handling for now. ps-poll is totally broken in its current form. This should unbreak things enough to let people use PS-POLL devices, but leave it in place for me to finish PS-POLL handling.
2012-11-07 06:29:45 +00:00
#ifdef ATH_SW_PSQ
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
struct ieee80211com *ic = ni->ni_ic;
Remove most of the references of ifp->if_softc and replace with references to ic->ic_softc. This is in preparation for gleb's ifnet work. Tested: * ath(4), STA mode * ath(4), hostap mode * make universe
2015-08-17 02:04:11 +00:00
struct ath_softc *sc = ic->ic_softc;
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
struct ath_node *an = ATH_NODE(ni);
struct ath_vap *avp = ATH_VAP(ni->ni_vap);
int changed = 0;
Begin tidying up the reassociation and node sleep/wakeup paths. * Move the node sleep/wake state under the TX lock rather than the node lock. Let's leave the node lock protecting rate control only for now. * When reassociating, various state needs to be cleared. For example, the aggregate session needs to be torn down, including any pending aggregation negotiation and BAR TX waiting. * .. and we need to do a "cleanup" pass since frames in the hardware TX queue need to be transmitted. Modify ath_tx_tid_cleanup() to be called with the TX lock held and push frames into a completion list. This allows for the cleanup to be done atomically for all TIDs in a node rather than grabbing and releasing the TX lock each time.
2013-05-13 18:56:04 +00:00
ATH_TX_LOCK(sc);
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
an->an_stack_psq = enable;
/*
* This will get called for all operating modes,
* even if avp->av_set_tim is unset.
* It's currently set for hostap/ibss modes; but
* the same infrastructure is used for both STA
* and AP/IBSS node power save.
*/
if (avp->av_set_tim == NULL) {
Begin tidying up the reassociation and node sleep/wakeup paths. * Move the node sleep/wake state under the TX lock rather than the node lock. Let's leave the node lock protecting rate control only for now. * When reassociating, various state needs to be cleared. For example, the aggregate session needs to be torn down, including any pending aggregation negotiation and BAR TX waiting. * .. and we need to do a "cleanup" pass since frames in the hardware TX queue need to be transmitted. Modify ath_tx_tid_cleanup() to be called with the TX lock held and push frames into a completion list. This allows for the cleanup to be done atomically for all TIDs in a node rather than grabbing and releasing the TX lock each time.
2013-05-13 18:56:04 +00:00
ATH_TX_UNLOCK(sc);
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
return (0);
}
/*
* If setting the bit, always set it here.
* If clearing the bit, only clear it if the
* software queue is also empty.
*
* If the node has left power save, just clear the TIM
* bit regardless of the state of the power save queue.
*
* XXX TODO: although atomics are used, it's quite possible
* that a race will occur between this and setting/clearing
* in another thread. TX completion will occur always in
* one thread, however setting/clearing the TIM bit can come
* from a variety of different process contexts!
*/
if (enable && an->an_tim_set == 1) {
DPRINTF(sc, ATH_DEBUG_NODE_PWRSAVE,
Improve the debugging output - use the MAC address rather than various pointer values everywhere.
2013-05-13 19:52:35 +00:00
"%s: %6D: enable=%d, tim_set=1, ignoring\n",
__func__,
ni->ni_macaddr,
":",
enable);
Begin tidying up the reassociation and node sleep/wakeup paths. * Move the node sleep/wake state under the TX lock rather than the node lock. Let's leave the node lock protecting rate control only for now. * When reassociating, various state needs to be cleared. For example, the aggregate session needs to be torn down, including any pending aggregation negotiation and BAR TX waiting. * .. and we need to do a "cleanup" pass since frames in the hardware TX queue need to be transmitted. Modify ath_tx_tid_cleanup() to be called with the TX lock held and push frames into a completion list. This allows for the cleanup to be done atomically for all TIDs in a node rather than grabbing and releasing the TX lock each time.
2013-05-13 18:56:04 +00:00
ATH_TX_UNLOCK(sc);
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
} else if (enable) {
DPRINTF(sc, ATH_DEBUG_NODE_PWRSAVE,
Improve the debugging output - use the MAC address rather than various pointer values everywhere.
2013-05-13 19:52:35 +00:00
"%s: %6D: enable=%d, enabling TIM\n",
__func__,
ni->ni_macaddr,
":",
enable);
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
an->an_tim_set = 1;
Begin tidying up the reassociation and node sleep/wakeup paths. * Move the node sleep/wake state under the TX lock rather than the node lock. Let's leave the node lock protecting rate control only for now. * When reassociating, various state needs to be cleared. For example, the aggregate session needs to be torn down, including any pending aggregation negotiation and BAR TX waiting. * .. and we need to do a "cleanup" pass since frames in the hardware TX queue need to be transmitted. Modify ath_tx_tid_cleanup() to be called with the TX lock held and push frames into a completion list. This allows for the cleanup to be done atomically for all TIDs in a node rather than grabbing and releasing the TX lock each time.
2013-05-13 18:56:04 +00:00
ATH_TX_UNLOCK(sc);
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
changed = avp->av_set_tim(ni, enable);
Since the node state is 100% back under the TX lock, just kill the use of atomics. I'll re-think this nonsense later.
2013-05-13 19:03:12 +00:00
} else if (an->an_swq_depth == 0) {
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
/* disable */
DPRINTF(sc, ATH_DEBUG_NODE_PWRSAVE,
Improve the debugging output - use the MAC address rather than various pointer values everywhere.
2013-05-13 19:52:35 +00:00
"%s: %6D: enable=%d, an_swq_depth == 0, disabling\n",
__func__,
ni->ni_macaddr,
":",
enable);
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
an->an_tim_set = 0;
Begin tidying up the reassociation and node sleep/wakeup paths. * Move the node sleep/wake state under the TX lock rather than the node lock. Let's leave the node lock protecting rate control only for now. * When reassociating, various state needs to be cleared. For example, the aggregate session needs to be torn down, including any pending aggregation negotiation and BAR TX waiting. * .. and we need to do a "cleanup" pass since frames in the hardware TX queue need to be transmitted. Modify ath_tx_tid_cleanup() to be called with the TX lock held and push frames into a completion list. This allows for the cleanup to be done atomically for all TIDs in a node rather than grabbing and releasing the TX lock each time.
2013-05-13 18:56:04 +00:00
ATH_TX_UNLOCK(sc);
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
changed = avp->av_set_tim(ni, enable);
} else if (! an->an_is_powersave) {
/*
* disable regardless; the node isn't in powersave now
*/
DPRINTF(sc, ATH_DEBUG_NODE_PWRSAVE,
Improve the debugging output - use the MAC address rather than various pointer values everywhere.
2013-05-13 19:52:35 +00:00
"%s: %6D: enable=%d, an_pwrsave=0, disabling\n",
__func__,
ni->ni_macaddr,
":",
enable);
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
an->an_tim_set = 0;
Begin tidying up the reassociation and node sleep/wakeup paths. * Move the node sleep/wake state under the TX lock rather than the node lock. Let's leave the node lock protecting rate control only for now. * When reassociating, various state needs to be cleared. For example, the aggregate session needs to be torn down, including any pending aggregation negotiation and BAR TX waiting. * .. and we need to do a "cleanup" pass since frames in the hardware TX queue need to be transmitted. Modify ath_tx_tid_cleanup() to be called with the TX lock held and push frames into a completion list. This allows for the cleanup to be done atomically for all TIDs in a node rather than grabbing and releasing the TX lock each time.
2013-05-13 18:56:04 +00:00
ATH_TX_UNLOCK(sc);
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
changed = avp->av_set_tim(ni, enable);
} else {
/*
* psq disable, node is currently in powersave, node
* software queue isn't empty, so don't clear the TIM bit
* for now.
*/
Begin tidying up the reassociation and node sleep/wakeup paths. * Move the node sleep/wake state under the TX lock rather than the node lock. Let's leave the node lock protecting rate control only for now. * When reassociating, various state needs to be cleared. For example, the aggregate session needs to be torn down, including any pending aggregation negotiation and BAR TX waiting. * .. and we need to do a "cleanup" pass since frames in the hardware TX queue need to be transmitted. Modify ath_tx_tid_cleanup() to be called with the TX lock held and push frames into a completion list. This allows for the cleanup to be done atomically for all TIDs in a node rather than grabbing and releasing the TX lock each time.
2013-05-13 18:56:04 +00:00
ATH_TX_UNLOCK(sc);
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
DPRINTF(sc, ATH_DEBUG_NODE_PWRSAVE,
Improve the debugging output - use the MAC address rather than various pointer values everywhere.
2013-05-13 19:52:35 +00:00
"%s: %6D: enable=%d, an_swq_depth > 0, ignoring\n",
__func__,
ni->ni_macaddr,
":",
enable);
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
changed = 0;
}
return (changed);
Disable my software queue TIM and PS handling for now. ps-poll is totally broken in its current form. This should unbreak things enough to let people use PS-POLL devices, but leave it in place for me to finish PS-POLL handling.
2012-11-07 06:29:45 +00:00
#else
struct ath_vap *avp = ATH_VAP(ni->ni_vap);
Correctly fix the 'scan during STA mode' crash.
2012-11-11 21:58:18 +00:00
/*
Fix typo in comment. Submitted by: Christoph Mallon <christoph.mallon@gmx.de>
2012-12-28 21:59:47 +00:00
* Some operating modes don't set av_set_tim(), so don't
Correctly fix the 'scan during STA mode' crash.
2012-11-11 21:58:18 +00:00
* update it here.
*/
if (avp->av_set_tim == NULL)
return (0);
Disable my software queue TIM and PS handling for now. ps-poll is totally broken in its current form. This should unbreak things enough to let people use PS-POLL devices, but leave it in place for me to finish PS-POLL handling.
2012-11-07 06:29:45 +00:00
return (avp->av_set_tim(ni, enable));
#endif /* ATH_SW_PSQ */
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
}
/*
* Set or update the TIM from the software queue.
*
* Check the software queue depth before attempting to do lock
* anything; that avoids trying to obtain the lock. Then,
* re-check afterwards to ensure nothing has changed in the
* meantime.
*
* set: This is designed to be called from the TX path, after
* a frame has been queued; to see if the swq > 0.
*
* clear: This is designed to be called from the buffer completion point
* (right now it's ath_tx_default_comp()) where the state of
* a software queue has changed.
*
* It makes sense to place it at buffer free / completion rather
* than after each software queue operation, as there's no real
* point in churning the TIM bit as the last frames in the software
* queue are transmitted. If they fail and we retry them, we'd
* just be setting the TIM bit again anyway.
*/
void
ath_tx_update_tim(struct ath_softc *sc, struct ieee80211_node *ni,
int enable)
{
Disable my software queue TIM and PS handling for now. ps-poll is totally broken in its current form. This should unbreak things enough to let people use PS-POLL devices, but leave it in place for me to finish PS-POLL handling.
2012-11-07 06:29:45 +00:00
#ifdef ATH_SW_PSQ
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
struct ath_node *an;
struct ath_vap *avp;
/* Don't do this for broadcast/etc frames */
if (ni == NULL)
return;
an = ATH_NODE(ni);
avp = ATH_VAP(ni->ni_vap);
/*
* And for operating modes without the TIM handler set, let's
* just skip those.
*/
if (avp->av_set_tim == NULL)
return;
Begin tidying up the reassociation and node sleep/wakeup paths. * Move the node sleep/wake state under the TX lock rather than the node lock. Let's leave the node lock protecting rate control only for now. * When reassociating, various state needs to be cleared. For example, the aggregate session needs to be torn down, including any pending aggregation negotiation and BAR TX waiting. * .. and we need to do a "cleanup" pass since frames in the hardware TX queue need to be transmitted. Modify ath_tx_tid_cleanup() to be called with the TX lock held and push frames into a completion list. This allows for the cleanup to be done atomically for all TIDs in a node rather than grabbing and releasing the TX lock each time.
2013-05-13 18:56:04 +00:00
ATH_TX_LOCK_ASSERT(sc);
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
if (enable) {
if (an->an_is_powersave &&
an->an_tim_set == 0 &&
Since the node state is 100% back under the TX lock, just kill the use of atomics. I'll re-think this nonsense later.
2013-05-13 19:03:12 +00:00
an->an_swq_depth != 0) {
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
DPRINTF(sc, ATH_DEBUG_NODE_PWRSAVE,
Improve the debugging output - use the MAC address rather than various pointer values everywhere.
2013-05-13 19:52:35 +00:00
"%s: %6D: swq_depth>0, tim_set=0, set!\n",
__func__,
ni->ni_macaddr,
":");
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
an->an_tim_set = 1;
(void) avp->av_set_tim(ni, 1);
}
} else {
/*
* Don't bother grabbing the lock unless the queue is empty.
*/
Check the right value correctly. Thanks to clang for pointing out this silliness.
2015-01-16 01:52:26 +00:00
if (an->an_swq_depth != 0)
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
return;
if (an->an_is_powersave &&
an->an_stack_psq == 0 &&
an->an_tim_set == 1 &&
Since the node state is 100% back under the TX lock, just kill the use of atomics. I'll re-think this nonsense later.
2013-05-13 19:03:12 +00:00
an->an_swq_depth == 0) {
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
DPRINTF(sc, ATH_DEBUG_NODE_PWRSAVE,
Implement my first cut at "correct" node power-save and PS-POLL support. This implements PS-POLL awareness i nthe * Implement frame "leaking", which allows for a software queue to be scheduled even though it's asleep * Track whether a frame has been leaked or not * Leak out a single non-AMPDU frame when transmitting aggregates * Queue BAR frames if the node is asleep * Direct-dispatch the rest of control and management frames. This allows for things like re-association to occur (which involves sending probe req/resp as well as assoc request/response) when the node is asleep and then tries reassociating. * Limit how many frames can set in the software node queue whilst the node is asleep. net80211 is already buffering frames for us so this is mostly just paranoia. * Add a PS-POLL method which leaks out a frame if there's something in the software queue, else it calls net80211's ps-poll routine. Since the ath PS-POLL routine marks the node as having a single frame to leak, either a software queued frame would leak, OR the next queued frame would leak. The next queued frame could be something from the net80211 power save queue, OR it could be a NULL frame from net80211. TODO: * Don't transmit further BAR frames (eg via a timeout) if the node is currently asleep. Otherwise we may end up exhausting management frames due to the lots of queued BAR frames. I may just undo this bit later on and direct-dispatch BAR frames even if the node is asleep. * It would be nice to burst out a single A-MPDU frame if both ends support this. I may end adding a FreeBSD IE soon to negotiate this power save behaviour. * I should make STAs timeout of power save mode if they've been in power save for more than a handful of seconds. This way cards that get "stuck" in power save mode don't stay there for the "inactivity" timeout in net80211. * Move the queue depth check into the driver layer (ath_start / ath_transmit) rather than doing it in the TX path. * There could be some naughty corner cases with ps-poll leaking. Specifically, if net80211 generates a NULL data frame whilst another transmitter sends a normal data frame out net80211 output / transmit, we need to ensure that the NULL data frame goes out first. This is one of those things that should occur inside the VAP/ic TX lock. Grr, more investigations to do.. Tested: * STA: AR5416, AR9280 * AP: AR5416, AR9280, AR9160
2013-05-15 18:33:05 +00:00
"%s: %6D: swq_depth=0, tim_set=1, psq_set=0,"
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
" clear!\n",
Implement my first cut at "correct" node power-save and PS-POLL support. This implements PS-POLL awareness i nthe * Implement frame "leaking", which allows for a software queue to be scheduled even though it's asleep * Track whether a frame has been leaked or not * Leak out a single non-AMPDU frame when transmitting aggregates * Queue BAR frames if the node is asleep * Direct-dispatch the rest of control and management frames. This allows for things like re-association to occur (which involves sending probe req/resp as well as assoc request/response) when the node is asleep and then tries reassociating. * Limit how many frames can set in the software node queue whilst the node is asleep. net80211 is already buffering frames for us so this is mostly just paranoia. * Add a PS-POLL method which leaks out a frame if there's something in the software queue, else it calls net80211's ps-poll routine. Since the ath PS-POLL routine marks the node as having a single frame to leak, either a software queued frame would leak, OR the next queued frame would leak. The next queued frame could be something from the net80211 power save queue, OR it could be a NULL frame from net80211. TODO: * Don't transmit further BAR frames (eg via a timeout) if the node is currently asleep. Otherwise we may end up exhausting management frames due to the lots of queued BAR frames. I may just undo this bit later on and direct-dispatch BAR frames even if the node is asleep. * It would be nice to burst out a single A-MPDU frame if both ends support this. I may end adding a FreeBSD IE soon to negotiate this power save behaviour. * I should make STAs timeout of power save mode if they've been in power save for more than a handful of seconds. This way cards that get "stuck" in power save mode don't stay there for the "inactivity" timeout in net80211. * Move the queue depth check into the driver layer (ath_start / ath_transmit) rather than doing it in the TX path. * There could be some naughty corner cases with ps-poll leaking. Specifically, if net80211 generates a NULL data frame whilst another transmitter sends a normal data frame out net80211 output / transmit, we need to ensure that the NULL data frame goes out first. This is one of those things that should occur inside the VAP/ic TX lock. Grr, more investigations to do.. Tested: * STA: AR5416, AR9280 * AP: AR5416, AR9280, AR9160
2013-05-15 18:33:05 +00:00
__func__,
ni->ni_macaddr,
":");
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
an->an_tim_set = 0;
(void) avp->av_set_tim(ni, 0);
}
}
Disable my software queue TIM and PS handling for now. ps-poll is totally broken in its current form. This should unbreak things enough to let people use PS-POLL devices, but leave it in place for me to finish PS-POLL handling.
2012-11-07 06:29:45 +00:00
#else
return;
#endif /* ATH_SW_PSQ */
Begin fleshing out some software queue awareness for TIM handling with the power save queue. * introduce some new ATH_NODE lock protected fields, tracking the net80211 psq and TIM state; * when doing buffer transitions - ie, when sending and completing buffers - check the state of the SWQ and update the TIM appropriately. * when clearing the TIM bit, if the SWQ is not empty then delay clearing it. This is racy, but it's no less racy than the current net80211 power save queue management code. Specifically, with multiple TX threads, it's quite plausible that parallel state updates will race and the TIM will be left in an inconsistent state. I'll address that in a follow-up commit.
2012-10-28 21:13:12 +00:00
}
Pause and unpause the software queues for a given node based on the net80211 node power save state. * Add an ATH_NODE_UNLOCK_ASSERT() check * Add a new node field - an_is_powersave * Pause/unpause the queue based on the node state * Attempt to handle net80211 concurrency issues so the queue doesn't get paused/unpaused more than once at a time from the net80211 power save code. Whilst here (and breaking my usual rule), set CLRDMASK when a queue is unpaused, regardless of whether the queue has some pending traffic. This means the first frame from that TID (now or later) will hvae CLRDMASK set. Also whilst here, bump the swretrymax counters whenever the filtered frames code expires a frame. Again, breaking my rule, but this is just a statistics thing rather than a functional change. This doesn't fix ps-poll (but it doesn't break it too much worse than it is at the present) or correcting the TID updates. That's next on the list. Tested: * AR9220 AP (Atheros AP96 reference design) * Macbook Pro and LG Optimus 1 Android phone, both setting and clearing power save state (but not using PS-POLL.)
2012-10-03 23:23:45 +00:00
Implement my first cut at "correct" node power-save and PS-POLL support. This implements PS-POLL awareness i nthe * Implement frame "leaking", which allows for a software queue to be scheduled even though it's asleep * Track whether a frame has been leaked or not * Leak out a single non-AMPDU frame when transmitting aggregates * Queue BAR frames if the node is asleep * Direct-dispatch the rest of control and management frames. This allows for things like re-association to occur (which involves sending probe req/resp as well as assoc request/response) when the node is asleep and then tries reassociating. * Limit how many frames can set in the software node queue whilst the node is asleep. net80211 is already buffering frames for us so this is mostly just paranoia. * Add a PS-POLL method which leaks out a frame if there's something in the software queue, else it calls net80211's ps-poll routine. Since the ath PS-POLL routine marks the node as having a single frame to leak, either a software queued frame would leak, OR the next queued frame would leak. The next queued frame could be something from the net80211 power save queue, OR it could be a NULL frame from net80211. TODO: * Don't transmit further BAR frames (eg via a timeout) if the node is currently asleep. Otherwise we may end up exhausting management frames due to the lots of queued BAR frames. I may just undo this bit later on and direct-dispatch BAR frames even if the node is asleep. * It would be nice to burst out a single A-MPDU frame if both ends support this. I may end adding a FreeBSD IE soon to negotiate this power save behaviour. * I should make STAs timeout of power save mode if they've been in power save for more than a handful of seconds. This way cards that get "stuck" in power save mode don't stay there for the "inactivity" timeout in net80211. * Move the queue depth check into the driver layer (ath_start / ath_transmit) rather than doing it in the TX path. * There could be some naughty corner cases with ps-poll leaking. Specifically, if net80211 generates a NULL data frame whilst another transmitter sends a normal data frame out net80211 output / transmit, we need to ensure that the NULL data frame goes out first. This is one of those things that should occur inside the VAP/ic TX lock. Grr, more investigations to do.. Tested: * STA: AR5416, AR9280 * AP: AR5416, AR9280, AR9160
2013-05-15 18:33:05 +00:00
/*
* Received a ps-poll frame from net80211.
*
* Here we get a chance to serve out a software-queued frame ourselves
* before we punt it to net80211 to transmit us one itself - either
* because there's traffic in the net80211 psq, or a NULL frame to
* indicate there's nothing else.
*/
static void
ath_node_recv_pspoll(struct ieee80211_node *ni, struct mbuf *m)
{
#ifdef ATH_SW_PSQ
struct ath_node *an;
struct ath_vap *avp;
struct ieee80211com *ic = ni->ni_ic;
Remove most of the references of ifp->if_softc and replace with references to ic->ic_softc. This is in preparation for gleb's ifnet work. Tested: * ath(4), STA mode * ath(4), hostap mode * make universe
2015-08-17 02:04:11 +00:00
struct ath_softc *sc = ic->ic_softc;
Implement my first cut at "correct" node power-save and PS-POLL support. This implements PS-POLL awareness i nthe * Implement frame "leaking", which allows for a software queue to be scheduled even though it's asleep * Track whether a frame has been leaked or not * Leak out a single non-AMPDU frame when transmitting aggregates * Queue BAR frames if the node is asleep * Direct-dispatch the rest of control and management frames. This allows for things like re-association to occur (which involves sending probe req/resp as well as assoc request/response) when the node is asleep and then tries reassociating. * Limit how many frames can set in the software node queue whilst the node is asleep. net80211 is already buffering frames for us so this is mostly just paranoia. * Add a PS-POLL method which leaks out a frame if there's something in the software queue, else it calls net80211's ps-poll routine. Since the ath PS-POLL routine marks the node as having a single frame to leak, either a software queued frame would leak, OR the next queued frame would leak. The next queued frame could be something from the net80211 power save queue, OR it could be a NULL frame from net80211. TODO: * Don't transmit further BAR frames (eg via a timeout) if the node is currently asleep. Otherwise we may end up exhausting management frames due to the lots of queued BAR frames. I may just undo this bit later on and direct-dispatch BAR frames even if the node is asleep. * It would be nice to burst out a single A-MPDU frame if both ends support this. I may end adding a FreeBSD IE soon to negotiate this power save behaviour. * I should make STAs timeout of power save mode if they've been in power save for more than a handful of seconds. This way cards that get "stuck" in power save mode don't stay there for the "inactivity" timeout in net80211. * Move the queue depth check into the driver layer (ath_start / ath_transmit) rather than doing it in the TX path. * There could be some naughty corner cases with ps-poll leaking. Specifically, if net80211 generates a NULL data frame whilst another transmitter sends a normal data frame out net80211 output / transmit, we need to ensure that the NULL data frame goes out first. This is one of those things that should occur inside the VAP/ic TX lock. Grr, more investigations to do.. Tested: * STA: AR5416, AR9280 * AP: AR5416, AR9280, AR9160
2013-05-15 18:33:05 +00:00
int tid;
/* Just paranoia */
if (ni == NULL)
return;
/*
* Unassociated (temporary node) station.
*/
if (ni->ni_associd == 0)
return;
/*
* We do have an active node, so let's begin looking into it.
*/
an = ATH_NODE(ni);
avp = ATH_VAP(ni->ni_vap);
/*
* For now, we just call the original ps-poll method.
* Once we're ready to flip this on:
*
* + Set leak to 1, as no matter what we're going to have
* to send a frame;
* + Check the software queue and if there's something in it,
* schedule the highest TID thas has traffic from this node.
* Then make sure we schedule the software scheduler to
* run so it picks up said frame.
*
* That way whatever happens, we'll at least send _a_ frame
* to the given node.
*
* Again, yes, it's crappy QoS if the node has multiple
* TIDs worth of traffic - but let's get it working first
* before we optimise it.
*
* Also yes, there's definitely latency here - we're not
* direct dispatching to the hardware in this path (and
* we're likely being called from the packet receive path,
* so going back into TX may be a little hairy!) but again
* I'd like to get this working first before optimising
* turn-around time.
*/
ATH_TX_LOCK(sc);
/*
* Legacy - we're called and the node isn't asleep.
* Immediately punt.
*/
if (! an->an_is_powersave) {
Move a lot of debugging printf's to DPRINTF. Approved by: adrian MFC after: 2 weeks
2013-10-17 01:53:07 +00:00
DPRINTF(sc, ATH_DEBUG_NODE_PWRSAVE,
Implement my first cut at "correct" node power-save and PS-POLL support. This implements PS-POLL awareness i nthe * Implement frame "leaking", which allows for a software queue to be scheduled even though it's asleep * Track whether a frame has been leaked or not * Leak out a single non-AMPDU frame when transmitting aggregates * Queue BAR frames if the node is asleep * Direct-dispatch the rest of control and management frames. This allows for things like re-association to occur (which involves sending probe req/resp as well as assoc request/response) when the node is asleep and then tries reassociating. * Limit how many frames can set in the software node queue whilst the node is asleep. net80211 is already buffering frames for us so this is mostly just paranoia. * Add a PS-POLL method which leaks out a frame if there's something in the software queue, else it calls net80211's ps-poll routine. Since the ath PS-POLL routine marks the node as having a single frame to leak, either a software queued frame would leak, OR the next queued frame would leak. The next queued frame could be something from the net80211 power save queue, OR it could be a NULL frame from net80211. TODO: * Don't transmit further BAR frames (eg via a timeout) if the node is currently asleep. Otherwise we may end up exhausting management frames due to the lots of queued BAR frames. I may just undo this bit later on and direct-dispatch BAR frames even if the node is asleep. * It would be nice to burst out a single A-MPDU frame if both ends support this. I may end adding a FreeBSD IE soon to negotiate this power save behaviour. * I should make STAs timeout of power save mode if they've been in power save for more than a handful of seconds. This way cards that get "stuck" in power save mode don't stay there for the "inactivity" timeout in net80211. * Move the queue depth check into the driver layer (ath_start / ath_transmit) rather than doing it in the TX path. * There could be some naughty corner cases with ps-poll leaking. Specifically, if net80211 generates a NULL data frame whilst another transmitter sends a normal data frame out net80211 output / transmit, we need to ensure that the NULL data frame goes out first. This is one of those things that should occur inside the VAP/ic TX lock. Grr, more investigations to do.. Tested: * STA: AR5416, AR9280 * AP: AR5416, AR9280, AR9160
2013-05-15 18:33:05 +00:00
"%s: %6D: not in powersave?\n",
__func__,
ni->ni_macaddr,
":");
ATH_TX_UNLOCK(sc);
avp->av_recv_pspoll(ni, m);
return;
}
/*
* We're in powersave.
*
* Leak a frame.
*/
an->an_leak_count = 1;
/*
* Now, if there's no frames in the node, just punt to
* recv_pspoll.
*
* Don't bother checking if the TIM bit is set, we really
* only care if there are any frames here!
*/
if (an->an_swq_depth == 0) {
ATH_TX_UNLOCK(sc);
DPRINTF(sc, ATH_DEBUG_NODE_PWRSAVE,
"%s: %6D: SWQ empty; punting to net80211\n",
__func__,
ni->ni_macaddr,
":");
avp->av_recv_pspoll(ni, m);
return;
}
/*
* Ok, let's schedule the highest TID that has traffic
* and then schedule something.
*/
for (tid = IEEE80211_TID_SIZE - 1; tid >= 0; tid--) {
struct ath_tid *atid = &an->an_tid[tid];
/*
* No frames? Skip.
*/
if (atid->axq_depth == 0)
continue;
ath_tx_tid_sched(sc, atid);
/*
* XXX we could do a direct call to the TXQ
* scheduler code here to optimise latency
* at the expense of a REALLY deep callstack.
*/
ATH_TX_UNLOCK(sc);
taskqueue_enqueue(sc->sc_tq, &sc->sc_txqtask);
DPRINTF(sc, ATH_DEBUG_NODE_PWRSAVE,
"%s: %6D: leaking frame to TID %d\n",
__func__,
ni->ni_macaddr,
":",
tid);
return;
}
ATH_TX_UNLOCK(sc);
/*
* XXX nothing in the TIDs at this point? Eek.
*/
Move a lot of debugging printf's to DPRINTF. Approved by: adrian MFC after: 2 weeks
2013-10-17 01:53:07 +00:00
DPRINTF(sc, ATH_DEBUG_NODE_PWRSAVE,
"%s: %6D: TIDs empty, but ath_node showed traffic?!\n",
Implement my first cut at "correct" node power-save and PS-POLL support. This implements PS-POLL awareness i nthe * Implement frame "leaking", which allows for a software queue to be scheduled even though it's asleep * Track whether a frame has been leaked or not * Leak out a single non-AMPDU frame when transmitting aggregates * Queue BAR frames if the node is asleep * Direct-dispatch the rest of control and management frames. This allows for things like re-association to occur (which involves sending probe req/resp as well as assoc request/response) when the node is asleep and then tries reassociating. * Limit how many frames can set in the software node queue whilst the node is asleep. net80211 is already buffering frames for us so this is mostly just paranoia. * Add a PS-POLL method which leaks out a frame if there's something in the software queue, else it calls net80211's ps-poll routine. Since the ath PS-POLL routine marks the node as having a single frame to leak, either a software queued frame would leak, OR the next queued frame would leak. The next queued frame could be something from the net80211 power save queue, OR it could be a NULL frame from net80211. TODO: * Don't transmit further BAR frames (eg via a timeout) if the node is currently asleep. Otherwise we may end up exhausting management frames due to the lots of queued BAR frames. I may just undo this bit later on and direct-dispatch BAR frames even if the node is asleep. * It would be nice to burst out a single A-MPDU frame if both ends support this. I may end adding a FreeBSD IE soon to negotiate this power save behaviour. * I should make STAs timeout of power save mode if they've been in power save for more than a handful of seconds. This way cards that get "stuck" in power save mode don't stay there for the "inactivity" timeout in net80211. * Move the queue depth check into the driver layer (ath_start / ath_transmit) rather than doing it in the TX path. * There could be some naughty corner cases with ps-poll leaking. Specifically, if net80211 generates a NULL data frame whilst another transmitter sends a normal data frame out net80211 output / transmit, we need to ensure that the NULL data frame goes out first. This is one of those things that should occur inside the VAP/ic TX lock. Grr, more investigations to do.. Tested: * STA: AR5416, AR9280 * AP: AR5416, AR9280, AR9160
2013-05-15 18:33:05 +00:00
__func__,
ni->ni_macaddr,
":");
avp->av_recv_pspoll(ni, m);
#else
avp->av_recv_pspoll(ni, m);
#endif /* ATH_SW_PSQ */
}
[ath] [ath_hal] (etc, etc) - begin the task of re-modularising the HAL. In the deep past, when this code compiled as a binary module, ath_hal built as a module. This allowed custom, smaller HAL modules to be built. This was especially beneficial for small embedded platforms where you didn't require /everything/ just to run. However, sometime around the HAL opening fanfare, the HAL landed here as one big driver+HAL thing, and a lot of the (dirty) infrastructure (ie, #ifdef AH_SUPPORT_XXX) to build specific subsets of the HAL went away. This was retained in sys/conf/files as "ath_hal_XXX" but it wasn't really floated up to the modules themselves. I'm now in a position where for the reaaaaaly embedded boards (both the really old and the last couple generation of QCA MIPS boards) having a cut down HAL module and driver loaded at runtime is /actually/ beneficial. This reduces the kernel size down by quite a bit. The MIPS modules look like this: adrian@gertrude:~/work/freebsd/head-embedded/src % ls -l ../root/mips_ap/boot/kernel.CARAMBOLA2/ath*ko -r-xr-xr-x 1 adrian adrian 5076 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_dfs.ko -r-xr-xr-x 1 adrian adrian 100588 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_hal.ko -r-xr-xr-x 1 adrian adrian 627324 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_hal_ar9300.ko -r-xr-xr-x 1 adrian adrian 314588 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_main.ko -r-xr-xr-x 1 adrian adrian 23472 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_rate.ko And the x86 versions, like this: root@gertrude:/home/adrian # ls -l /boot/kernel/ath*ko -r-xr-xr-x 1 root wheel 36632 May 24 18:32 /boot/kernel/ath_dfs.ko -r-xr-xr-x 1 root wheel 134440 May 24 18:32 /boot/kernel/ath_hal.ko -r-xr-xr-x 1 root wheel 82320 May 24 18:32 /boot/kernel/ath_hal_ar5210.ko -r-xr-xr-x 1 root wheel 104976 May 24 18:32 /boot/kernel/ath_hal_ar5211.ko -r-xr-xr-x 1 root wheel 236144 May 24 18:32 /boot/kernel/ath_hal_ar5212.ko -r-xr-xr-x 1 root wheel 336104 May 24 18:32 /boot/kernel/ath_hal_ar5416.ko -r-xr-xr-x 1 root wheel 598336 May 24 18:32 /boot/kernel/ath_hal_ar9300.ko -r-xr-xr-x 1 root wheel 406144 May 24 18:32 /boot/kernel/ath_main.ko -r-xr-xr-x 1 root wheel 55352 May 24 18:32 /boot/kernel/ath_rate.ko .. so you can see, not building the whole HAL can save quite a bit. For example, if you don't need AR9300 support, you can actually avoid wasting half a megabyte of RAM. On embedded routers this is quite a big deal. The AR9300 HAL can be later further shrunk because, hilariously, it indeed supports AH_SUPPORT_<xxx> for optionally adding chipset support. (I'll chase that down later as it's quite a big savings if you're only building for a single embedded target.) So: * Create a very hackish way to load/unload HAL modules * Create module metadata for each HAL subtype - ah_osdep_arXXXX.c * Create module metadata for ath_rate and ath_dfs (bluetooth is currently just built as part of it) * .. yes, this means we could actually build multiple rate control modules and pick one at load time, but I'd rather just glue this into net80211's rate control code. Oh well, baby steps. * Main driver is now "ath_main" * Create an "if_ath" module that does what the ye olde one did - load PCI glue, main driver, HAL and all child modules. In this way, if you have "if_ath_load=YES" in /boot/modules.conf it will load everything the old way and stuff should still work. * For module autoloading purposes, I actually /did/ fix up the name of the modules in if_ath_pci and if_ath_ahb. If you want to selectively load things (eg on ye cheape ARM/MIPS platforms where RAM is at a premium) you should: * load ath_hal * load the chip modules in question * load ath_rate, ath_dfs * load ath_main * load if_ath_pci and/or if_ath_ahb depending upon your particular bus bind type - this is where probe/attach is done. TODO: * AR5312 module and associated pieces - yes, we have the SoC side support now so the wifi support would be good to "round things out"; * Just nuke AH_SUPPORT_AR5416 for now and always bloat the packet structures; this'll simplify other things. * Should add a simple refcnt thing to the HAL RF/chip modules so you can't unload them whilst you're using them. * Manpage updates, UPDATING if appropriate, etc.
2017-05-25 04:18:46 +00:00
MODULE_VERSION(ath_main, 1);
MODULE_DEPEND(ath_main, wlan, 1, 1, 1); /* 802.11 media layer */
MODULE_DEPEND(ath_main, ath_rate, 1, 1, 1);
MODULE_DEPEND(ath_main, ath_dfs, 1, 1, 1);
MODULE_DEPEND(ath_main, ath_hal, 1, 1, 1);
Add initial support for the AR9485 CUS198 / CUS230 variants. These variants have a few differences from the default AR9485 NIC, namely: * a non-default antenna switch config; * slightly different RX gain table setup; * an external XLNA hooked up to a GPIO pin; * (and not yet done) RSSI threshold differences when doing slow diversity. To make this possible: * Add the PCI device list from Linux ath9k, complete with vendor and sub-vendor IDs for various things to be enabled; * .. and until FreeBSD learns about a PCI device list like this, write a search function inspired by the USB device enumeration code; * add HAL_OPS_CONFIG to the HAL attach methods; the HAL can use this to initialise its local driver parameters upon attach; * copy these parameters over in the AR9300 HAL; * don't default to override the antenna switch - only do it for the chips that require it; * I brought over ar9300_attenuation_apply() from ath9k which is cleaner and easier to read for this particular NIC. This is a work in progress. I'm worried that there's some post-AR9380 NIC out there which doesn't work without the antenna override set as I currently haven't implemented bluetooth coexistence for the AR9380 and later HAL. But I'd rather have this code in the tree and fix it up before 11.0-RELEASE happens versus having a set of newer NICs in laptops be effectively RX deaf. Tested: * AR9380 (STA) * AR9485 CUS198 (STA) Obtained from: Qualcomm Atheros, Linux ath9k
2014-09-30 03:19:29 +00:00
#if defined(IEEE80211_ALQ) || defined(AH_DEBUG_ALQ) || defined(ATH_DEBUG_ALQ)
[ath] [ath_hal] (etc, etc) - begin the task of re-modularising the HAL. In the deep past, when this code compiled as a binary module, ath_hal built as a module. This allowed custom, smaller HAL modules to be built. This was especially beneficial for small embedded platforms where you didn't require /everything/ just to run. However, sometime around the HAL opening fanfare, the HAL landed here as one big driver+HAL thing, and a lot of the (dirty) infrastructure (ie, #ifdef AH_SUPPORT_XXX) to build specific subsets of the HAL went away. This was retained in sys/conf/files as "ath_hal_XXX" but it wasn't really floated up to the modules themselves. I'm now in a position where for the reaaaaaly embedded boards (both the really old and the last couple generation of QCA MIPS boards) having a cut down HAL module and driver loaded at runtime is /actually/ beneficial. This reduces the kernel size down by quite a bit. The MIPS modules look like this: adrian@gertrude:~/work/freebsd/head-embedded/src % ls -l ../root/mips_ap/boot/kernel.CARAMBOLA2/ath*ko -r-xr-xr-x 1 adrian adrian 5076 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_dfs.ko -r-xr-xr-x 1 adrian adrian 100588 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_hal.ko -r-xr-xr-x 1 adrian adrian 627324 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_hal_ar9300.ko -r-xr-xr-x 1 adrian adrian 314588 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_main.ko -r-xr-xr-x 1 adrian adrian 23472 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_rate.ko And the x86 versions, like this: root@gertrude:/home/adrian # ls -l /boot/kernel/ath*ko -r-xr-xr-x 1 root wheel 36632 May 24 18:32 /boot/kernel/ath_dfs.ko -r-xr-xr-x 1 root wheel 134440 May 24 18:32 /boot/kernel/ath_hal.ko -r-xr-xr-x 1 root wheel 82320 May 24 18:32 /boot/kernel/ath_hal_ar5210.ko -r-xr-xr-x 1 root wheel 104976 May 24 18:32 /boot/kernel/ath_hal_ar5211.ko -r-xr-xr-x 1 root wheel 236144 May 24 18:32 /boot/kernel/ath_hal_ar5212.ko -r-xr-xr-x 1 root wheel 336104 May 24 18:32 /boot/kernel/ath_hal_ar5416.ko -r-xr-xr-x 1 root wheel 598336 May 24 18:32 /boot/kernel/ath_hal_ar9300.ko -r-xr-xr-x 1 root wheel 406144 May 24 18:32 /boot/kernel/ath_main.ko -r-xr-xr-x 1 root wheel 55352 May 24 18:32 /boot/kernel/ath_rate.ko .. so you can see, not building the whole HAL can save quite a bit. For example, if you don't need AR9300 support, you can actually avoid wasting half a megabyte of RAM. On embedded routers this is quite a big deal. The AR9300 HAL can be later further shrunk because, hilariously, it indeed supports AH_SUPPORT_<xxx> for optionally adding chipset support. (I'll chase that down later as it's quite a big savings if you're only building for a single embedded target.) So: * Create a very hackish way to load/unload HAL modules * Create module metadata for each HAL subtype - ah_osdep_arXXXX.c * Create module metadata for ath_rate and ath_dfs (bluetooth is currently just built as part of it) * .. yes, this means we could actually build multiple rate control modules and pick one at load time, but I'd rather just glue this into net80211's rate control code. Oh well, baby steps. * Main driver is now "ath_main" * Create an "if_ath" module that does what the ye olde one did - load PCI glue, main driver, HAL and all child modules. In this way, if you have "if_ath_load=YES" in /boot/modules.conf it will load everything the old way and stuff should still work. * For module autoloading purposes, I actually /did/ fix up the name of the modules in if_ath_pci and if_ath_ahb. If you want to selectively load things (eg on ye cheape ARM/MIPS platforms where RAM is at a premium) you should: * load ath_hal * load the chip modules in question * load ath_rate, ath_dfs * load ath_main * load if_ath_pci and/or if_ath_ahb depending upon your particular bus bind type - this is where probe/attach is done. TODO: * AR5312 module and associated pieces - yes, we have the SoC side support now so the wifi support would be good to "round things out"; * Just nuke AH_SUPPORT_AR5416 for now and always bloat the packet structures; this'll simplify other things. * Should add a simple refcnt thing to the HAL RF/chip modules so you can't unload them whilst you're using them. * Manpage updates, UPDATING if appropriate, etc.
2017-05-25 04:18:46 +00:00
MODULE_DEPEND(ath_main, alq, 1, 1, 1);
Add a dependency on ALQ if IEEE80211_ALQ and/or AH_DEBUG_ALQ is included.
2012-03-16 23:12:40 +00:00
#endif
Reference in New Issue Copy Permalink