Hi Michal / Kalle / Ben, is this patch is good to go (or) should i re-work ? I had replied to Michal's comment of introducing a new firmware feature flag will not address the issue in older firmware / code. Let me know if i had missed something very obvious. On Tue, Jul 05, 2016 at 08:21:01AM -0700, Ben Greear wrote: > On 06/30/2016 03:25 AM, Valo, Kalle wrote: > >Ben Greear <greearb@xxxxxxxxxxxxxxx> writes: > > > >>Is there a better way than posting to the ath10k mailing list? There are quite > >>a few more of my patches that are stuck in pending or ignored state. If you > >>could review some of them and add them to your testing trees then it might help > >>them go upstream. > > > >Yes, as you seem to test with your custom ath10k and custom firmware > >review and testing feedback from others is more than welcome. That way I > >can have more confidence that the patch really works with the mainline > >version. > > > >The problem with your patches is that you dump more responsibility on > >me. I have no idea if they work with the mainline kernel, or if they > >break something, so I need to personally test the patch and that takes > >time. Basically I have a rule if that I need to use more than two > >minutes on a patch it goes to the Deferred queue and I'll go through > >that less often than the normal patch queue. > > I can do some testing with stock firmware, but stock firmware is often quite limited > so I cannot do the more interesting test cases that we use internally. > Some of my patches are for fixing edge cases that cannot be easily reproduced, > and that code really needs to be reviewed for correctness more by looking at > the code than by trying to run some exhaustive test case. > > I think if there were a specific maintainer for ath10k that could take a more > active role, especially with regard to keeping a fairly wide variety of test rigs > around to run regression tests, then it would help all involved. I think this person > needs access to firmware source so that they can more easily verify the driver > matches the firmware: Many of the regressions and bug fixes, for instance with > stats, would be much easier to clean up if you look at firmware while developing > the driver bits. > regards, shafi -- 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
