Michal Kazior <michal.kaz...@tieto.com> writes: > On 21 October 2014 10:17, Kalle Valo <kv...@qca.qualcomm.com> wrote: >> Michal Kazior <michal.kaz...@tieto.com> writes: >> >>> In some cases hw recovery was taking an absurdly >>> long time due to ath10k waiting for things that >>> would never really complete. >>> >>> Instead of waiting for inevitable timeouts poke >>> all completions and wakequeues and check if it's >>> still worth waiting. >>> >>> Reading/writing ar->state requires conf_mutex. >>> Since waiters might be holding it introduce a new >>> flag CRASH_FLUSH so it's possible to tell waiters >>> to abort whatever they were waiting for. >>> >>> Signed-off-by: Michal Kazior <michal.kaz...@tieto.com> >> >> While applying to ath-next-test there was a conflict in core.h. Please >> check my resolution: >> >> https://github.com/kvalo/ath/commit/6cccda0185c7df96f439dc3f87961e81843de3ee > > I think it was `enum ath10k_cal_mode {` vs `enum ath10k_scan_state {` > because my patch was based without your cal patches.
Yeah, that was the reason as I applied the cal file patches just an hour ago. With the amount of patches going to ath10k these conflicts are "business as usual", we just need to be careful with resolutions. As long as everyone use ath.git master branch as the baseline everything should go pretty smoothly, most of the time :) -- Kalle Valo _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
