8c01c3dc46
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 |
||
|---|---|---|
| .. | ||
| alpine-hal | ||
| ck | ||
| cloudabi | ||
| dev | ||
| edk2 | ||
| ena-com | ||
| ipfilter/netinet | ||
| libb2 | ||
| libfdt | ||
| libnv | ||
| libsodium | ||
| ncsw | ||
| ngatm | ||
| octeon-sdk | ||
| rdma/krping | ||
| v4l | ||
| vchiq/interface | ||
| x86emu | ||
| xz-embedded | ||
| zlib | ||
| zstd | ||