aboutsummaryrefslogtreecommitdiff
path: root/sys/dev/ath/ath_hal
Commit message (Collapse)AuthorAgeFilesLines
* ath(4): Fix a typo in a device messsageGordon Bergling2025-10-311-1/+1
| | | | | | - s/Orignal/Original/ MFC after: 5 days
* ath(4): Fix a typo in a source code commentGordon Bergling2025-04-281-1/+1
| | | | | | - s/chang/change/ MFC after: 3 days
* Fix enum warning in ath_hal's ar9002Dimitry Andric2024-10-231-1/+1
| | | | | | | | | | | | | | | | | | | | This fixes a clang 19 warning: sys/dev/ath/ath_hal/ar9002/ar9285_btcoex.c:57:32: error: comparison of different enumeration types ('HAL_BOOL' and 'HAL_ANT_SETTING') [-Werror,-Wenum-compare] 57 | (AH5212(ah)->ah_diversity != HAL_ANT_VARIABLE)) { | ~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~ The `ah_diversity` field of `struct ath_hal_5212` is of type `HAL_BOOL`, not the enum type `HAL_ANT_SETTING`. In other code, `ah_diversity` is set to `AH_TRUE` whenever the related field `ah_antControl` is set to `HAL_ANT_VARIABLE`. It is not entirely clear to me what the intended statement is here: the test as it is written now compares the enum value 0 to `ah_diversity`, so in effect it enables the following block whenever `ah_diversity` is `AH_TRUE`. Write it like that, to avoid the compiler warning. MFC after: 3 days
* ath: Fix typo (triple M)Jose Luis Duran2024-02-035-5/+5
| | | | | Reviewed by: imp Pull Request: https://github.com/freebsd/freebsd-src/pull/963
* ath_hal: Fix a couple of type mismatches in function prototypesJohn Baldwin2023-11-152-2/+2
| | | | | | Reported by: GCC 13 via -Wenum-int-mismatch Reviewed by: imp, emaste Differential Revision: https://reviews.freebsd.org/D42584
* sys: Remove $FreeBSD$: two-line .h patternWarner Losh2023-08-16163-326/+0
| | | | Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
* ath(4): Remove MIPS SoC build glue and AR9130 from FreeBSD HALMarius Strobl2023-08-097-1142/+0
| | | | | | | | | | | | All of these are obsoleted by the general removal of MIPS support. Actually, corresponding to the removed AH_SUPPORT_x, there is more superfluous support sprinkled across the HAL source. However, that code is left in place for now in order to ease a sync to NetBSD. Reviewed by: emaste (w/ man page fix) Approved by: adrian Differential Revision: https://reviews.freebsd.org/D41355
* spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSDWarner Losh2023-05-1213-13/+13
| | | | | | | | | The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause. Discussed with: pfg MFC After: 3 days Sponsored by: Netflix
* ath: Fix mismatches in array bounds.John Baldwin2022-12-071-1/+1
| | | | | | Reported by: GCC -Warray-parameter Reviewed by: imp, emaste Differential Revision: https://reviews.freebsd.org/D37542
* ath(4): Fix two typos in source code commentsGordon Bergling2022-09-031-2/+2
| | | | | | - s/overriden/overridden/ MFC after: 3 days
* ath(4): Remove a double word in a few source code commentsGordon Bergling2022-04-092-2/+2
| | | | | | - s/for for/for/ MFC after: 3 days
* ath: Fix a typo in a source code commentGordon Bergling2022-03-271-1/+1
| | | | | | - s/ony/only/ MFC after: 3 days
* [ath_hal] Add get/set NAV functionsAdrian Chadd2021-04-1910-0/+87
| | | | | | | | | | | | | | | | | | | | | The NAV (network allocation vector) register reflects the current MAC tracking of NAV - when it will stay quiet before transmitting. Other devices transmit their frame durations in their 802.11 PHY headers and all devices that hear a frame - even if it's one in an encoding they don't understand - will understand the low bitrate PHY header that includes the frame duration. So, they'll set NAV to this value so they'll stay quiet until the transmit completes. Anyway, sometimes the PHY NAV header is garbled and sometimes, notably older broadcom devices, will fake a long NAV so they can get "cleaner" air for local calibration. When this happens, the hardware will stay quiet for quite some time and this can lead to missed/stuck beacons, or (for Very Large Values) a MAC hang. This code just adds the ability to get/set the NAV; the driver will need to take care of using it during transmit hangs and beacon misses to see if it's due to a trash looking NAV.
* ath: clean up empty lines in .c and .h filesMateusz Guzik2020-09-0167-131/+63
| | | | Notes: svn path=/head/; revision=365116
* [ath_hal] Add KeyMiss for AR5212/AR5416 series chips.Adrian Chadd2020-06-272-3/+5
| | | | | | | | | | | | | | This is a flag from the MAC that says the received packet didn't match a keycache slot. This isn't technically a problem as WEP keys don't match keycache slots (they're "global" keys), but it could be useful for tracking down CCMP decryption failures. Right now it's a no-op - it mirrors what the AR9300 HAL does and it just increments a counter. But, hey, maybe one day I'll use it for diagnosing keycache/CCMP decrypt issues. Notes: svn path=/head/; revision=362671
* [ath] [ath_hal] Propagate the HAL_RESET_TYPE through to the chip reset; set ↵Adrian Chadd2020-05-258-9/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] [ath_rate] Extend ath_rate_sample to better handle 11n rates and ↵Adrian Chadd2020-05-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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_hal] [ath_hal_ar9300] Fix endian macros to work in and out of kernel tree.Adrian Chadd2020-05-121-0/+12
| | | | | | | | | | | | | | | | | | | | | | Yes, people shouldn't use bitfields in C for structure parsing. If someone ever wants a cleanup task then it'd be great to remove them from this vendor code and other places in the ar9285/ar9287 HALs. Alas, here we are. AH_BYTE_ORDER wasn't defined and neither were the two values it could be. So when compiling ath_ee_print_9300 it'd default to the big endian struct layout and get a WHOLE lot of stuff wrong. So: * move AH_BYTE_ORDER into ath_hal/ah.h where it can be used by everyone. * ensure that AH_BYTE_ORDER is actually defined before using it! This should work on both big and little endian platforms. Notes: svn path=/head/; revision=360953
* ath_hal: fix typo in ath_hal_printfRebecca Cran2020-03-181-1/+1
| | | | Notes: svn path=/head/; revision=359063
* [ath_hal] Fix queue bits a bitAdrian Chadd2019-05-281-1/+1
| | | | | | | | | | Found by PVS Studio: duplicate assignment; add assignment of tqi_compBuf. Submitted by: <mizhka@gmail.com> Differential Revision: https://reviews.freebsd.org/D20431 Notes: svn path=/head/; revision=348331
* [ath] [ath_hal] [ath_hal_9300] Extend the start PCU receive to handle ↵Adrian Chadd2019-04-219-13/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | resetting ANI. One of the fun issues with scanning has been how the existing ANI values were programmed into the hardware when channels were changed. If you're on a really crappy channel and ANI has made you deaf then when you scan you continue to be deaf on all channels. This code passes in a flag to startpcureceive which in AR5416 and later is also used to enable ANI. This allows it to know if it's a normal operation or a scan operation. This fixes my situation at home where a temporary spot of a device going deaf due to interference starts scanning and .. can't hear anything until I restart. Now, this isn't the full fix - ideally: (a) all the ANI config and per-channel information would be migrated to the shared HAL stuff and enabled for all of the NICs; (b) when a station reassociates and some other error conditions (like missed beacons, NF calibration failures, etc) a knob to reset ANI parameters would likely help recovery. But hey, I'm committing bits of code again! woo! Tested: * AR9344 (2G), STA operation Notes: svn path=/head/; revision=346470
* [ath_hal] [ath_hal_ar9300] ANI fixes and preparation for userland control.Adrian Chadd2019-03-061-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | * The ani function bitmap was being badly used when determining if a command could be used. In hostap modes only a couple of the ANI control parameters are enabled. * The ani function bitmap was not being reset to HAL_ANI_ALL if transitioning from AP -> STA. * Change mrcCckOff to mrcCck - 1 == on, rather than 1 == off. This matches the API used to set the value from userland via the diagnostic API. * Handle OFDM/CCK noise immunity level commands in ar9300_ani_control(). These will only come from userland and it will go and program the rest of the ANI control parameters with the values in the ANI table. * Ensure all of the ANI parameters can be tweaked at runtime, even if they're disabled. Tested: * carambola2 (AR9331), STA/AP modes Notes: svn path=/head/; revision=344841
* [ath_hal] add extra ANI fields for the AR9300 HAL.Adrian Chadd2019-03-041-1/+3
| | | | | | | | | | | | I'm trying to debug why reception upstairs here is so terrible and it turns out ANI is buggy. (Which is no surprise, ANI is always buggy.) Tested: * Carambola2 (AR9331), STA/AP modes Notes: svn path=/head/; revision=344749
* [ath_hal] Return failure if noise floor calibration fails.Adrian Chadd2018-06-081-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | If we fail noise floor calibration then we may end up with a deaf NIC which we can't recover without a full chip reset. Earlier chips seem to get less stuck in this condition versus AR9280/later and AR9300/later, but whilst here just fix up the AR5212 era chips to also return NF calibration failures. This HAL routine would only return failure if the channel was not configured. This is a no-op until the driver side code for doing resets and the HAL code for being told about the reset type (and then handling it!) is implemented. Tested: * AR9280, STA mode * AR2425, STA mode * AR9380, STA mode Notes: svn path=/head/; revision=334849
* [ath_hal] Don't do ANI processing if we've reset.Adrian Chadd2018-06-082-0/+6
| | | | | | | | | | | | If we've reset then we can't trust the current state of the ANI tracking, so just wait until next time. Tested: * AR5424, STA mode (2GHz) Notes: svn path=/head/; revision=334848
* [ath_hal] migrate the shared HAL_RESET_* pieces out into ath_hal.Adrian Chadd2018-05-252-6/+6
| | | | | | | | | I'm in the process of reworking how the reset path works with an eye to better recovery when the chips hang and/or go RF/PHY deaf. This is the first step in a lot of unification and API changes. Notes: svn path=/head/; revision=334197
* SPDX: license IDs for some ISC-related files.Pedro F. Giffuni2017-12-08145-145/+435
| | | | Notes: svn path=/head/; revision=326695
* sys/dev: further adoption of SPDX licensing ID tags.Pedro F. Giffuni2017-11-2714-15/+43
| | | | | | | | | | | | | | | 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
* Increase timeout in Atheros HALWojciech Macek2017-05-291-1/+1
| | | | | | | | | | | | | | | It turned out, that some models of the Atheros PCIe adapters (e.g. AR983x family) may fail to attach due to insufficient timeout value. Submitted by: Bartosz Szczepanek <bsz@semihalf.com> Obtained from: Semihalf Sponsored by: Stormshield Reviewed by: adrian Differential revision: https://reviews.freebsd.org/D10903 Notes: svn path=/head/; revision=319116
* [ath] [ath_hal] retire AH_SUPPORT_AR5416 changing anything.Adrian Chadd2017-05-253-34/+0
| | | | | | | | Yes, the memory bloat is large, but it's 2017 and I'll fix it later by making it runtime configurable / per-chip configurable if I ever need to. Notes: svn path=/head/; revision=318857
* [ath] [ath_hal] (etc, etc) - begin the task of re-modularising the HAL.Adrian Chadd2017-05-252-4/+100
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Renumber copyright clause 4Warner Losh2017-02-281-1/+1
| | | | | | | | | | | | Renumber cluase 4 to 3, per what everybody else did when BSD granted them permission to remove clause 3. My insistance on keeping the same numbering for legal reasons is too pedantic, so give up on that point. Submitted by: Jan Schaumann <jschauma@stevens.edu> Pull Request: https://github.com/freebsd/freebsd/pull/96 Notes: svn path=/head/; revision=314436
* [ath_hal] implement NULL methods for ah_setQuiet for AR5210, AR5211.Adrian Chadd2017-02-096-0/+20
| | | | | | | | | | Tested: * "crap, I didn't bring my cardbus collection and T400 with me" compile tested. Notes: svn path=/head/; revision=313491
* [ath_hal] prepare for CAC quiet time.Adrian Chadd2017-02-032-0/+21
| | | | | | | | | | To support DFS, the NIC needs to be very quiet during this time. No transmissions including ACKs are allowed. This is just the initial HAL glue. Notes: svn path=/head/; revision=313135
* [ath_hal] add debugging level for spectral scan.Adrian Chadd2017-02-021-0/+1
| | | | Notes: svn path=/head/; revision=313086
* [ath_hal] note that the CCA configuration setting may be chip-dependent.Adrian Chadd2017-01-241-0/+3
| | | | | | | | I bet it isn't, but who knows - this is making assumptions about the layout of AR_DIAG. Notes: svn path=/head/; revision=312726
* [ath_hal] mad, mad hacks to get some semblence of correct HT/40 channels ↵Adrian Chadd2017-01-051-3/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | populated. The HT40 channel population logic was "just" doing pairs of channels starting with the band entry frequency. Trouble is, a lot of the rules start way off at 5120MHz, which isn't a valid 5GHz channel. Then, eg for HT40U, it would populate: * (5120,5140) * (5160,5180) * (5200,5220) * (5240,5260) .. as the HT40U pairs, with the first being the primary channel. Channel 36 is 5180MHz, and since it's not a primary channel here, it wouldn't populate it. Then, the next HT40U would be 5200/5220, which is highly wrong. HT40D had the same problem. So, this just forces that 5GHz HT40 channels start at channel 36 (5180), no matter what the band edge says. This includes eg doing 4.9GHz channels. This erm, meant that the HT40 channels for the low band was always wrong. Oops! Tested: * AR9380, STA mode * AR9344 SoC, AP mode MFC after: 1 week Notes: svn path=/head/; revision=311361
* [ath_hal] add a new regdomain flag - I think this means "yes, you can use thisAdrian Chadd2016-09-261-1/+2
| | | | | | | | | NIC in channel 144 if you're in FCC6." I have to go figure out more details about this before I enable it.. Notes: svn path=/head/; revision=306331
* [ath_hal] add a comment for the channel 144 regdomain flag.Adrian Chadd2016-09-251-0/+8
| | | | | | | I'm .. still trying to figure out what's going on. Notes: svn path=/head/; revision=306324
* [ath_hal] Add FCC6_FCCA regulatory domain (0x0014).Adrian Chadd2016-09-254-10/+35
| | | | | | | | | Tested: * TP-Link N900, AR9380, regdomain 0x0014 (FCC6_FCCA). Notes: svn path=/head/; revision=306323
* [ath_hal] fixes for finer grain timestamping, some 11n macrosAdrian Chadd2016-09-094-16/+37
| | | | | | | | | | | | | | | | * change the HT_RC_2_MCS to do MCS0..23 * Use it when looking up the ht20/ht40 array for bits-per-symbol * add a clk_to_psec (picoseconds) routine, so we can get sub-microsecond accuracy for the math * .. and make that + clk_to_usec public, so higher layer code that is returning clocks (eg the ANI diag routines, some upcoming locationing experiments) can be converted to microseconds. Whilst here, add a comment in ar5416 so i or someone else can revisit the latency values. Notes: svn path=/head/; revision=305637
* sys/dev: replace comma with semicolon when pertinent.Pedro F. Giffuni2016-08-092-4/+4
| | | | | | | | | | | | | Uses of commas instead of a semicolons can easily go undetected. The comma can serve as a statement separator but this shouldn't be abused when statements are meant to be standalone. Detected with devel/coccinelle following a hint from DragonFlyBSD. MFC after: 1 month Notes: svn path=/head/; revision=303891
* [ath] [ath_hal] break out the duration calculation to optionally include SIFS.Adrian Chadd2016-07-153-20/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pre-11n calculations include SIFS, but the 11n ones don't. The reason is that (mostly) the 11n hardware is doing the SIFS calculation for us but the pre-11n hardware isn't. This means that we're over-shooting the times in the duration field for non-11n frames on 11n hardware, which is OK, if not a little inefficient. Now, this is all fine for what the hardware needs for doing duration math for ACK, RTS/CTS, frame length, etc, but it isn't useful for doing PHY duration calculations. Ie, given a frame to TX and its timestamp, what would the end of the actual transmission time be; and similar for an RX timestamp and figuring out its original length. So, this adds a new field to the duration routines which requests SIFS or no SIFS to be included. All the callers currently will call it requesting SIFS, so this /should/ be a glorious no-op. I'm however planning some future work around airtime fairness and positioning which requires these routines to have SIFS be optional. Notably though, the 11n version doesn't do any SIFS addition at the moment. I'll go and tweak and verify all of the packet durations before I go and flip that part on. Tested: * AR9330, STA mode * AR9330, AP mode * AR9380, STA mode Notes: svn path=/head/; revision=302877
* [ath_hal] add capability bit for querying/controlling the ToA/ToD ↵Adrian Chadd2016-07-081-0/+1
| | | | | | | positioning code. Notes: svn path=/head/; revision=302463
* [ath_hal] retire a "long RX desc" flag, store/use the TX/RX timestamp length.Adrian Chadd2016-07-087-12/+15
| | | | | | | | | * 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_hal] extend the TX/RX descriptor layout to include location/beamforming ↵Adrian Chadd2016-07-081-1/+12
| | | | | | | | | | | | | fields. * extend the TX timestamp to 32 bits, as the AR5416 and later does a full 32 bit TX timestamp instead of 15 or 16 bits. * add RX descriptor fields for PHY uploaded information (coming soon) * add flags for RX/TX fast timestamp, hardware upload, etc * add a flag for TX to request ToD/ToA location information. Notes: svn path=/head/; revision=302446
* [ath_hal] add placeholders for AUDIO stomp for Kite/Kiwi.Adrian Chadd2016-06-041-0/+4
| | | | | | | It just stomps all; which is enough for some testing. Notes: svn path=/head/; revision=301304
* [ath_hal] add BTCOEX_STOMP_AUDIO; delete unused methods.Adrian Chadd2016-06-041-2/+1
| | | | Notes: svn path=/head/; revision=301303
* [ath_hal] add extra MCI definitions used by the later chips (QCA9565/Aphrodite).Adrian Chadd2016-06-011-0/+21
| | | | | | | Obtained from: Linux ath9k Notes: svn path=/head/; revision=301089
* [ath_hal] rename the MCI state info routine.Adrian Chadd2016-05-311-1/+1
| | | | | | | It's not /really/ "get state". Notes: svn path=/head/; revision=301043
generated by cgit v1.2.3 (git 2.25.1) at 2026-01-24 17:46:56 +0000