mirror of
https://github.com/opnsense/src.git
synced 2026-04-29 10:11:09 -04:00
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 |
||
|---|---|---|
| .. | ||
| ar2133.c | ||
| ar5416.h | ||
| ar5416.ini | ||
| ar5416_ani.c | ||
| ar5416_attach.c | ||
| ar5416_beacon.c | ||
| ar5416_btcoex.c | ||
| ar5416_btcoex.h | ||
| ar5416_cal.c | ||
| ar5416_cal.h | ||
| ar5416_cal_adcdc.c | ||
| ar5416_cal_adcgain.c | ||
| ar5416_cal_iq.c | ||
| ar5416_eeprom.c | ||
| ar5416_gpio.c | ||
| ar5416_interrupts.c | ||
| ar5416_keycache.c | ||
| ar5416_misc.c | ||
| ar5416_phy.c | ||
| ar5416_power.c | ||
| ar5416_radar.c | ||
| ar5416_recv.c | ||
| ar5416_reset.c | ||
| ar5416_spectral.c | ||
| ar5416_xmit.c | ||
| ar5416desc.h | ||
| ar5416phy.h | ||
| ar5416reg.h | ||