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
Use a temporary variable, make the lines shorter. Differential Revision: https://reviews.freebsd.org/D48239 Reviewed by: emaste
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
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
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
Reported by: GCC -Warray-parameter Reviewed by: imp, emaste Differential Revision: https://reviews.freebsd.org/D37542
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.
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.
Approved by: adrian
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