On 9/7/20 9:07 AM, Kalle Valo wrote:
Ben Greear <greearb@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
