Adrian Chadd 8c01c3dc46 [ath] [ath_hal] Propagate the HAL_RESET_TYPE through to the chip reset; set 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		2020-05-25 22:31:45 +00:00
..
ar9002phy.h
ar9280.c
ar9280.h
ar9280_attach.c
ar9280_olc.c
ar9280_olc.h
ar9280v1.ini
ar9280v2.ini
ar9285.c
ar9285.h
ar9285.ini
ar9285_attach.c
ar9285_btcoex.c
ar9285_cal.c
ar9285_cal.h
ar9285_diversity.c
ar9285_diversity.h
ar9285_phy.c
ar9285_phy.h
ar9285_reset.c
ar9285an.h
ar9285phy.h
ar9285v2.ini
ar9287.c
ar9287.h
ar9287.ini
ar9287_attach.c
ar9287_cal.c
ar9287_cal.h
ar9287_olc.c
ar9287_olc.h
ar9287_reset.c
ar9287_reset.h
ar9287an.h
ar9287phy.h