sys: Remove $FreeBSD$: two-line .h patternRemove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
ath: Fix mismatches in array bounds.Reported by: GCC -Warray-parameterReviewed by: imp, emasteDifferential Revision: https://reviews.freebsd.org/D37542
ath(4): Remove a double word in a few source code comments- s/for for/for/MFC after: 3 days
[ath_hal] Add get/set NAV functionsThe NAV (network allocation vector) register reflects the current MACtracking of NAV - when it will stay quiet before transmitting.Other devices transmit their
[ath_hal] Add get/set NAV functionsThe NAV (network allocation vector) register reflects the current MACtracking of NAV - when it will stay quiet before transmitting.Other devices transmit their frame durations in their 802.11 PHY headersand all devices that hear a frame - even if it's one in an encodingthey don't understand - will understand the low bitrate PHY header thatincludes the frame duration. So, they'll set NAV to this value sothey'll stay quiet until the transmit completes.Anyway, sometimes the PHY NAV header is garbled and sometimes, notablyolder broadcom devices, will fake a long NAV so they can get "cleaner" airfor local calibration. When this happens, the hardware will stay quietfor 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 willneed to take care of using it during transmit hangs and beacon missesto see if it's due to a trash looking NAV.
show more ...
ath: clean up empty lines in .c and .h files
[ath_hal] Add KeyMiss for AR5212/AR5416 series chips.This is a flag from the MAC that says the received packet didn't matcha keycache slot. This isn't technically a problem as WEP keys don'tmatc
[ath_hal] Add KeyMiss for AR5212/AR5416 series chips.This is a flag from the MAC that says the received packet didn't matcha keycache slot. This isn't technically a problem as WEP keys don'tmatch keycache slots (they're "global" keys), but it could be usefulfor tracking down CCMP decryption failures.Right now it's a no-op - it mirrors what the AR9300 HAL does and itjust increments a counter. But, hey, maybe one day I'll use it fordiagnosing keycache/CCMP decrypt issues.
[ath] [ath_hal] [ath_hal_9300] Extend the start PCU receive to handle resetting ANI.One of the fun issues with scanning has been how the existingANI values were programmed into the hardware when c
[ath] [ath_hal] [ath_hal_9300] Extend the start PCU receive to handle resetting ANI.One of the fun issues with scanning has been how the existingANI values were programmed into the hardware when channels werechanged. If you're on a really crappy channel and ANI has madeyou 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 lateris also used to enable ANI. This allows it to know if it's a normaloperation or a scan operation.This fixes my situation at home where a temporary spot of a devicegoing deaf due to interference starts scanning and .. can't hearanything 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
[ath_hal] Don't do ANI processing if we've reset.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)
SPDX: license IDs for some ISC-related files.
sys/dev: replace comma with semicolon when pertinent.Uses of commas instead of a semicolons can easily go undetected. The commacan serve as a statement separator but this shouldn't be abused when
sys/dev: replace comma with semicolon when pertinent.Uses of commas instead of a semicolons can easily go undetected. The commacan serve as a statement separator but this shouldn't be abused whenstatements are meant to be standalone.Detected with devel/coccinelle following a hint from DragonFlyBSD.MFC after: 1 month
[ath] [ath_hal] break out the duration calculation to optionally include SIFS.The pre-11n calculations include SIFS, but the 11n ones don't.The reason is that (mostly) the 11n hardware is doing t
[ath] [ath_hal] break out the duration calculation to optionally include SIFS.The pre-11n calculations include SIFS, but the 11n ones don't.The reason is that (mostly) the 11n hardware is doing the SIFS calculationfor us but the pre-11n hardware isn't. This means that we're over-shootingthe times in the duration field for non-11n frames on 11n hardware, whichis OK, if not a little inefficient.Now, this is all fine for what the hardware needs for doing duration mathfor ACK, RTS/CTS, frame length, etc, but it isn't useful for doing PHYduration calculations. Ie, given a frame to TX and its timestamp, whatwould the end of the actual transmission time be; and similar for anRX timestamp and figuring out its original length.So, this adds a new field to the duration routines which requestsSIFS or no SIFS to be included. All the callers currently will callit requesting SIFS, so this /should/ be a glorious no-op. I'm howeverplanning some future work around airtime fairness and positioning whichrequires 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 andflip that part on.Tested:* AR9330, STA mode* AR9330, AP mode* AR9380, STA mode
[ath_hal] retire a "long RX desc" flag, store/use the TX/RX timestamp length.* the code already stored the length of the RX desc, which I never used. So, use that and retire the new flag I introd
[ath_hal] retire a "long RX desc" flag, store/use the TX/RX timestamp length.* the code already stored the length of the RX desc, which I never used. So, use that and retire the new flag I introduced a while ago.* Introduce a TX timestamp length field and capability.
dev/ath: minor spelling fixes in comments.No functional change.Reviewed by: adrian
Fix kernel build, broken in r290612Approved by: adrian
ath(4): begin fleshing out a "reset type" extension to force cold/warn resets.Right now the only way to force a cold reset is:* The HAL itself detects it's needed, or* The sysctl, setting all re
ath(4): begin fleshing out a "reset type" extension to force cold/warn resets.Right now the only way to force a cold reset is:* The HAL itself detects it's needed, or* The sysctl, setting all resets to be cold.Trouble is, cold resets take quite a bit longer than warm resets.However, there are situations where a cold reset would be nice.Specifically, after a stuck beacon, BB/MAC hang, stuck calibration results,etc.The vendor HAL has a separate method to set the reset reason (which ishow HAL_RESET_BBPANIC gets set) which informs the HAL during the reset pathwhy it occured. This is almost but not quite the same; I may eventuallyunify 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'llcome later.It also is a big no-op in each HAL - I need to go teach each of the HALsabout cold/warm reset through this path.
Return the correct HAL data type for HAL_DIAG_ANI_STATS.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 wer
Return the correct HAL data type for HAL_DIAG_ANI_STATS.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 wereenough 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.
Use the HAL API for returning ar5212AniState, rather than just dumpingAniState itself.
Start the process of migrating the ANI statistics out of the HALs and intothe top-level HAL.The athstats program is blindly using a copy of the ar5212 ANI stats structureto pull out ANI statistic
Start the process of migrating the ANI statistics out of the HALs and intothe top-level HAL.The athstats program is blindly using a copy of the ar5212 ANI stats structureto pull out ANI statistics/state and this is problematic for the AR9300HAL.So:* Define HAL_ANI_STATS and HAL_ANI_STATE* Use HAL_ANI_STATS inside the AR5212 HALThis commit doesn't (yet) convert the ar5212AniState -> HAL_ANI_STATE whenexporting it to userland; that'll come in the next commit.
Move the HAL channel survey support out to be in the top-level HAL,rathe than private in each HAL module.Whilst here, modify ath_hal_private to always have the per-channelnoisefloor stats, rather
Move the HAL channel survey support out to be in the top-level HAL,rathe than private in each HAL module.Whilst here, modify ath_hal_private to always have the per-channelnoisefloor stats, rather than conditionally. This just makeslife easier in general (no strange ABI differences between differentHAL compile options.)Add a couple of methods (clear/reset, add) rather than usinghand-rolled versions of things.
Fix the following -Werror warning from clang 3.5.0, while building theath kernel module:sys/dev/ath/ath_hal/ar5212/ar5212_reset.c:2642:7: error: taking the absolute value of unsigned type 'unsigne
Fix the following -Werror warning from clang 3.5.0, while building theath 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 negativesys/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 thesubtraction expression is also unsigned, and calling abs() is a no-op.However, the intention was to look at the absolute difference betweenthe two unsigned quantities. Introduce a small static function toclarify what we're doing, and call that instead.Reviewed by: adrianMFC after: 3 daysDifferential Revision: https://reviews.freebsd.org/D1212
Add initial support for the AR9485 CUS198 / CUS230 variants.These variants have a few differences from the default AR9485 NIC,namely:* a non-default antenna switch config;* slightly different R
Add initial support for the AR9485 CUS198 / CUS230 variants.These variants have a few differences from the default AR9485 NIC,namely:* a non-default antenna switch config;* slightly different RX gain table setup;* an external XLNA hooked up to a GPIO pin;* (and not yet done) RSSI threshold differences when doing slow diversity.To make this possible:* Add the PCI device list from Linux ath9k, complete with vendor and sub-vendor IDs for various things to be enabled;* .. and until FreeBSD learns about a PCI device list like this, write a search function inspired by the USB device enumeration code;* add HAL_OPS_CONFIG to the HAL attach methods; the HAL can use this to initialise its local driver parameters upon attach;* copy these parameters over in the AR9300 HAL;* don't default to override the antenna switch - only do it for the chips that require it;* I brought over ar9300_attenuation_apply() from ath9k which is cleaner and easier to read for this particular NIC.This is a work in progress. I'm worried that there's some post-AR9380NIC out there which doesn't work without the antenna override set asI currently haven't implemented bluetooth coexistence for the AR9380and later HAL. But I'd rather have this code in the tree and fix itup before 11.0-RELEASE happens versus having a set of newer NICsin laptops be effectively RX deaf.Tested:* AR9380 (STA)* AR9485 CUS198 (STA)Obtained from: Qualcomm Atheros, Linux ath9k
* Only update ah_powerMode if we're setting the chip sleep state. Some code will appear soon that is actually setting the chip powerstate separate from the self-generated frames power state.* Al
* Only update ah_powerMode if we're setting the chip sleep state. 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
Also set the AR5212 HAL power mode tracking in the right spot.Tested:* D-Link DWL-G650 NIC (AR2413), STA mode
Migrate the chip power mode status to public ath_hal, rather than theprivate per-chip HAL.This allows the ah_osdep.[ch] code to check whether the power state isvalid for doing chip programming.
Migrate the chip power mode status to public ath_hal, rather than theprivate per-chip HAL.This allows the ah_osdep.[ch] code to check whether the power state isvalid for doing chip programming.It should be a no-op for normal driver work but it does require aclean 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 trafficis received. This doesn't actually set the power mode to AWAKE, sowe have to be careful about how we touch things.But it's enough to start down the path of implementing station modechipset power savings, as a large part of the silliness is makingsure the chip is awake during periodic calibration / ANI andrandom places where transmit may be occuring. I'd rather not a repeatof debugging power save on ath9k, where races with calibrationand transmit path stuff took a couple years to shake out.Tested:* AR5416, STA mode
Add channel survey support to the AR5212 HAL.The AR5212 series of MACs implement the same channel counters as thelater 11n chips - except, of course, the 11n specific counter (extensionchannel bu
Add channel survey support to the AR5212 HAL.The AR5212 series of MACs implement the same channel counters as thelater 11n chips - except, of course, the 11n specific counter (extensionchannel busy.)This allows users of these NICs to use 'athsurvey' to see how busy theircurrent channel is.Tested:* AR5212, AR2413 NICs, STA modeApproved by: re@ (gleb)
12345