Adrian Chadd f50e4ebf6a ath(4): begin fleshing out a "reset type" extension to force cold/warn resets. ... Right now the only way to force a cold reset is: * The HAL itself detects it's needed, or * The sysctl, setting all resets to be cold. Trouble is, cold resets take quite a bit longer than warm resets. However, there are situations where a cold reset would be nice. Specifically, after a stuck beacon, BB/MAC hang, stuck calibration results, etc. The vendor HAL has a separate method to set the reset reason (which is how HAL_RESET_BBPANIC gets set) which informs the HAL during the reset path why it occured. This is almost but not quite the same; I may eventually unify both approaches in the future. This commit just extends HAL_RESET_TYPE to include both status (eg BBPANIC) and type (eg do COLD.) None of the HAL code uses it yet though; that'll come later. It also is a big no-op in each HAL - I need to go teach each of the HALs about cold/warm reset through this path.		2015-11-09 15:59:42 +00:00
..
ar5211.h	ath(4): begin fleshing out a "reset type" extension to force cold/warn resets.	2015-11-09 15:59:42 +00:00
ar5211_attach.c	Add initial support for the AR9485 CUS198 / CUS230 variants.	2014-09-30 03:19:29 +00:00
ar5211_beacon.c
ar5211_interrupts.c
ar5211_keycache.c
ar5211_misc.c	Begin adding support to explicitly set the current chainmask.	2013-02-25 22:42:43 +00:00
ar5211_phy.c
ar5211_power.c	* Only update ah_powerMode if we're setting the chip sleep state.	2014-04-30 02:03:13 +00:00
ar5211_recv.c
ar5211_reset.c	ath(4): begin fleshing out a "reset type" extension to force cold/warn resets.	2015-11-09 15:59:42 +00:00
ar5211_xmit.c
ar5211desc.h
ar5211phy.h
ar5211reg.h
boss.ini