From: Carl Huang <cjhuang@codeaurora.org> To: Brian Norris <briannorris@chromium.org> Cc: linux-wireless <linux-wireless@vger.kernel.org>, ath11k@lists.infradead.org, Doug Anderson <dianders@chromium.org> Subject: Re: [RFC 1/2] nl80211: add common API to configure SAR power limitations. Date: Wed, 04 Nov 2020 15:32:21 +0800 [thread overview] Message-ID: <f3be456c4c748f21836279eb4dc16e5e@codeaurora.org> (raw) In-Reply-To: <CA+ASDXM7TcF-zfbktbdSu-fDBuGe0LAgFq3Qt2zaq6efbWJ=sA@mail.gmail.com> On 2020-11-04 10:00, Brian Norris wrote: > On Mon, Sep 21, 2020 at 10:37 PM Carl Huang <cjhuang@codeaurora.org> > wrote: >> +/** >> + * struct cfg80211_sar_capa - sar limit capability >> + * @type: it's set via power in 0.25dbm or other types >> + * @num_freq_ranges: number of frequency ranges >> + * @chan_ranges: memory to hold the channel ranges. >> + */ >> +struct cfg80211_sar_capa { >> + enum nl80211_sar_type type; >> + u8 num_freq_ranges; >> + const struct cfg80211_sar_freq_ranges *freq_ranges; >> +}; > ... >> u8 max_data_retry_count; >> >> + const struct cfg80211_sar_capa *sar_capa; >> + >> char priv[] __aligned(NETDEV_ALIGN); >> }; > > What are the ABI guarantees around a given driver/chip's 'sar_capa'? > Do we guarantee that if the driver supports N ranges of certain bands, > that it will always continue to support those bands? What if, for > instance, ath10k grows a new set of subbands, supporting sub-sections > of the 5GHz band -- does it still need to support both a contiguous > [5, 5 + X] and a split [5, 5 + X/2], [5 + X/2, 5 + X]? Basically, do > we intend to put the burden on user space to figure out how to map its > power tables to the supported frequency band(s), or on the kernel, to > support a backwards-compatible set of frequency ranges? The latter > doesn't really work if you expect user space to always specify all > ranges in a SET command. > > To be clear, I'm not as worried about differences between chips or > drivers (I expect that different driver or chips may have different > range support); just about stability for a given chip. > For a given chip(at least a QCOM chip), we don't see that the range will grow or change. In addition, with current index-power SET method, it's hard for driver to know what the index mean given your example. Does the index mean [5,5 + x] or [5, 5 + x/2] ? So it's required for user-space to specify all the ranges. The number of ranges is quite small, so the SET itself is not a problem to specify all. Brian, are you fine that we go with this proposal? I'll send V2 based on the comments from Johannes and Abhishek. > Brian
WARNING: multiple messages have this Message-ID (diff)
From: Carl Huang <cjhuang@codeaurora.org> To: Brian Norris <briannorris@chromium.org> Cc: linux-wireless <linux-wireless@vger.kernel.org>, ath11k@lists.infradead.org, Doug Anderson <dianders@chromium.org> Subject: Re: [RFC 1/2] nl80211: add common API to configure SAR power limitations. Date: Wed, 04 Nov 2020 15:32:21 +0800 [thread overview] Message-ID: <f3be456c4c748f21836279eb4dc16e5e@codeaurora.org> (raw) In-Reply-To: <CA+ASDXM7TcF-zfbktbdSu-fDBuGe0LAgFq3Qt2zaq6efbWJ=sA@mail.gmail.com> On 2020-11-04 10:00, Brian Norris wrote: > On Mon, Sep 21, 2020 at 10:37 PM Carl Huang <cjhuang@codeaurora.org> > wrote: >> +/** >> + * struct cfg80211_sar_capa - sar limit capability >> + * @type: it's set via power in 0.25dbm or other types >> + * @num_freq_ranges: number of frequency ranges >> + * @chan_ranges: memory to hold the channel ranges. >> + */ >> +struct cfg80211_sar_capa { >> + enum nl80211_sar_type type; >> + u8 num_freq_ranges; >> + const struct cfg80211_sar_freq_ranges *freq_ranges; >> +}; > ... >> u8 max_data_retry_count; >> >> + const struct cfg80211_sar_capa *sar_capa; >> + >> char priv[] __aligned(NETDEV_ALIGN); >> }; > > What are the ABI guarantees around a given driver/chip's 'sar_capa'? > Do we guarantee that if the driver supports N ranges of certain bands, > that it will always continue to support those bands? What if, for > instance, ath10k grows a new set of subbands, supporting sub-sections > of the 5GHz band -- does it still need to support both a contiguous > [5, 5 + X] and a split [5, 5 + X/2], [5 + X/2, 5 + X]? Basically, do > we intend to put the burden on user space to figure out how to map its > power tables to the supported frequency band(s), or on the kernel, to > support a backwards-compatible set of frequency ranges? The latter > doesn't really work if you expect user space to always specify all > ranges in a SET command. > > To be clear, I'm not as worried about differences between chips or > drivers (I expect that different driver or chips may have different > range support); just about stability for a given chip. > For a given chip(at least a QCOM chip), we don't see that the range will grow or change. In addition, with current index-power SET method, it's hard for driver to know what the index mean given your example. Does the index mean [5,5 + x] or [5, 5 + x/2] ? So it's required for user-space to specify all the ranges. The number of ranges is quite small, so the SET itself is not a problem to specify all. Brian, are you fine that we go with this proposal? I'll send V2 based on the comments from Johannes and Abhishek. > Brian -- ath11k mailing list ath11k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath11k
next prev parent reply other threads:[~2020-11-04 7:32 UTC|newest] Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-22 5:36 [RFC 1/2] nl80211: add common API to configure SAR power limitations Carl Huang 2020-09-22 5:36 ` Carl Huang 2020-09-22 5:36 ` [RFC 2/2] ath10k: allow dynamic SAR power limits via common API Carl Huang 2020-09-22 5:36 ` Carl Huang 2020-09-22 5:47 ` [RFC 1/2] nl80211: add common API to configure SAR power limitations cjhuang 2020-09-22 5:47 ` cjhuang 2020-09-22 8:09 ` Kalle Valo 2020-09-22 8:09 ` Kalle Valo 2020-11-04 2:00 ` Brian Norris 2020-11-04 2:00 ` Brian Norris 2020-11-04 7:32 ` Carl Huang [this message] 2020-11-04 7:32 ` Carl Huang 2020-11-04 17:44 ` Brian Norris 2020-11-04 17:44 ` Brian Norris 2020-11-04 17:44 ` Brian Norris 2020-11-05 8:35 ` Kalle Valo 2020-11-05 8:35 ` Kalle Valo 2020-11-05 8:35 ` Kalle Valo 2020-11-05 11:10 ` Carl Huang 2020-11-05 11:10 ` Carl Huang 2020-11-05 11:10 ` Carl Huang 2020-11-05 18:25 ` Brian Norris 2020-11-05 18:25 ` Brian Norris 2020-11-05 18:25 ` Brian Norris 2020-11-06 10:11 ` Carl Huang 2020-11-06 10:11 ` Carl Huang 2020-11-06 10:11 ` Carl Huang 2020-11-05 11:17 ` Carl Huang 2020-11-05 11:17 ` Carl Huang 2020-11-05 11:17 ` Carl Huang 2020-09-22 5:49 Carl Huang 2020-09-22 5:49 ` Carl Huang 2020-09-28 12:36 ` Johannes Berg 2020-09-28 12:36 ` Johannes Berg 2020-10-30 20:56 ` Abhishek Kumar 2020-10-30 20:56 ` Abhishek Kumar 2020-10-31 2:46 ` Abhishek Kumar 2020-11-03 2:34 ` Carl Huang 2020-11-03 2:34 ` Carl Huang 2020-11-03 13:15 ` Johannes Berg 2020-11-03 13:15 ` Johannes Berg 2020-11-04 1:17 ` Abhishek Kumar 2020-11-04 1:17 ` Abhishek Kumar 2020-11-04 6:18 ` Carl Huang 2020-11-04 6:18 ` Carl Huang 2020-11-04 8:44 ` Carl Huang 2020-11-04 8:44 ` Carl Huang 2020-11-04 17:48 ` Brian Norris 2020-11-04 17:48 ` Brian Norris 2020-11-05 11:37 ` Carl Huang 2020-11-05 11:37 ` Carl Huang 2020-11-04 23:18 ` Brian Norris 2020-11-04 23:18 ` Brian Norris 2020-11-04 23:27 ` Brian Norris 2020-11-04 23:27 ` Brian Norris 2020-11-05 11:30 ` Carl Huang 2020-11-05 11:30 ` Carl Huang
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=f3be456c4c748f21836279eb4dc16e5e@codeaurora.org \ --to=cjhuang@codeaurora.org \ --cc=ath11k@lists.infradead.org \ --cc=briannorris@chromium.org \ --cc=dianders@chromium.org \ --cc=linux-wireless@vger.kernel.org \ /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.