From: Kalle Valo <email@example.com> To: Johannes Berg <firstname.lastname@example.org> Cc: Brian Norris <email@example.com>, Jouni Malinen <firstname.lastname@example.org>, Pkshih <email@example.com>, "linux-wireless\@vger.kernel.org" <firstname.lastname@example.org>, "ath10k\@lists.infradead.org" <email@example.com>, Wen Gong <firstname.lastname@example.org> Subject: Re: [PATCH 1/2] nl80211: vendor-cmd: qca: add dynamic SAR power limits Date: Tue, 8 Sep 2020 05:55:01 +0000 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> (Johannes Berg's message of "Thu, 30 Jul 2020 15:24:11 +0200") Johannes Berg <email@example.com> writes: > On Fri, 2020-07-24 at 12:26 +0300, Kalle Valo wrote: > >> > > So to me it feels like the best solution forward is to go with the >> > > vendor API, do you agree? We can, of course, later switch to the common >> > > API if we manage to create one which is usable for everyone. > > But why wouldn't we try that now, while we have it all in our heads (in > a way ... even if this discussion drags out forever)? > > I mean, the range-based approach ought to work, and if we define it as a > nested attribute list or so, we can even later add more attributes to it > (chain limits, whatnot) without any backward compatibility concerns. > > So what is it that we _cannot_ do in a more common way today? > >> > I think we've had some healthy (though very protracted) discussion, >> > and I don't think I've seen anyone bring up anything I wasn't already >> > aware of that would prevent eventual consolidation. As long as we >> > acknowledge those things (item 2 at >> > https://wireless.wiki.kernel.org/en/developers/documentation/nl80211#vendor-specific_api), >> > I'm happy. >> >> Good, I was just checking that we all are on the same page. > > But are we? ;-) > > I don't really see anything in the new proposal  that really explains > why the common API that we've sort of vaguely outlined in this thread > couldn't work? It just speaks of technical difficulties ("need a > reporting API too"), but should we let that stop us? > >  https://patchwork.kernel.org/patch/11686317/ I misunderstood then, I thought everyone were leaning towards the vendor API approach. But yeah, of course a common API is much better if people think it's doable. So I'll now drop all the vendor API patches from patchwork and assume/hope that we will get the common API at some point. -- https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
next prev parent reply other threads:[~2020-09-08 5:55 UTC|newest] Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-18 15:48 [PATCH 0/2] ath10k: SAR power limit vendor command Kalle Valo 2019-12-18 15:48 ` Kalle Valo 2019-12-18 15:48 ` [PATCH 1/2] nl80211: vendor-cmd: qca: add dynamic SAR power limits Kalle Valo 2019-12-18 15:48 ` Kalle Valo 2019-12-19 9:44 ` Pkshih 2019-12-19 9:44 ` Pkshih 2019-12-19 15:48 ` Jouni Malinen 2019-12-19 15:48 ` Jouni Malinen 2019-12-19 18:32 ` Brian Norris 2019-12-19 18:32 ` Brian Norris 2019-12-19 18:55 ` Jouni Malinen 2019-12-19 18:55 ` Jouni Malinen 2019-12-19 23:40 ` Brian Norris 2019-12-19 23:40 ` Brian Norris 2020-03-17 16:54 ` Kalle Valo 2020-03-17 16:54 ` Kalle Valo 2020-03-20 12:55 ` Johannes Berg 2020-03-20 12:55 ` Johannes Berg 2020-06-02 1:32 ` Brian Norris 2020-06-02 1:32 ` Brian Norris 2020-07-16 9:35 ` Kalle Valo 2020-07-16 9:35 ` Kalle Valo 2020-07-16 18:56 ` Brian Norris 2020-07-16 18:56 ` Brian Norris 2020-07-24 9:26 ` Kalle Valo 2020-07-24 9:26 ` Kalle Valo 2020-07-30 13:24 ` Johannes Berg 2020-07-30 13:24 ` Johannes Berg 2020-08-01 1:31 ` Brian Norris 2020-08-01 1:31 ` Brian Norris 2020-09-08 5:55 ` Kalle Valo 2020-09-08 5:55 ` Kalle Valo [this message] 2020-07-30 13:17 ` Johannes Berg 2020-07-30 13:17 ` Johannes Berg 2019-12-18 15:48 ` [PATCH 2/2] ath10k: allow dynamic SAR power limits to be configured Kalle Valo 2019-12-18 15:48 ` Kalle Valo 2019-12-19 9:45 ` Pkshih 2019-12-19 9:45 ` Pkshih 2020-04-16 7:38 ` Kalle Valo 2020-04-16 7:38 ` Kalle Valo
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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH 1/2] nl80211: vendor-cmd: qca: add dynamic SAR power limits' \ /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: link
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.