aboutsummaryrefslogtreecommitdiff
path: root/sys/contrib/dev/ath
Commit message (Collapse)AuthorAgeFilesLines
* ath: return error code of HAL_STATUS typeGleb Smirnoff2026-08-071-1/+1
| | | | Found with: clang -Werror=assign-enum
* ath_hal_ar9300: implement the TX/RX chainmask override for AR9300 HALAdrian Chadd2024-12-312-2/+29
| | | | | | | | | | | | | | | | | | | This commit implements the missing capability set handlers for setting the transmit and receive chainmasks. I did this for the AR5416 and later chips years ago, but not for these. This is especially useful when you're only hooking up one or two antennas on a 3 antenna device - or you just want to test it like that. It also requires updating the number of supported transmit/receive streams, so also add them here. Locally Tested: * AR9300, STA mode, 1, 2 and 3 stream TX/RX configuration Differential Revision: https://reviews.freebsd.org/D48240
* ath_hal_ar9300: quick refactor of tx/rx chain handlingAdrian Chadd2024-12-311-4/+3
| | | | | | | Use a temporary variable, make the lines shorter. Differential Revision: https://reviews.freebsd.org/D48239 Reviewed by: emaste
* Fix enum warnings in ath_hal's ar9300Dimitry Andric2024-08-041-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a number of clang 19 warnings: sys/contrib/dev/ath/ath_hal/ar9300/ar9300_eeprom.c:709:25: error: comparison of different enumeration types ('HAL_BOOL' and 'HAL_FREQ_BAND') [-Werror,-Wenum-compare] 709 | freq_array[i] = FBIN2FREQ(p_freq_bin[i], is_2ghz); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ sys/contrib/dev/ath/ath_hal/ar9300/ar9300eep.h:148:11: note: expanded from macro 'FBIN2FREQ' 148 | (((y) == HAL_FREQ_BAND_2GHZ) ? (2300 + x) : (4800 + 5 * x)) | ~~~ ^ ~~~~~~~~~~~~~~~~~~ sys/contrib/dev/ath/ath_hal/ar9300/ar9300_eeprom.c:745:25: error: comparison of different enumeration types ('HAL_BOOL' and 'HAL_FREQ_BAND') [-Werror,-Wenum-compare] 745 | freq_array[i] = FBIN2FREQ(p_freq_bin[i], is_2ghz); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ sys/contrib/dev/ath/ath_hal/ar9300/ar9300eep.h:148:11: note: expanded from macro 'FBIN2FREQ' 148 | (((y) == HAL_FREQ_BAND_2GHZ) ? (2300 + x) : (4800 + 5 * x)) | ~~~ ^ ~~~~~~~~~~~~~~~~~~ sys/contrib/dev/ath/ath_hal/ar9300/ar9300_eeprom.c:781:25: error: comparison of different enumeration types ('HAL_BOOL' and 'HAL_FREQ_BAND') [-Werror,-Wenum-compare] 781 | freq_array[i] = FBIN2FREQ(p_freq_bin[i], is_2ghz); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ sys/contrib/dev/ath/ath_hal/ar9300/ar9300eep.h:148:11: note: expanded from macro 'FBIN2FREQ' 148 | (((y) == HAL_FREQ_BAND_2GHZ) ? (2300 + x) : (4800 + 5 * x)) | ~~~ ^ ~~~~~~~~~~~~~~~~~~ The `FBIN2FREQ()` and `FREQ2FBIN()` macros in `ar9300eep.h` are invoked in most places around the `ath_hal` code with a (effectively) boolean second argument, corresponding to "is this 2GHz?". But in the code that is warned about, the value `HAL_FREQ_BAND_2GHZ` is of a different non-boolean type, `HAL_FREQ_BAND`. Update the `FBIN2FREQ()` and `FREQ2FBIN()` macros to interpret the second argument as boolean value, and rename the macro parameter names to better describe their meaning. Reviewed by: adrian, bz MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D46201
* ath_hal/ar9300: allow JUPITER cards to read eepromBjoern A. Zeeb2024-03-121-2/+2
| | | | | | | | | | | | | | | Summary: In ar9300_eeprom_read_word() also allow JUPITER cards read the eeprom instead of returning an error. While this will not help all the 9462, 9485, 9565 OEM cards to work, it will make debugging of the next steps a lot easier. While here fix a typo in the error message if we do not get CAL. PR: 255337 Tested by: John Nielsen (john jnielsen net) Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D44328
* ath(4): Remove MIPS SoC build glue and AR9130 from FreeBSD HALMarius Strobl2023-08-091-13/+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
* 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_hal] Add get/set NAV functionsAdrian Chadd2021-04-191-0/+19
| | | | | | | | | | | | | | | | | | | | | 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_hal] ar9300: save TSF across full chip resetAdrian Chadd2021-04-191-1/+6
| | | | | This saves the TSF across a a full reset. The TSF is otherwise cleared and subsequent beaconing stops until the TSF catches up to nexttbtt.
* ys/contrib/dev/ath: remove unintentional double semicolonEd Maste2020-09-181-1/+1
| | | | | | | Approved by: adrian Notes: svn path=/head/; revision=365888
* [ath] [ath_hal] Propagate the HAL_RESET_TYPE through to the chip reset; set ↵Adrian Chadd2020-05-253-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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_hal_ar9300] Ensure AH_BYTE_ORDER is defined before used.Adrian Chadd2020-05-1210-0/+51
| | | | | | | Same deal here - ensure endian bits are set here first! Notes: svn path=/head/; revision=360954
* [ath_hal] [ath_hal_ar9300] Fix endian macros to work in and out of kernel tree.Adrian Chadd2020-05-122-13/+13
| | | | | | | | | | | | | | | | | | | | | | 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
* [ar9300] Disable unconditionally reducing transmit power in the case of FCC.Adrian Chadd2020-05-112-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ok, yeah, the commit title is a bit misleading. This has to do with CDD (cyclic delay diversity) - how this and later wifi hardware transmits lower rates over more antennas. Eg, if you're transmitting legacy 11abg rates on 2 or 3 antennas, you COULD just send them all at the same time or you could delay each by tens/hundreds of nanoseconds to try and get some better diversity characteristics. However, this has a fun side effect - the antenna pattern is no longer a bunch of interacting dipoles, but are a bunch of interacting dipoles plus a bunch of changing phases. And it's frequency dependent - 50-200nS is not exactly the same fraction of a wavelength across all of 2GHz or 5GHz! Thus the power spectral density and maximum directional gain that you're effectively getting is not .. well, as flat as it once was. For more information, look up FCC/OET 13TR1003 in the FCC technical report database. It has pretty graphics and everything. Anyway, the problem lies thusly - the CDD code just subtracts another 3dB or 5dB for the lower rates based on transmit antenna configuration. However, it's not done based on operating configuration and it doesn't take into account how far from any regulatory limits the hardware is at. It also doesn't let us do things like transmit legacy rates and frames on a single antenna without losing up to 5dB when we absolutely don't need to in that case (there's no CDD used when one antenna is used!) This shows up as the hardware behaving even worse for longer distance links at 20MHz because, well, those are the exact rates losing a bunch more transmit power. * For lower power NICs (ie the majority of what is out there!) it's highly unlikely we're going to hit anywhere near the PSD limits. * It's doing it based on the existing limits from the CTL table (conformance testing limits) - this isn't the regulatory max! It's what the NIC is allowed to put out in each frequency and rate configuration! So things like band edges, power amplifier behaviour and maximum current draw apply here. Blindly subtracting 3 to 5dB from /this/ value is /very/ conservative.. * /and/ ath9k just plainly doesn't do any of this at all. So, for now disable it and get the TX power back, thus matching what ath9k in Linux is doing. If/once I get some more cycles I'll look at making it a bit more adaptive and really only kick in if we're a few dB away from hard regulatory limits. Tested: * AR9344 (2GHz + SoC, 2x2 configuration) - AP and STA modes * QCA9580 (5GHz 2x2 and 3x3 configurations) - AP and STA modes Notes: svn path=/head/; revision=360888
* athhal: disable unused function (big endian only)Bjoern A. Zeeb2019-08-211-0/+4
| | | | | | | | | | | Disable ar9300_swap_tx_desc() for the moment. It is an unused function only tried to compile on big endian systems. Found by: s390x buildkernel MFC after: 3 months Notes: svn path=/head/; revision=351327
* [ath] [ath_hal] [ath_hal_9300] Extend the start PCU receive to handle ↵Adrian Chadd2019-04-213-11/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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_ar9300] Add some comments around the AR9300 ANI code.Adrian Chadd2019-03-191-2/+28
| | | | | | | | I'm refamiliarising myself with the behaviour of the ANI code and I thought I'd drop some comments to remind myself. Notes: svn path=/head/; revision=345284
* [ath_hal_ar9300] Add the missing bits from the previous HAL commit.Adrian Chadd2019-03-062-5/+56
| | | | | | | Noticed by: 75+ emails telling me I messed up. Notes: svn path=/head/; revision=344843
* [ath_hal_ar9300] Add the extra ANI configuration fields for the AR93xx HAL.Adrian Chadd2019-03-041-4/+2
| | | | | | | | | Tested: * Carambola2 (Ar9331), STA/AP modes Notes: svn path=/head/; revision=344750
* [ath_hal] Return failure if noise floor calibration fails.Adrian Chadd2018-06-083-3/+27
| | | | | | | | | | | | | | | | | | | | | | | | 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] migrate the shared HAL_RESET_* pieces out into ath_hal.Adrian Chadd2018-05-251-6/+0
| | | | | | | | | 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
* Quiesce a couple pages of clang warnings with a cast. DuplicatesSean Bruno2018-05-181-1/+1
| | | | | | | | | | | | | | | | | | | | | linux maintainer commit: https://github.com/torvalds/linux/commit/627871b71c89a6ec12fbed75063f238e0c7127b2#diff-8c6ddb4c3ad69a6fb9f289475821db56 ar9300template_aphrodite.h:575:40: warning: implicit conversion from 'int' to 'u_int8_t' (aka 'unsigned char') changes value from 3495 to 167 [-Wconstant-conversion] /* Data[8].ctl_edges[7].bChannel*/FREQ2FBIN(5795, 0)} ^~~~~~~~~~~~~~~~~~ ar9300eep.h:142:41: note: expanded from macro 'FREQ2FBIN' (((y) == HAL_FREQ_BAND_2GHZ) ? ((x) - 2300) : (((x) - 4800) / 5)) Reviewed by: imp MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D15476 Notes: svn path=/head/; revision=333801
* [ath_hal] add USB reset PLL work around for AR9331/AR9344 (Hornet/Wasp.)Adrian Chadd2017-06-041-2/+27
| | | | | | | | | | | | | | | | | | It turns out that this is useful on hornet and wasp SoCs but it isn't enabled in ye olde HAL /unless/ you were using a version from one of the business units building USB targetted devices. It eventually got fixed for all of them as people started wanting to use the USB ports on their SoCs (eg for flash storage, bluetooth, 4G/LTE widgets, etc.) This is actually a fix from ath9k but I'm merging it with the available-but- disabled code in the QCA reference HAL. Tested: * AR9331 SoC Notes: svn path=/head/; revision=319583
* 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] [ar9300] link in the CAC enable/diable methods and expose it via ↵Adrian Chadd2017-02-033-6/+8
| | | | | | | the HAL. Notes: svn path=/head/; revision=313136
* [ath_hal] [ar9300] initial radar decode for AR9380 and later chips.Adrian Chadd2017-02-031-1/+196
| | | | Notes: svn path=/head/; revision=313134
* [ath_hal] [ar9300] initial radar detection glue.Adrian Chadd2017-02-024-12/+29
| | | | | | | | | | | | | * flesh out a "get default DFS parameters" routine * remove the stub that returns NULL * fix up the enable DFS method to do what FreeBSD does - specifically, allow pe_enabled to be set/cleared. This allows the radar pulse reporting code to function, but it doesn't yet do anything useful. Notes: svn path=/head/; revision=313091
* [ath_hal] [ar9300] initial hacks to make spectral scan working on AR9380 and ↵Adrian Chadd2017-02-021-2/+32
| | | | | | | | | | | | | later NICs. * add debugging * disable the manual noise floor calibration and tracking done by the HAL; this interferes with the normal calibration path and will lock up the RX side * don't program short report / priority if they're provided as NOVAL. Notes: svn path=/head/; revision=313088
* Fix improper use of "its".Bryan Drewery2016-11-081-1/+1
| | | | | | | Sponsored by: Dell EMC Isilon Notes: svn path=/head/; revision=308457
* [ath_hal] quieten a bit of the boot messages - this stuff has been working ↵Adrian Chadd2016-09-121-0/+4
| | | | | | | for a while. Notes: svn path=/head/; revision=305723
* [ath_hal] add USB PHY control registers for hornet/AR9330.Adrian Chadd2016-08-281-0/+6
| | | | | | | Obtained from: linux ath9k Notes: svn path=/head/; revision=304944
* [ar9300] don't program a negative readytime.Adrian Chadd2016-08-091-0/+2
| | | | Notes: svn path=/head/; revision=303862
* [ath_hal] add in locationing timer support and capabilities.Adrian Chadd2016-07-081-0/+25
| | | | | | | | | | | | | | | | | | | | | * add support to read the timer and capability * add support to enable/disable the location timer. On AR9380 at least, enabling the location timer is required to make the timer tick, otherwise location packets return a timestamp of 0. However, it then makes /all/ RX packets use the RX location timestamp instead of the TSF timestamp. So, unless I find another magical way to do location timestamping, we will have to dynamically switch things on/off and ensure the TX/RX path handles the "different" timestamps correctly. Tested: * AR9380, STA mode Notes: svn path=/head/; revision=302468
* [ath_hal] add locationing / tx-beamforming RX status descriptor decoding.Adrian Chadd2016-07-081-5/+29
| | | | | | | | | | * LOC_INFO is mostly just "did this packet come with a locationing timestamp instead of TSF"; * Decode not-sounding, uploaded-data, data-valid, data type and number of extension spatial streams. Notes: svn path=/head/; revision=302467
* [ath_hal] Add setting positioning bit and clear sounding-disable bit.Adrian Chadd2016-07-081-0/+8
| | | | | | | | | | | | | * If fast_ts is set then the TX timestamp is the fast timestamp, not normal TSF. * If the TX descriptor has the position bit set then request locationing and clear sounding-disable. This way we (a) get the response with the TX timestamp from the location side of things, and (b) we get a CSI dump of the response ACK, which we will eventually use in the locationing path. Notes: svn path=/head/; revision=302466
* [ath_hal] retire a "long RX desc" flag, store/use the TX/RX timestamp length.Adrian Chadd2016-07-081-3/+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
* [ath] implement TX queue configuration extensions for the AR9380 HAL.Adrian Chadd2016-06-201-11/+31
| | | | | | | | | | | | | | | Among other things, this introduces the idea of DBA-gated queues that aren't the CABQ. The TDMA support requires this. Tested: * AR9580 (hostap mode) * AR9380 (sta mode) Approved by: re (gjb) Notes: svn path=/head/; revision=302030
* [ath_hal] modify the xmit code to use temporary variables for setting ↵Adrian Chadd2016-06-081-38/+23
| | | | | | | | | | | | qmisc/dmisc. This is in preparation for some other TDMA fixes which will hopefully end with having working TDMA. But, it does avoid lots of read/modify/writes in the txq setup path. Notes: svn path=/head/; revision=301641
* [ath_hal] add a _S so FSP (frame scheduling policy) can be set/read via ↵Adrian Chadd2016-06-081-0/+1
| | | | | | | SM/MS macros. Notes: svn path=/head/; revision=301640
* [ath_hal] correctly initialise the CAB queue default valueAdrian Chadd2016-06-081-5/+23
| | | | | | | | | | * Allow readyTime to just be programmed in directly * The beacon interval and all of the beacon timing sysctl's are in TU, not TSF. So, we were doing the wrong math on the CAB programming in the first place. Notes: svn path=/head/; revision=301639
* [ath_hal] initialise ah_beaconInterval when the AP/IBSS/TDMA beacon is setup.Adrian Chadd2016-06-082-2/+3
| | | | Notes: svn path=/head/; revision=301638
* [ath_hal] add AR9462 (jupiter) RX gain / XLNA programming.Adrian Chadd2016-06-053-0/+60
| | | | | | | | | | | | | | | | | This seems to make 5G work better. It doesn't fix powersave handling though, that still sees the PHY get stuck during initial calibration and everything goes pear shaped. I'll look into that later. Tested: * QCAFN222 NIC, STA mode, 5GHz Obtained from: Linux ath9k Notes: svn path=/head/; revision=301423
* [ath_hal] Add Jupiter 2.1 (AR9462 mac 640.3) support.Adrian Chadd2016-06-051-3/+32
| | | | | | | | | | | | | | | | | | Turns out I wasn't even initialising or programming a lot of stuff for the AR9462 2.1 chip. Oops. This mostly gets it working. powersave scan results in some pretty hilarious NFcal hangs and I don't see beacons reliably. There are still some xlna gain tables missing that ath9k has; I'll follow up with some fixes and then see if the QCAFN222 NIC I have tests this path. Tested: * QCAFN222 NIC, STA mode, 2GHz and 5GHz Notes: svn path=/head/; revision=301421
* [ath_hal] teach the reset path(s) about Jupiter 2.1.Adrian Chadd2016-06-051-3/+4
| | | | | | | | This was just .. not programming in things, and thus large chunks of the radio wouldn't work. Notably, 5GHz didn't work. Notes: svn path=/head/; revision=301420
* [ath_hal] convert the MCI code over to work on Jupiter 2.1.Adrian Chadd2016-06-051-7/+7
| | | | | | | | (Note: jupiter 1.0 was emulation / test silicon, and was never released in production. So, yes, AR_SREV_JUPITER() would really be fine.) Notes: svn path=/head/; revision=301419
* [ath_hal] Make the AR9462 2.0 initvals from ath9k compile.Adrian Chadd2016-06-051-19/+20
| | | | | | | | The (upcoming) semi-working AR9462 2.1 support uses the 2.0 initvals where appropriate, and those need to at least compile under freebsd. Notes: svn path=/head/; revision=301416
* [ath_hal] add STOMP_AUDIO for AR9462/QCA9565.Adrian Chadd2016-06-041-0/+6
| | | | | | | Obtained from: Linux ath9k Notes: svn path=/head/; revision=301305
* [ath_hal] add azimuth timestamp payload marking for AR9380 and later chips.Adrian Chadd2016-06-011-0/+1
| | | | Notes: svn path=/head/; revision=301133
* [ath_hal] implement shared PA handling checks, based on ath9k.Adrian Chadd2016-06-011-8/+16
| | | | | | | | | | | | | | | | | These are apparently conditional on there being a shared PA/LNA, which at least on AR9462/QCA9535 devices I have isn't a thing. I'm .. not yet sure which devices it /is/ a thing, so I'll come back to that. Tested: * QCA9565 STA + bluetooth Obtained from: Linux ath9k Notes: svn path=/head/; revision=301097
* [ath_hal] add MCI bits from ath9k for QCA9565Adrian Chadd2016-06-011-21/+106
| | | | | | | | | | | | | | | | | | | | | | | | * Add extra debugging - the weights debugging is really useful to ensure things are programmed into the wlan coexistence table. The weights are what traffic priority each of the various modes get (tx, tx-high-priority, rx-beacon, etc) if they're all zero, things work very poorly. * Add in coex init routines from ath9k for AR9462 and QCA9565 1ANT and 2ANT. This control things like beacon stomping, ACK handling, antennas, PA/LNA shared, etc. * Some ancillary bits. TODO: * There's some conditional stuff around MCI_ANT_ARCH_PA_LNA_SHARED() in ath9k which doesn't always enable force-on LNA. That'll have to be examined and merged in as appropriate. Obtained from: linux ath9k Notes: svn path=/head/; revision=301095
generated by cgit v1.3 (git 2.53.0) at 2026-10-03 00:15:26 +0000