On 02/16/2014 11:42 PM, Michal Kazior wrote:
On 14 February 2014 17:07, Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote:
We already wait for EVENT_STARTED in mac.c (see ath10k_start_scan) and
clean up stuff (ath10k_abort_scan). Why not add the missing bits in
there? Or is it possible to get EVENT_START_FAILED *after*
EVENT_STARTED? Or am I missing something else here?
I think a lot of this would be firmware dependent, and might change between
various versions of the firmware.
It doesn't make any sense. That would suggest a really ugly firmware
bug. Did you see this (i.e. START_FAILED after STARTED) on 636 or
10.1.467?
I am working on a 10.1.389 release currently...will move forward when
I can get access to newer source code.
It seems to me we should handle this case and do cleanup just to be safe,
but maybe cleanup is needed in failure case of ath10k_start_scan as well?
If you really get START_FAILED then you shouldn't have received
STARTED before that. ath10k_start_scan() already waits for the STARTED
event with a timeout and if it fails it triggers a cleanup. If it
doesn't work for you then what perhaps needs to be fixed is the
current cleanup code?
I am not certain the patch is needed. I was looking at my firmware and it
appeared that I could hit the START_FAILED case, but perhaps it was not
really possible, and maybe newer firmware keeps it from happening entirely.
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
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
