From: Ben Greear <greearb@candelatech.com> To: Johannes Berg <johannes@sipsolutions.net>, Oleksij Rempel <linux@rempel-privat.de>, "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>, ath10k <ath10k@lists.infradead.org>, kirtika@google.com Subject: Re: Setting single rate in ath10k broken by "reject/clear user rate mask if not usable" Date: Wed, 18 Oct 2017 13:51:15 -0700 [thread overview] Message-ID: <9791c86a-a15f-4c99-ab84-ce00b242d70f@candelatech.com> (raw) In-Reply-To: <1508358869.2674.55.camel@sipsolutions.net> On 10/18/2017 01:34 PM, Johannes Berg wrote: > Hi, > > On Wed, 2017-10-18 at 19:56 +0200, Oleksij Rempel wrote: >> >>> People trying to do regulatory testing want this feature, and other people >>> that are not me also like to test with specific rates. Still a >>> small-ish set of people, but bigger than just me at least. >> >> Till now i was interviewing different people who was asking for this for >> ath9k-htc. So I would say we have: >> - academical researchers >> - testers >> - R&D >> - exploit and penetration testers >> - HAM >> - just hackers >> >> As for me, it sounds a s lot. > > Making (literally) millions of devices in the field hit a WARN_ON() is > not really acceptable either though. > > You can argue that this introduced a regression, but putting the old > behaviour back would equally be a regression, for more systems by a few > orders of magnitude. > > In any case, I've already suggested a way to fix this, but you've both > completely ignored that part of my email. All I've been reading is that > you're demanding that I fix this, and arguments about how much people > are allowed to shoot themselves in the foot, none of which is very > constructive. You mean this part? It wasn't clear to me that you thought this was a good solution that should be implemented. " I guess you could implement this part? I.e. iterating the clients and checking that they all support the rate that is set. However, then you also need to implement that this gets reset when a new client that doesn't support this rate connects. " The first part seems OK, but the second seems like a pain. Maybe just keep a new client from being able to connect at all if it doesn't support any available rates? Thanks, Ben > I might even fix it myself eventually, if only to appease the people > who say we have a zero tolerance no regressions rule, but it's not > exactly the most important thing I'm doing right now (also, I'll be > going on vacation for a few days, and you can probably implement my > suggestion in that time, and then I can review it when I get back on > Monday.) > > Let's just say that I think we're discussing the wrong thing here - we > ought to be discussing how it can be fixed, and perhaps you can even be > constructive in suggesting (and testing, which I can't really do) > changes. > > johannes > -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com
WARNING: multiple messages have this Message-ID (diff)
From: Ben Greear <greearb@candelatech.com> To: Johannes Berg <johannes@sipsolutions.net>, Oleksij Rempel <linux@rempel-privat.de>, "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>, ath10k <ath10k@lists.infradead.org>, kirtika@google.com Subject: Re: Setting single rate in ath10k broken by "reject/clear user rate mask if not usable" Date: Wed, 18 Oct 2017 13:51:15 -0700 [thread overview] Message-ID: <9791c86a-a15f-4c99-ab84-ce00b242d70f@candelatech.com> (raw) In-Reply-To: <1508358869.2674.55.camel@sipsolutions.net> On 10/18/2017 01:34 PM, Johannes Berg wrote: > Hi, > > On Wed, 2017-10-18 at 19:56 +0200, Oleksij Rempel wrote: >> >>> People trying to do regulatory testing want this feature, and other people >>> that are not me also like to test with specific rates. Still a >>> small-ish set of people, but bigger than just me at least. >> >> Till now i was interviewing different people who was asking for this for >> ath9k-htc. So I would say we have: >> - academical researchers >> - testers >> - R&D >> - exploit and penetration testers >> - HAM >> - just hackers >> >> As for me, it sounds a s lot. > > Making (literally) millions of devices in the field hit a WARN_ON() is > not really acceptable either though. > > You can argue that this introduced a regression, but putting the old > behaviour back would equally be a regression, for more systems by a few > orders of magnitude. > > In any case, I've already suggested a way to fix this, but you've both > completely ignored that part of my email. All I've been reading is that > you're demanding that I fix this, and arguments about how much people > are allowed to shoot themselves in the foot, none of which is very > constructive. You mean this part? It wasn't clear to me that you thought this was a good solution that should be implemented. " I guess you could implement this part? I.e. iterating the clients and checking that they all support the rate that is set. However, then you also need to implement that this gets reset when a new client that doesn't support this rate connects. " The first part seems OK, but the second seems like a pain. Maybe just keep a new client from being able to connect at all if it doesn't support any available rates? Thanks, Ben > I might even fix it myself eventually, if only to appease the people > who say we have a zero tolerance no regressions rule, but it's not > exactly the most important thing I'm doing right now (also, I'll be > going on vacation for a few days, and you can probably implement my > suggestion in that time, and then I can review it when I get back on > Monday.) > > Let's just say that I think we're discussing the wrong thing here - we > ought to be discussing how it can be fixed, and perhaps you can even be > constructive in suggesting (and testing, which I can't really do) > changes. > > johannes > -- 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
next prev parent reply other threads:[~2017-10-18 20:51 UTC|newest] Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-10-10 20:54 Setting single rate in ath10k broken by "reject/clear user rate mask if not usable" Ben Greear 2017-10-10 20:54 ` Ben Greear 2017-10-11 4:37 ` Not able to set single rate in ath10k (backports-4.14-rc2-1) KAVITA MATHUR 2017-10-11 8:02 ` Setting single rate in ath10k broken by "reject/clear user rate mask if not usable" Johannes Berg 2017-10-11 8:02 ` Johannes Berg 2017-10-11 8:07 ` Johannes Berg 2017-10-11 8:07 ` Johannes Berg 2017-10-11 14:51 ` Ben Greear 2017-10-11 14:51 ` Ben Greear 2017-10-18 7:33 ` Johannes Berg 2017-10-18 7:33 ` Johannes Berg 2017-10-18 14:50 ` Ben Greear 2017-10-18 14:50 ` Ben Greear 2017-10-18 17:56 ` Oleksij Rempel 2017-10-18 17:56 ` Oleksij Rempel 2017-10-18 20:34 ` Johannes Berg 2017-10-18 20:34 ` Johannes Berg 2017-10-18 20:51 ` Ben Greear [this message] 2017-10-18 20:51 ` Ben Greear 2017-10-18 21:02 ` Johannes Berg 2017-10-18 21:02 ` Johannes Berg 2017-10-18 21:30 ` Ben Greear 2017-10-18 21:30 ` Ben Greear 2017-10-25 15:17 ` Johannes Berg 2017-10-25 15:17 ` Johannes Berg 2017-10-25 16:13 ` Ben Greear 2017-10-25 16:13 ` Ben Greear 2017-10-27 20:15 ` Johannes Berg 2017-10-27 20:15 ` Johannes Berg 2017-10-27 20:41 ` Ben Greear 2017-10-27 20:41 ` Ben Greear 2017-11-13 10:09 ` Johannes Berg 2017-11-13 10:09 ` Johannes Berg 2017-11-13 17:05 ` Ben Greear 2017-11-13 17:05 ` 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=9791c86a-a15f-4c99-ab84-ce00b242d70f@candelatech.com \ --to=greearb@candelatech.com \ --cc=ath10k@lists.infradead.org \ --cc=johannes@sipsolutions.net \ --cc=kirtika@google.com \ --cc=linux-wireless@vger.kernel.org \ --cc=linux@rempel-privat.de \ /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: linkBe 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.