All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: Michal Kazior <michal.kazior@tieto.com>
Cc: linux-wireless <linux-wireless@vger.kernel.org>,
	"ath10k@lists.infradead.org" <ath10k@lists.infradead.org>
Subject: Re: [RFC] wmi: Handle failure to start scan.
Date: Mon, 17 Feb 2014 08:10:50 -0800	[thread overview]
Message-ID: <5302348A.9090700@candelatech.com> (raw)
In-Reply-To: <CA+BoTQ=cojyffQrTGmq7zgpfUNSBB9nrZEPpy5hsngnBW2j3pA@mail.gmail.com>

On 02/16/2014 11:42 PM, Michal Kazior wrote:
> On 14 February 2014 17:07, Ben Greear <greearb@candelatech.com> 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@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

WARNING: multiple messages have this Message-ID (diff)
From: Ben Greear <greearb@candelatech.com>
To: Michal Kazior <michal.kazior@tieto.com>
Cc: linux-wireless <linux-wireless@vger.kernel.org>,
	"ath10k@lists.infradead.org" <ath10k@lists.infradead.org>
Subject: Re: [RFC] wmi: Handle failure to start scan.
Date: Mon, 17 Feb 2014 08:10:50 -0800	[thread overview]
Message-ID: <5302348A.9090700@candelatech.com> (raw)
In-Reply-To: <CA+BoTQ=cojyffQrTGmq7zgpfUNSBB9nrZEPpy5hsngnBW2j3pA@mail.gmail.com>

On 02/16/2014 11:42 PM, Michal Kazior wrote:
> On 14 February 2014 17:07, Ben Greear <greearb@candelatech.com> 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@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


  reply	other threads:[~2014-02-17 16:11 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-13 19:09 [RFC] wmi: Handle failure to start scan greearb
2014-02-13 19:09 ` greearb
2014-02-14  6:13 ` Kalle Valo
2014-02-14  6:13   ` Kalle Valo
2014-02-14  6:47 ` Michal Kazior
2014-02-14  6:47   ` Michal Kazior
2014-02-14 16:07   ` Ben Greear
2014-02-14 16:07     ` Ben Greear
2014-02-17  7:42     ` Michal Kazior
2014-02-17  7:42       ` Michal Kazior
2014-02-17 16:10       ` Ben Greear [this message]
2014-02-17 16:10         ` Ben Greear

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5302348A.9090700@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=ath10k@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=michal.kazior@tieto.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.