aboutsummaryrefslogtreecommitdiff
path: root/sys/dev/ath/ath_hal/ar5212
Commit message (Collapse)AuthorAgeFilesLines
* ath(4): Fix a typo in a source code commentGordon Bergling2025-04-281-1/+1
| | | | | | - s/chang/change/ MFC after: 3 days
* sys: Remove $FreeBSD$: two-line .h patternWarner Losh2023-08-1627-54/+0
| | | | Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
* 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): Remove a double word in a few source code commentsGordon Bergling2022-04-091-1/+1
| | | | | | - s/for for/for/ MFC after: 3 days
* [ath_hal] Add get/set NAV functionsAdrian Chadd2021-04-193-0/+31
| | | | | | | | | | | | | | | | | | | | | 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-0115-29/+18
| | | | Notes: svn path=/head/; revision=365116
* [ath_hal] Add KeyMiss for AR5212/AR5416 series chips.Adrian Chadd2020-06-271-1/+2
| | | | | | | | | | | | | | 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] [ath_hal_9300] Extend the start PCU receive to handle ↵Adrian Chadd2019-04-212-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Don't do ANI processing if we've reset.Adrian Chadd2018-06-081-0/+3
| | | | | | | | | | | | 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
* SPDX: license IDs for some ISC-related files.Pedro F. Giffuni2017-12-0826-26/+78
| | | | Notes: svn path=/head/; revision=326695
* sys/dev: replace comma with semicolon when pertinent.Pedro F. Giffuni2016-08-091-2/+2
| | | | | | | | | | | | | 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-151-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] retire a "long RX desc" flag, store/use the TX/RX timestamp length.Adrian Chadd2016-07-081-1/+2
| | | | | | | | | * 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
* dev/ath: minor spelling fixes in comments.Pedro F. Giffuni2016-05-028-13/+13
| | | | | | | | | No functional change. Reviewed by: adrian Notes: svn path=/head/; revision=298939
* Fix kernel build, broken in r290612Renato Botelho2015-11-091-1/+1
| | | | | | | Approved by: adrian Notes: svn path=/head/; revision=290616
* ath(4): begin fleshing out a "reset type" extension to force cold/warn resets.Adrian Chadd2015-11-092-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Return the correct HAL data type for HAL_DIAG_ANI_STATS.Adrian Chadd2015-04-062-20/+10
| | | | | | | | | | | | | | | | I .. stupidly added code to return HAL_ANI_STATS to HAL_DIAG_ANI_STATS. I discovered this in a noisy environment when the returned values were enough to .. well, make everything terrible. So - restore functionality. Tested: * AR5416 (uses the AR5212 HAL), in a /very/ noisy 2GHz environment. Enough to trigger ANI to get upset and generate useful data. Notes: svn path=/head/; revision=281128
* Use the HAL API for returning ar5212AniState, rather than just dumpingAdrian Chadd2015-04-012-3/+24
| | | | | | | AniState itself. Notes: svn path=/head/; revision=280942
* Start the process of migrating the ANI statistics out of the HALs and intoAdrian Chadd2015-04-013-4/+6
| | | | | | | | | | | | | | | | | | | the top-level HAL. The athstats program is blindly using a copy of the ar5212 ANI stats structure to pull out ANI statistics/state and this is problematic for the AR9300 HAL. So: * Define HAL_ANI_STATS and HAL_ANI_STATE * Use HAL_ANI_STATS inside the AR5212 HAL This commit doesn't (yet) convert the ar5212AniState -> HAL_ANI_STATE when exporting it to userland; that'll come in the next commit. Notes: svn path=/head/; revision=280940
* Move the HAL channel survey support out to be in the top-level HAL,Adrian Chadd2015-03-294-16/+3
| | | | | | | | | | | | | | | rathe than private in each HAL module. Whilst here, modify ath_hal_private to always have the per-channel noisefloor stats, rather than conditionally. This just makes life easier in general (no strange ABI differences between different HAL compile options.) Add a couple of methods (clear/reset, add) rather than using hand-rolled versions of things. Notes: svn path=/head/; revision=280828
* Fix the following -Werror warning from clang 3.5.0, while building theDimitry Andric2014-11-231-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ath kernel module: sys/dev/ath/ath_hal/ar5212/ar5212_reset.c:2642:7: error: taking the absolute value of unsigned type 'unsigned int' has no effect [-Werror,-Wabsolute-value] if (abs(lp[0] * EEP_SCALE - target) < EEP_DELTA) { ^ sys/dev/ath/ah_osdep.h:74:18: note: expanded from macro 'abs' #define abs(_a) __builtin_abs(_a) ^ sys/dev/ath/ath_hal/ar5212/ar5212_reset.c:2642:7: note: remove the call to '__builtin_abs' since unsigned values cannot be negative sys/dev/ath/ah_osdep.h:74:18: note: expanded from macro 'abs' #define abs(_a) __builtin_abs(_a) ^ 1 error generated. This warning occurs because both lp[0] and target are unsigned, so the subtraction expression is also unsigned, and calling abs() is a no-op. However, the intention was to look at the absolute difference between the two unsigned quantities. Introduce a small static function to clarify what we're doing, and call that instead. Reviewed by: adrian MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D1212 Notes: svn path=/head/; revision=274922
* Add initial support for the AR9485 CUS198 / CUS230 variants.Adrian Chadd2014-09-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=272292
* * Only update ah_powerMode if we're setting the chip sleep state.Adrian Chadd2014-04-301-3/+6
| | | | | | | | | | | | | | | | | | | Some code will appear soon that is actually setting the chip powerstate separate from the self-generated frames power state. * Allow the AR5416 family chips to actually have the power state changed from the self generated state change. Tested (STA mode): * AR5210 * AR5211 * AR5412 * AR5413 * AR5416 * AR9285 Notes: svn path=/head/; revision=265112
* Also set the AR5212 HAL power mode tracking in the right spot.Adrian Chadd2014-03-221-1/+3
| | | | | | | | | Tested: * D-Link DWL-G650 NIC (AR2413), STA mode Notes: svn path=/head/; revision=263618
* Migrate the chip power mode status to public ath_hal, rather than theAdrian Chadd2014-03-102-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | private per-chip HAL. This allows the ah_osdep.[ch] code to check whether the power state is valid for doing chip programming. It should be a no-op for normal driver work but it does require a clean kernel/module rebuild, as the size of HAL structures have changed. Now, this doesn't track whether the hardware is ACTUALLY awake, as NETWORK_SLEEP wakes the chip up for a short period when traffic is received. This doesn't actually set the power mode to AWAKE, so we have to be careful about how we touch things. But it's enough to start down the path of implementing station mode chipset power savings, as a large part of the silliness is making sure the chip is awake during periodic calibration / ANI and random places where transmit may be occuring. I'd rather not a repeat of debugging power save on ath9k, where races with calibration and transmit path stuff took a couple years to shake out. Tested: * AR5416, STA mode Notes: svn path=/head/; revision=262969
* Add channel survey support to the AR5212 HAL.Adrian Chadd2013-10-083-18/+102
| | | | | | | | | | | | | | | | | | The AR5212 series of MACs implement the same channel counters as the later 11n chips - except, of course, the 11n specific counter (extension channel busy.) This allows users of these NICs to use 'athsurvey' to see how busy their current channel is. Tested: * AR5212, AR2413 NICs, STA mode Approved by: re@ (gleb) Notes: svn path=/head/; revision=256139
* Begin adding support to explicitly set the current chainmask.Adrian Chadd2013-02-253-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Right now the only way to set the chainmask is to set the hardware configured chainmask through capabilities. This is fine for forcing the chainmask to be something other than what the hardware is capable of (eg to reduce TX/RX to one connected antenna) but it does change what the HAL hardware chainmask configuration is. For operational mode changes, it (may?) make sense to separately control the TX/RX chainmask. Right now it's done as part of ar5416_reset.c - ar5416UpdateChainMasks() calculates which TX/RX chainmasks to enable based on the operating mode. (1 for legacy and whatever is supported for 11n operation.) But doing this in the HAL is suboptimal - the driver needs to know the currently configured chainmask in order to correctly enable things for each TX descriptor. This is currently done by overriding the chainmask config in the ar5416 TX routines but this has to disappear - the AR9300 HAL support requires the driver to dynamically set the TX chainmask based on the TX power and TX rate in order to meet mini-PCIe slot power requirements. So: * Introduce a new HAL method to set the operational chainmask variables; * Introduce null methods for the previous generation chipsets; * Add new driver state to record the current chainmask separate from the hardware configured chainmask. Part #2 of this will involve disabling ar5416UpdateChainMasks() and moving it into the driver; as well as properly programming the TX chainmask based on the currently configured HAL chainmask. Tested: * AR5416, STA mode - both legacy (11a/11bg) and 11n rates - verified that AR_SELFGEN_MASK (the chainmask used for self-generated frames like ACKs and RTSes) is correct, as well as the TX descriptor contents is correct. Notes: svn path=/head/; revision=247286
* When programming the beacon timer configuration, be very explicit aboutAdrian Chadd2012-11-271-4/+13
| | | | | | | | | | | | | | | | | | | | | | | what the maximum legal values are. The current beacon timer configuration from TDMA wraps things at HAL_BEACON_PERIOD-1 TU. For the 11a chips this is fine, but for the 11n chips it's not enough resolution. Since the 11a chips have a limit on what's "valid", just enforce this so when I do write larger values in, they get suitably wrapped before programming. Tested: * AR5413, TDMA slave Todo: * Run it for a (lot) longer on a clear channel, ensure that no strange slippages occur. * Re-validate this on STA configurations, just to be sure. Notes: svn path=/head/; revision=243588
* Implement a HAL method to set a 64 bit TSF value.Adrian Chadd2012-11-231-0/+1
| | | | | | | TODO: implement it (and test) for the AR5210/AR5211. Notes: svn path=/head/; revision=243424
* .. include ah_desc.h here now.Adrian Chadd2012-11-172-0/+2
| | | | Notes: svn path=/head/; revision=243169
* Remove the ah_desc.h reference; it's not needed.Adrian Chadd2012-11-171-1/+0
| | | | | | | | I'm using these descriptor header files in userland and I'm trying to avoid populating a compatibility ah_desc.h file. Notes: svn path=/head/; revision=243168
* Remove duplicate const specifiers in many drivers (I hope I got all ofDimitry Andric2012-11-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | them, please let me know if not). Most of these are of the form: static const struct bzzt_type { [...list of members...] } const bzzt_devs[] = { [...list of initializers...] }; The second const is unnecessary, as arrays cannot be modified anyway, and if the elements are const, the whole thing is const automatically (e.g. it is placed in .rodata). I have verified this does not change the binary output of a full kernel build (except for build timestamps embedded in the object files). Reviewed by: yongari, marius MFC after: 1 week Notes: svn path=/head/; revision=242625
* HAL updates!Adrian Chadd2012-10-311-1/+23
| | | | | | | | | | | | | | | | * Add some more ANI spur immunity levels. * For AR5111 radios attached to an AR5212, limit the 5GHz channels that are available. A later revision of the AR5111 supports the 4.9GHz PSB channels but right now there's no check in place for the radio revision. If someone wants PSB support on AR5212+AR5111 radios then please let me know and I'll add the relevant version check. Obtained from: Qualcomm Atheros Notes: svn path=/head/; revision=242408
* AR5212 radar pulse fixes.Adrian Chadd2012-09-021-13/+12
| | | | | | | | | | | | | | | | | | | | | | | | | Fix the strong signal diversity capability setting - I had totally messed up the indentation. Set the default values to match what's in the .ini for now, rather than what values I had previously gleaned from places. This seems to work quite well for the early AR5212 NICs I have. Of course, later NICs have different PHYs and the radar configuration is very card/board dependent.. Tested: * ath1: AR5212 mac 5.3 RF5111 phy 4.1 ath1: 2GHz radio: 0x0023; 5GHz radio: 0x0017 This detects 1, 5, 25, 50, 75, 100uS pulses reliably (with no interference.) However, 10uS pulses don't detect reliably. That may be around the transition between short and long pulses so some further tuning may improve things. Notes: svn path=/head/; revision=240001
* Fix the PHY / CRC error bug in the AR5212 HAL, which apparently also popsAdrian Chadd2012-09-011-4/+14
| | | | | | | | | | | | | | | | | up on (at least) the AR5413. The 30 second summary - if a CRC error frame comes in during PHY error processing, that CRC bit will be set for all subsequent frames until a non-CRC error frame is processed. So to allow for accurate PHY error processing (Radar, and ANI on the AR5212 HAL chips) just tag the frame as being both CRC and PHY - let the driver decide what to do with it. PR: kern/169362 Notes: svn path=/head/; revision=239966
* Add AR5413 radar parameters and strong signal diversity capability.Adrian Chadd2012-08-292-21/+155
| | | | | | | | | | | | | | | This is a re-implementation based on the reference carrier code for the AR5413. Tested: * Pulse detection for AR5212 and AR5413, to ensure the correct behaviour for both chips PR: kern/170904 Obtained from: Qualcomm Atheros Notes: svn path=/head/; revision=239801
* Correctly handle the "pe_enabled" flag - both when configuring DFS andAdrian Chadd2012-08-241-1/+7
| | | | | | | | | fetching the current DFS configuration. PR: kern/170904 Notes: svn path=/head/; revision=239657
* Add default values for the NumTxMaps capability.Adrian Chadd2012-08-241-0/+1
| | | | Notes: svn path=/head/; revision=239643
* Add the method to fetch the default DFS parameters for the AR5212 PHY.Adrian Chadd2012-08-243-1/+33
| | | | | | | | | I need to check whether new parameters were added for the AR5413 NIC. PR: kern/170904 Notes: svn path=/head/; revision=239642
* Migrate the ath_hal_filltxdesc() API to take a list of buffer/seglen values.Adrian Chadd2012-08-052-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The existing API only exposes 'seglen' (the current buffer (segment) length) with the data buffer pointer set in 'ds_data'. This is fine for the legacy DMA engine but it won't work for the EDMA engines. The EDMA engine has a significantly different TX descriptor layout. * The legacy DMA engine had a ds_data pointer at the same offset in the descriptor for both TX and RX buffers; * The EDMA engine has no ds_data for RX - the data is DMAed after the descriptor; * The EDMA engine has support for 4 TX buffer/segment pairs in the TX DMA descriptor; * The EDMA TX completion is in a different FIFO, and the driver will 'link' the status completion entry to a QCU by a "QCU ID". I don't know why it's just not filled in by the hardware, alas. So given that, here are the changes: * Instead of directly fondling 'ds_data' in ath_desc, change the ath_hal_filltxdesc() to take an array of buffer pointers as well as segment len pointers; * The EDMA TX completion status wants a descriptor and queue id. This (for now) uses bf_state.bfs_txq and will extract the hardware QCU ID from that. * .. and this is ugly and wasteful; it should change to just store the QCU in the bf_state and save 3/7 bytes in the process. Now, the weird crap: * The aggregate TX path was using bf_state->bfs_txq for the TXQ, rather than taking a function argument. I've tidied that up. * The multicast queue frames get put on a software TXQ and then that is appended to the hardware CABQ when appropriate. So for now, make sure that bf_state->bfs_txq points at the CABQ when adding frames to the multicast queue. * .. but the multicast queue TX path for now doesn't use the software queue and instead (a) directly sets up the descriptor contents at that point; (b) the frames on the vap->avp_mcastq are then just appended wholesale to the CABQ. So for now, I don't have to worry about making the multicast path work with aggregation or the per-TID software queue. Phew. What's left to do: * I need to modify the 11n ath_hal_chaintxdesc() API to do the same. I'll do that in a subsequent commit. * Remove bf_state.bfs_txq entirely and store the QCU as appropriate. * .. then do the runtime "is this going on the right HWQ?" checks using that, rather than comparing pointer values. Tested on: * AR9280 STA/AP * AR5416 STA/AP Notes: svn path=/head/; revision=239051
* Flesh out the multi-rate retry capability.Adrian Chadd2012-07-281-0/+1
| | | | | | | | | | | The existing method for testing for MRR is to call the "SetupXTXDesc" HAL method and see if it returns AH_TRUE or AH_FALSE. This capability explicitly lists what number of multi-rate attempts are possible. "1" means "one rate attempt supported". Notes: svn path=/head/; revision=238858
* Break out the TX descriptor link field into HAL methods.Adrian Chadd2012-07-193-0/+33
| | | | | | | | | | | | | | | | | | | The DMA FIFO chips (AR93xx and later) differ slightly to th elegacy chips: * The RX DMA descriptors don't have a ds_link field; * The TX DMA descriptors have a ds_link field however at a different offset. This is a reimplementation based on what the reference driver and ath9k does. A subsequent commit will enable it in the TX and beacon paths. Obtained from: Linux ath9k, Qualcomm Atheros Notes: svn path=/head/; revision=238607
* Extend the RX HAL API to include the RX queue identifier.Adrian Chadd2012-07-092-4/+8
| | | | | | | | | | | | | The AR93xx and later chips support two RX FIFO queues - a high and low priority queue. For legacy chips, just assume the queues are high priority. This is inspired by the reference driver but is a reimplementation of the API and code. Notes: svn path=/head/; revision=238278
* oops - ath_hal_disablepcie is actually destined for another purpose,Adrian Chadd2012-05-251-3/+4
| | | | | | | | | | 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. Notes: svn path=/head/; revision=235972
* Change the MIB cycle count API to return HAL_BOOL, rather than uint32_t,Adrian Chadd2012-05-013-2/+15
| | | | | | | | | | to return whether it was successful. Add placeholder (blank) methods for previous chips, for both it and the 11n extension channel busy call. Notes: svn path=/head/; revision=234873
* After thinking about this a bit more, let's not keep statistics per-channelAdrian Chadd2012-04-283-5/+5
| | | | | | | | | | | | | | | | | | in the HAL. That's very memory hungry (32k just for channel statistics) which would be better served by keeping a summary in the ANI state. Or, later, keep a survey history in net80211. So: * Migrate the ah_chansurvey array to be a single entry, for the current channel. * Change the ioctl interface and ANI code to just reference that. * Clear the ah_chansurvey array during channel reset, both in the AR5212 and AR5416 reset path. Notes: svn path=/head/; revision=234774
* Fetch the channel survey code from the HAL.Adrian Chadd2012-04-282-0/+9
| | | | | | | | This information is currently not being populated by any of the HAL modules. Notes: svn path=/head/; revision=234750
* Stop using the hardware register value byte order swapping for now,Adrian Chadd2012-04-191-4/+3
| | | | | | | | | | | | | | | | | | at least until I can root cause what's going on. The only platform I've seen this on is the AR9220 when attached to the AR71xx CPUs. I get immediate PCIe bus errors and all subsequent accesses cause further MIPS bus exceptions. I don't have any other big-endian platforms to test this on. If I get a chance (or two), I'll try to whack this on a bus analyser and see exactly what happens. I'd rather leave this on, especially for slower, embedded platforms. But the #ifdef hell is something I'm trying to avoid. Notes: svn path=/head/; revision=234450
* Radar API related fixes.Adrian Chadd2012-01-303-0/+18
| | | | | | | | | | | | | | | * For legacy NICs, the combined RSSI should be used. For earlier AR5416 NICs, use control chain 0 RSSI rather than combined RSSI. For AR5416 > version 2.1, use the combined RSSI again. * Add in a missing AR5212 HAL method (get11nextbusy) which may be called by radar code. This serves no functional change for what's currently in FreeBSD. Notes: svn path=/head/; revision=230791
* Use the correct types when calling the decompression mask function.Adrian Chadd2011-12-221-1/+1
| | | | | | | | | | | | | | | There's currently no public code which uses this feature and the current reference driver doesn't enable this feature at all. It's possible it was used by a previous version of the driver and that indeed it should return HAL_STATUS; but at this point I'm happy to require that they complain and submit a patch. This was found by LLVM compile-time type checking. Submitted by: dim Notes: svn path=/head/; revision=228817
generated by cgit v1.2.3 (git 2.25.1) at 2026-01-16 20:48:16 +0000