[RFC] ath10k: change to do napi_enable and napi_disable when insmod and rmmod for sdio

[Ben Greear]

On 9/7/20 9:07 AM, Kalle Valo wrote:
> Ben Greear <greearb at candelatech.com> writes:
> 
>>>>>>> Here is my original patch to fix this, it is not complex.
>>>>>>>
>>>>>>> https://patchwork.kernel.org/patch/10249363/
>>>>>> Sure, I have shared your patch above :).
>>>>> Sent a bit early, any idea why this wasn't upstreamed earlier?
>>>>
>>>> No, one comment from Michal indicated maybe there were more problems lurking
>>>> in this area, but he seemed to be OK with the patch over all.  After that,
>>>> it was just ignored.
>>>>
>>> Now might be a good time to push for it :)
>>>
>>
>> It is generally a waste of time in my experience.  Kalle is the maintainer and should
>> be seeing any of this he cares to see.  If he likes the patch, he can apply it or
>> something similar.  If you have a reproducible test case, see if the patch fixes
>> things, that might help it be accepted.
> 
> The problem with yours (Ben's) patches is that you have your own set of
> patches for ath10k and your own firmware. So I cannot know at all if
> your patches work with upstream ath10k and upstream firmware, and would
> need to test the patches myself. But nowadays I just can't find the time
> for testing. So if someone else can do the testing and provide a
> Tested-on tag it would it increase my confidence level for the patches.

Surely codeaura could get a few entry level engineers to run basic testing against
your target platforms on a regular basis?  The several years of time this bug was
known (to me at least, and to whoever saw my original patch) and the time wasted
by codeaura to rediscover and re-fix the bug would have much better been spent just
testing and review my patch to begin with.  And not just my patches either, this
pattern is far and wide in ath10k.

Also, my driver is often tested against various upstream QCA firmware and chipsets in openwrt,
so while bugs are always possible, there is some test coverage.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com