summaryrefslogtreecommitdiff
path: root/sys/dev/ath/if_ath.c
Commit message (Collapse)AuthorAgeFilesLines
* WiFi: fix ieee80211_media_change() callersBjoern A. Zeeb2020-09-071-11/+2
| | | | | | | | | | | | | | | | | | | | | In r178354 with the introduction of multi-bss ("vap") support factoring out started and with r193340 ieee80211_media_change() no longer returned ENETRESET but only 0 or error. As ieee80211(9) tells the ieee80211_media_change() function should not be called directly but is registered with ieee80211_vap_attach() instead. Some drivers have not been fully converted. After fixing the return checking some of these functions were simply wrappers between ieee80211_vap_attach() and ieee80211_media_change(), so remove the extra function, where possible as well. PR: 248955 Submitted by: Tong Zhang (ztong0001 gmail.com) (original) MFC after: 3 days Sponsored by: The FreeBSD Foundation Notes: svn path=/head/; revision=365419
* ath: clean up empty lines in .c and .h filesMateusz Guzik2020-09-011-5/+1
| | | | Notes: svn path=/head/; revision=365116
* [ath] [ath_hal] Propagate the HAL_RESET_TYPE through to the chip reset; set ↵Adrian Chadd2020-05-251-8/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | it during ath_reset() Although I added the reset type field to ath_hal_reset() years ago, I never finished adding it both throughout the HALs and in if_ath.c. This will eventually deprecate the ath_hal force_full_reset option because it can be requested at the driver layer. So: * Teach ar5416ChipReset() and ar9300_chip_reset() about the HAL type * Use it in ar5416Reset() and ar9300_reset() when doing a full chip reset * Extend ath_reset() to include the HAL_RESET_TYPE parameter added in the above functions * Use HAL_RESET_NORMAL in most calls to ath_reset() * .. but use HAL_RESET_BBPANIC for the BB panics, and HAL_RESET_FORCE_COLD during fatal, beacon miss and other hardware related hangs. This should be a glorified no-op outside of actual hardware issues. I've tested things with ath_hal force_full_reset set to 1 for years now, so I know that feature and a full reset works (albeit much slower than a warm reset!) and it does unwedge hardware. The eventual aim is to use this for all the places where the driver detects a potential hang as well as if long calibration - ie, noise floor calibration - fails to complete. That's one of the big hardware related things that causes station mode operation to hang without easy recovery. Differential Revision: https://reviews.freebsd.org/D24981 Notes: svn path=/head/; revision=361486
* [ath] Hopefully recover better-er upon RX restart on AR9380.Adrian Chadd2020-05-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is all very long-standing bug stuff that is touchy and still poorly documented. Ok, here goes. The basic bug: * deleting a VAP causes the RX path (and TX path too) to be restarted without a full chip reset, which causes RX hangs on the AR9380 and later. (ie, the ones with the newer DMA engine.) The basic fix: * do an RX flush when stopping RX in ath_vap_delete() to match what happens when RX is stopped elsewhere. This ensures any pending frames are completed and we restart at the right spot; it also ensures we don't push new RX buffers into the hardware if we're stopping receive. The other issues I found: * Don't bother checking the RX packet ring in the deferred read taskqueue; that's specifically supposed to be for completing frames rather than just yanking them off the receive ring. * Cancel/drain any pending deferred read taskqueue. This isn't done inside any locks so we should be super careful here. This stops the hardware being reprogrammed at the same time in another thread/CPU whilst we're stopping RX. * .. (yes, this should be better serialised, but that's for another day. maybe.) * Add more debugging to trace what's going on here. And the fun bit: * Reinitialise the RX FIFO ONLY if we've been reset or stopped, rather than just reset. I noticed that after all the above was done I was STILL seeing RXEOL. RXEOL isn't enabled on the AR9380 so I'd only see it if I was sending TX frames (ie a ping where it'd be transmitted but never received) so I was not being spammed by RXEOL. So, as long as stuff is stopped, restart it. This seems to be doing the right thing in both AP and STA modes. What I should do next, if I ever get time: * as I said above, serialise the receive stop/start to include taskqueues * monitor RXEOL on the AR9380 and I keep seeing it spammed / lockups, just go do a full chip reset to get things back on track. It sucks, but it is better than nothing. Tested: * AR9380 AP/STA mode, adding/deleting a hostap VAP to trigger the TX/RX queue stop/start; whilst also running an iperf through it. Lots of times. Lots. Of.. Times. Notes: svn path=/head/; revision=361321
* [ath] [ath_rate] Extend ath_rate_sample to better handle 11n rates and ↵Adrian Chadd2020-05-151-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | aggregates. My initial rate control code was .. suboptimal. I wanted to at least get MCS rates sent, but it didn't do anywhere near enough to handle low signal level links or remotely keep accurate statistics. So, 8 years later, here's what I should've done back then. * Firstly, I wasn't at all tracking packet sizes other than the two buckets (250 and 1600 bytes.) So, extend it to include 4096, 8192, 16384, 32768 and 65536. I may go add 2048 at some point if I find it's useful. This is important for a few reasons. First, when forming A-MPDU or AMSDU aggregates the frame sizes are larger, and thus the TX time calculation is woefully, increasingly wrong. Secondly, the behaviour of 802.11 channels isn't some fixed thing, both due to channel conditions and radios themselves. Notably, there was some observations done a few years ago on 11n chipsets which noticed longer aggregates showed an increase in failed A-MPDU sub-frame reception as you got further along in the transmit time. It could be due to a variety of things - transmitter linearity, channel conditions changing, frequency/phase drift, etc - but the observation was to potentially form shorter aggregates to improve BER. * .. and then modify the ath TX path to report the length of the aggregate sent, so as the statistics kept would line up with the correct bucket. * Then on the rate control look-up side - i was also only using the first frame length for an A-MPDU rate control lookup which isn't good enough here. So, add a new method that walks the TID software queue for that node to find out what the likely length of data available is. It isn't ALL of the data in the queue because we'll only ever send enough data to fit inside the block-ack window, so limit how many bytes we return to roughly what ath_tx_form_aggr() would do. * .. and cache that in the first ath_buf in the aggregate so it and the eventual AMPDU length can be returned to the rate control code. * THEN, modify the rate control code to look at them both when deciding which bucket to attribute the sent frame on. I'm erring on the side of caution and using the size bucket that the lookup is based on. Ok, so now the rate lookups and statistics are "more correct". However, MCS rates are not the same as 11abg rates in that they're not a monotonically incrementing set of faster rates and you can't assume that just because a given MCS rate fails, the next higher one wouldn't work better or be a lower average tx time. So, I had to do a bunch of surgery to the best rate and sample rate math. This is the bit that's a WIP. * First, simplify the statistics updates (update_stats()) to do a single pass on all rates. * Next, make sure that each rate average tx time is updated based on /its/ failure/success. Eg if you sent a frame with { MCS15, MCS12, MCS8 } and MCS8 succeeded, MCS15 and MCS 12 would have their average tx time updated for /their/ part of the transmission, not the whole transmission. * Next, EWMA wasn't being fully calculated based on the /failures/ in each of the rate attempts. So, if MCS15, MCS12 failed above but MCS8 didn't, then ensure that the statistics noted that /all/ subframes failed at those rates, rather than the eventual set of transmitted/sent frames. This ensures the EWMA /and/ average TX time are updated correctly. * When picking a sample rate and initial rate, probe rates aroud the current MCS but limit it to MCS0..7 /for all spatial streams/, rather than doing crazy things like hitting MCS7 and then probing MCS8 - MCS8 is basically MCS0 but two spatial streams. It's a /lot/ slower than MCS7. Also, the reverse is true - if we're at MCS8 then don't probe MCS7 as part of it, it's not likely to succeed. * Fix bugs in pick_best_rate() where I was /immediately/ choosing the highest MCS rate if there weren't any frames yet transmitted. I was defaulting to 25% EWMA and .. then each comparison would accept the higher rate. Just skip those; sampling will fill in the details. So, this seems to work a lot better. It's not perfect; I'm still seeing a lot of instability around higher MCS rates because there are bursts of loss/retransmissions that aren't /too/ bad. But i'll keep iterating over this and tidying up my hacks. Ok, so why this still something I'm poking at? rather than porting minstrel_ht? ath_rate_sample tries to minimise airtime, not maximise throughput. I have extended it with an EWMA based on sub-frame success/failures - high MCS rates that have partially successful receptions still show super short average frame times, but a /lot/ of retransmits have to happen for that to work. So for MCS rates I also track this EWMA and ensure that the rates I'm choosing don't have super crappy packet failures. I don't mind not getting lower peak throughput versus minstrel_ht; instead I want to see if I can make "minimise airtime" work well. Tested: * AR9380, STA mode * AR9344, STA mode * AR9580, STA/AP mode Notes: svn path=/head/; revision=361085
* [ath] [ath_rate] Add some extra data into the rate control lookup.Adrian Chadd2020-05-131-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Right now (well, since I did this in 2011/2012) the rate control code makes some super bad choices for 11n aggregates/rates, and it tracks statistics even more questionably. It's been long enough and I'm now trying to use it again daily, so let's start by: * telling the rate control code if it's an aggregate or not; * being clearer about the TID - yes it can be extracted from the ath_buf but this way it can be overridden by the caller without changing the TID itself. (This is for doing experiments with voice/video QoS at some point..) * Return an optional field to limit how long the aggregate is in microseconds. Right now the rate control code supplies a rate table and the ath aggr form code will look at the rate table and limit the aggregate size to 4ms at the slowest rate. Yeah, this is pretty terrible. * Add some more TODO comments around handling txpower, rate and handling filtered frames status so if I continue to have spoons for this I can go poke at it. Notes: svn path=/head/; revision=360998
* [ath] Attempt to fix epoch handling.Adrian Chadd2020-02-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The epoch stuff with taskqueues works fine if the driver never calls the receive path in other contexts, but this driver does. If there was a chip reset during active receive then part of the reset will call the receive path to flush out any active packets before reinitialising the receive queue and that needs to be done with the epoch held. So: * make the receive task a normal task again * explicitly call epoch enter/exit around the legacy and newer DMA receive paths * add a couple of epoch asserts to ensure that the receive packet path itself is called with epoch held. This fixes it on my Atom eeepc laptop (circa 2010!) that I did all of my initial 802.11n work in this driver and net80211. Tested: * AR9285, STA mode TODO: * Test on EDMA chipset (AR9380) * Test in AP/adhoc modes, just to be sure (eg for beacon receive processing in particular.) Notes: svn path=/head/; revision=358156
* Use NET_TASK_INIT() and NET_GROUPTASK_INIT() for drivers that processGleb Smirnoff2020-02-111-1/+1
| | | | | | | | | | incoming packets in taskqueue context. Reviewed by: hselasky Differential Revision: https://reviews.freebsd.org/D23518 Notes: svn path=/head/; revision=357772
* Convert to if_foreach_llmaddr() KPI.Gleb Smirnoff2019-10-211-24/+21
| | | | Notes: svn path=/head/; revision=353809
* [ath] [ath_rate] Fix ANI calibration during non-ACTIVE states; start poking ↵Adrian Chadd2019-05-051-0/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=347140
* ath(4): Fix typo in debugging codeConrad Meyer2018-07-051-1/+1
| | | | | | | | PR: 229548 Submitted by: David Binderman <dcb314 AT hotmail.com> Notes: svn path=/head/; revision=336016
* ifnet: Replace if_addr_lock rwlock with epoch + mutexMatt Macy2018-05-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Run on LLNW canaries and tested by pho@ gallatin: Using a 14-core, 28-HTT single socket E5-2697 v3 with a 40GbE MLX5 based ConnectX 4-LX NIC, I see an almost 12% improvement in received packet rate, and a larger improvement in bytes delivered all the way to userspace. When the host receiving 64 streams of netperf -H $DUT -t UDP_STREAM -- -m 1, I see, using nstat -I mce0 1 before the patch: InMpps OMpps InGbs OGbs err TCP Est %CPU syscalls csw irq GBfree 4.98 0.00 4.42 0.00 4235592 33 83.80 4720653 2149771 1235 247.32 4.73 0.00 4.20 0.00 4025260 33 82.99 4724900 2139833 1204 247.32 4.72 0.00 4.20 0.00 4035252 33 82.14 4719162 2132023 1264 247.32 4.71 0.00 4.21 0.00 4073206 33 83.68 4744973 2123317 1347 247.32 4.72 0.00 4.21 0.00 4061118 33 80.82 4713615 2188091 1490 247.32 4.72 0.00 4.21 0.00 4051675 33 85.29 4727399 2109011 1205 247.32 4.73 0.00 4.21 0.00 4039056 33 84.65 4724735 2102603 1053 247.32 After the patch InMpps OMpps InGbs OGbs err TCP Est %CPU syscalls csw irq GBfree 5.43 0.00 4.20 0.00 3313143 33 84.96 5434214 1900162 2656 245.51 5.43 0.00 4.20 0.00 3308527 33 85.24 5439695 1809382 2521 245.51 5.42 0.00 4.19 0.00 3316778 33 87.54 5416028 1805835 2256 245.51 5.42 0.00 4.19 0.00 3317673 33 90.44 5426044 1763056 2332 245.51 5.42 0.00 4.19 0.00 3314839 33 88.11 5435732 1792218 2499 245.52 5.44 0.00 4.19 0.00 3293228 33 91.84 5426301 1668597 2121 245.52 Similarly, netperf reports 230Mb/s before the patch, and 270Mb/s after the patch Reviewed by: gallatin Sponsored by: Limelight Networks Differential Revision: https://reviews.freebsd.org/D15366 Notes: svn path=/head/; revision=333813
* [ath] Use the BSSID address logic for STA VAPs too.Adrian Chadd2018-02-071-1/+2
| | | | | | | | | | | | | 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. Notes: svn path=/head/; revision=328970
* kernel: Fix several typos and minor errorsEitan Adler2017-12-271-1/+1
| | | | | | | | | | | - duplicate words - typos - references to old versions of FreeBSD Reviewed by: imp, benno Notes: svn path=/head/; revision=327231
* sys/dev: further adoption of SPDX licensing ID tags.Pedro F. Giffuni2017-11-271-0/+2
| | | | | | | | | | | | | | | 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. Notes: svn path=/head/; revision=326255
* [ath] Begin using the replacement EDCA functions.Adrian Chadd2017-10-121-1/+5
| | | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=324571
* [ath] [ath_hal] (etc, etc) - begin the task of re-modularising the HAL.Adrian Chadd2017-05-251-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Notes: svn path=/head/; revision=318856
* [ath] initial station side quiet IE support.Adrian Chadd2017-02-091-1/+182
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Notes: svn path=/head/; revision=313490
* [ath] fix "doing stuff before wakeup" warning; add comments for ACK/CTS ↵Adrian Chadd2017-01-271-0/+103
| | | | | | | | | | | | | | | | | | | | | 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. Notes: svn path=/head/; revision=312853
* [ath] modify cabq and per-node packet usage limits.Adrian Chadd2017-01-231-8/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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. Notes: svn path=/head/; revision=312662
* ath: adapt LDPC support checksAndriy Voskoboinyk2017-01-211-1/+2
| | | | | | | | | | | | 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 Notes: svn path=/head/; revision=312607
* [ath] ensure both iv_ampdu_limit and iv_ampdu_rxmax is set.Adrian Chadd2017-01-211-0/+1
| | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=312562
* [ath] force wake the hardware if we see a missed beacon.Adrian Chadd2016-11-281-19/+55
| | | | | | | | | | | | | | | | | | | | | 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. Notes: svn path=/head/; revision=309256
* [ath_hal] retire a "long RX desc" flag, store/use the TX/RX timestamp length.Adrian Chadd2016-07-081-1/+14
| | | | | | | | | * 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. Notes: svn path=/head/; revision=302461
* [ath] commit initial bluetooth coexistence support for the MCI NICs.Adrian Chadd2016-06-021-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=301181
* dev/ath: minor spelling fixes in comments.Pedro F. Giffuni2016-05-021-8/+8
| | | | | | | | | No functional change. Reviewed by: adrian Notes: svn path=/head/; revision=298939
* [ath] add LDPC capability support and LDPC RX support.Adrian Chadd2016-04-261-0/+13
| | | | | | | | | | | | | | | | | | 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. Notes: svn path=/head/; revision=298608
* net80211: replace internal LE_READ_*/LE_WRITE_* macro with systemAndriy Voskoboinyk2016-04-201-2/+2
| | | | | | | | | | | | | | | | | | | | le*dec / le*enc functions. Replace net80211 specific macros with system-wide bytestream encoding/decoding functions: - LE_READ_2 -> le16dec - LE_READ_4 -> le32dec - LE_WRITE_2 -> le16enc - LE_WRITE_4 -> le32enc + drop ieee80211_input.h include, where it was included for these operations only. Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D6030 Notes: svn path=/head/; revision=298359
* Cleanup unnecessary semicolons from the kernel.Pedro F. Giffuni2016-04-101-1/+0
| | | | | | | Found with devel/coccinelle. Notes: svn path=/head/; revision=297793
* Fix up the ath(4) device names for QCA chipsets.Adrian Chadd2016-02-291-1/+1
| | | | | | | Submitted by: Tobias Kortkamp <t@tobik.me> Notes: svn path=/head/; revision=296176
* [ath] migrate ioctl and busdma memory operations out into separate source files.Adrian Chadd2015-11-241-495/+2
| | | | | | | | | | 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. Notes: svn path=/head/; revision=291233
* ath(4): begin fleshing out a "reset type" extension to force cold/warn resets.Adrian Chadd2015-11-091-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Notes: svn path=/head/; revision=290612
* ath(4) - don't try to free buffers / return an error if we've committedAdrian Chadd2015-11-031-1/+11
| | | | | | | | | | | | | | | | | 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. Notes: svn path=/head/; revision=290339
* net80211: separate mbuf cleanup from ieee80211_fragment()Adrian Chadd2015-10-121-2/+2
| | | | | | | | | | | | | | | * 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 Notes: svn path=/head/; revision=289162
* Remove the unnecessary cast.Kevin Lo2015-10-051-2/+1
| | | | Notes: svn path=/head/; revision=288689
* net80211 & wireless drivers: remove duplicate defines (noop)Adrian Chadd2015-09-221-15/+7
| | | | | | | | | | | | | | * 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 Notes: svn path=/head/; revision=288087
* Replay r286410. Change KPI of how device drivers that provide wirelessGleb Smirnoff2015-08-271-317/+172
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Notes: svn path=/head/; revision=287197
* Remove most of the references of ifp->if_softc and replace withAdrian Chadd2015-08-171-33/+26
| | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=286835
* Revert the wifi ifnet changes until things are more baked and tested.Adrian Chadd2015-08-081-182/+316
| | | | | | | | | | | | * 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. Notes: svn path=/head/; revision=286437
* Change KPI of how device drivers that provide wireless connectivity interactGleb Smirnoff2015-08-071-316/+182
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Details here: https://wiki.freebsd.org/projects/ifnet/net80211 Still, drivers: ndis, wtap, mwl, ipw, bwn, wi, upgt, uath were not tested. Changes to mwl, ipw, bwn, wi, upgt are trivial and chances of problems are low. The wtap wasn't compilable even before this change. But the ndis driver is complex, and it is likely to be broken with this commit. Help with testing and debugging it is appreciated. Differential Revision: D2655, D2740 Sponsored by: Nginx, Inc. Sponsored by: Netflix Notes: svn path=/head/; revision=286410
* Add a hack-around to this fatal taskqueue running whilst the NICAdrian Chadd2015-08-051-0/+3
| | | | | | | | | | | | | | | | 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 .. Notes: svn path=/head/; revision=286343
* Use device_printf() instead of if_printf(). No functional changes.Gleb Smirnoff2015-05-291-70/+81
| | | | Notes: svn path=/head/; revision=283744
* Change three methods in struct ieee80211com, namely ic_updateslot,Gleb Smirnoff2015-05-251-10/+9
| | | | | | | | | | | ic_update_mcast and ic_update_promisc, to pass pointer to the ieee80211com, not to the ifnet. Sponsored by: Netflix Sponsored by: Nginx, Inc. Notes: svn path=/head/; revision=283540
* Set ic_softc in all 802.11 drivers. Not required right now, but will beGleb Smirnoff2015-05-251-0/+1
| | | | | | | | | | used quite soon. Sponsored by: Netflix Sponsored by: Nginx, Inc. Notes: svn path=/head/; revision=283537
* Make net80211 drivers supply their device name to the net80211 layer, soGleb Smirnoff2015-05-251-0/+1
| | | | | | | | | | that the latter doesn't need to go through struct ifnet to get their name. Sponsored by: Netflix Sponsored by: Nginx, Inc. Notes: svn path=/head/; revision=283527
* CALLOUT_MPSAFE has lost its meaning since r141428, i.e., for more than tenJung-uk Kim2015-05-221-1/+1
| | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=283291
* Fix more ticks wrapping bugs exposed by the ticks wrapping bug check.Adrian Chadd2015-03-291-3/+3
| | | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=280825
* Fix a long-standing bug with the early MAC address initialisation path,Adrian Chadd2015-03-291-1/+5
| | | | | | | | | | | | | | | | 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. Notes: svn path=/head/; revision=280802
* Update if_ath(4) to check for "hint.ath.X.macaddr" for an override MAC address.Adrian Chadd2015-03-281-2/+58
| | | | | | | | | 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. Notes: svn path=/head/; revision=280799
* Check the right value correctly.Adrian Chadd2015-01-161-1/+1
| | | | | | | Thanks to clang for pointing out this silliness. Notes: svn path=/head/; revision=277228
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-03 16:55:25 +0000