On 2020-08-20 17:26, Krishna Chaitanya wrote:
On Thu, Aug 20, 2020 at 2:49 PM Krishna Chaitanya
<chaitanya.mgit@xxxxxxxxx> wrote:
On Thu, Aug 20, 2020 at 2:03 PM Kalle Valo <kvalo@xxxxxxxxxxxxxx>
wrote:
>
> Wen Gong <wgong@xxxxxxxxxxxxxx> writes:
>
...
> I'm not really convinced that this is the right fix, but I'm no NAPI
> expert. Can anyone else help?
Calling napi_disable() twice can lead to hangs, but moving NAPI from
start/stop to
the probe isn't the right approach as the datapath is tied to
start/stop.
Maybe check the state of NAPI before disable?
if (test_bit(NAPI_STATE_SCHED, &ar->napi.napi.state))
napi_disable(&ar->napi)
or maintain napi_state like this
https://patchwork.kernel.org/patch/10249365/
Also, the most common cause for such issues (1st
napi_synchronize/napi_disable hang)
is that napi_poll is being scheduled, so, you might want to check that
napi_schedule isn't
called after stop.
cd ath10k; git log --grep=napi shows plenty of such issues. the one
that matches closest is
c2cac2f74ab4bcf0db0dcf3a612f1e5b52d145c8, so, it could just be a
regression.
Also, I see that napi_schedule() is being called from work_queue
async_work_rx
so we should cancel that work in hif_stop before calling
napi_synchronize.
Yes, I will do that in a new patch.
