Re: [PATCH 3.7 2/3] ath9k: improve suspend/resume reliability

[Felix Fietkau <nbd@openwrt.org>]

On 2012-10-06 12:46 PM, Manoharan, Sujith wrote:
> On 2012-10-04 4:33 AM, Sujith Manoharan wrote:
>> Felix Fietkau wrote:
>>> Ensure that drv_start() always returns true, as a failing hw start usually
>>> eventually leads to crashes when there's still a station entry present.
>>> Call a power-on reset after a resume and after a hw reset failure to bring
>>> the hardware back to life again.
>>
>> In what situations did HW reset (via start() or resume()) fail ?
>> I don't know what situations caused it, but this happened on a few
>> ChromeOS devices in the wild, and my patch fixed it.
> 
> Well, the cause for the real issue, the HW reset failure is still unknown.
> I think we might be papering over some other bug here.
After a suspend/resume cycle, the card definitely needs at least one
power-on reset (since we can assume that the card was power cycled), as
is done on driver initialization as well. My patch ensures that this
happens by setting a flag on resume.

If for some reason the drv_start() reset still fails (and I'm not aware
of any such instances), it's still much better to return 0. The reset
failure will still appear in log messages.

If we return an error code in drv_start, this tends to create a mess of
either WARN_ON/BUG_ON calls triggered at a later point in time (if a
station was connected), or just a complete loss of wifi functionality.

- Felix