ath_hal: Fix a couple of type mismatches in function prototypesReported by: GCC 13 via -Wenum-int-mismatchReviewed by: imp, emasteDifferential Revision: https://reviews.freebsd.org/D42584(cherr
ath_hal: Fix a couple of type mismatches in function prototypesReported by: GCC 13 via -Wenum-int-mismatchReviewed by: imp, emasteDifferential Revision: https://reviews.freebsd.org/D42584(cherry picked from commit 1e65df68403acac2231dda161fd12e62f888a031)
show more ...
sys: Remove $FreeBSD$: two-line .h patternRemove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
[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.
ath: clean up empty lines in .c and .h files
[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
SPDX: license IDs for some ISC-related files.
[ath_hal] implement NULL methods for ah_setQuiet for AR5210, AR5211.Tested:* "crap, I didn't bring my cardbus collection and T400 with me" compile tested.
[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.
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.
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
Fix the AR5210 HAL code to store the association ID and restore itupon reset.Tested:* AR5210, STA mode
Fix ah_powerMode to be set at the correct place for the AR5210.Tested:* AR5210, 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
Begin adding support to explicitly set the current chainmask.Right now the only way to set the chainmask is to set the hardwareconfigured chainmask through capabilities. This is fine for forcing
Begin adding support to explicitly set the current chainmask.Right now the only way to set the chainmask is to set the hardwareconfigured chainmask through capabilities. This is fine for forcingthe chainmask to be something other than what the hardware is capableof (eg to reduce TX/RX to one connected antenna) but it does change whatthe HAL hardware chainmask configuration is.For operational mode changes, it (may?) make sense to separately controlthe 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 doingthis in the HAL is suboptimal - the driver needs to know the currentlyconfigured chainmask in order to correctly enable things for eachTX descriptor. This is currently done by overriding the chainmaskconfig in the ar5416 TX routines but this has to disappear - the AR9300HAL support requires the driver to dynamically set the TX chainmask basedon the TX power and TX rate in order to meet mini-PCIe slot powerrequirements.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 movingit into the driver; as well as properly programming the TX chainmaskbased 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.
Disable WEP hardware encryption on the AR5210, in order to allow otherencryption types.The AR5210 only has four WEP key slots, in contrast to what thelater MACs have (ie, the keycache.) So there
Disable WEP hardware encryption on the AR5210, in order to allow otherencryption types.The AR5210 only has four WEP key slots, in contrast to what thelater MACs have (ie, the keycache.) So there's no way to store a "clear"key.Even if the driver is taught to not allocate CLR key entries forthe AR5210, the hardware will actually attempt to decode the encryptedframes with the (likely all 0!) WEP keys.So for now, disable the hardware encryption entirely and just so itall in software. That allows both WEP -and- WPA to actually work.If someone wishes to try and make hardware WEP _but_ software WPA work,they'll have to create a HAL capability to enable/disable hardwareencryption based on the current STA/Hostap mode. However, makingmulti-vap work with one WEP and one WPA VAP will require hardwareencryption to be disabled anyway.
Correctly populate the RTS field.Tested: * AR5210, STA mode, RTS enabled
* Remove ah_desc.h, it's not needed* Add some shifts that I'm using in userspace (athalq.)However, this exposes a fun little bug..
Add default values for the NumTxMaps capability.
Migrate the ath_hal_filltxdesc() API to take a list of buffer/seglen values.The existing API only exposes 'seglen' (the current buffer (segment) length)with the data buffer pointer set in 'ds_data
Migrate the ath_hal_filltxdesc() API to take a list of buffer/seglen values.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 legacyDMA 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
Flesh out the multi-rate retry capability.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 capabilityexplicitly lis
Flesh out the multi-rate retry capability.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 capabilityexplicitly lists what number of multi-rate attempts are possible."1" means "one rate attempt supported".
Break out the TX descriptor link field into HAL methods.The DMA FIFO chips (AR93xx and later) differ slightly to th elegacychips:* The RX DMA descriptors don't have a ds_link field;* The TX DMA
Break out the TX descriptor link field into HAL methods.The DMA FIFO chips (AR93xx and later) differ slightly to th elegacychips:* 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 ath9kdoes.A subsequent commit will enable it in the TX and beacon paths.Obtained from: Linux ath9k, Qualcomm Atheros
Extend the RX HAL API to include the RX queue identifier.The AR93xx and later chips support two RX FIFO queues - a high and lowpriority queue.For legacy chips, just assume the queues are high pr
Extend the RX HAL API to include the RX queue identifier.The AR93xx and later chips support two RX FIFO queues - a high and lowpriority queue.For legacy chips, just assume the queues are high priority.This is inspired by the reference driver but is a reimplementation ofthe API and code.
oops - ath_hal_disablepcie is actually destined for another purpose,not to disable the PCIe PHY in prepration for reset.Extend the enablepci method to have a "poweroff" flag, which if equalto tru
oops - ath_hal_disablepcie is actually destined for another purpose,not to disable the PCIe PHY in prepration for reset.Extend the enablepci method to have a "poweroff" flag, which if equalto true means the hardware is about to go to sleep.
Add some empty DFS methods for AR5210/AR5211 for now, if DFS is enabledbut these don't exist, the code panics.I should really just add or use a DFS HAL capability before doing this,so the methods
Add some empty DFS methods for AR5210/AR5211 for now, if DFS is enabledbut these don't exist, the code panics.I should really just add or use a DFS HAL capability before doing this,so the methods wouldn't be needed..
123