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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
