From: Carl Huang <cjhuang@codeaurora.org>
To: Abhishek Kumar <kuabhs@chromium.org>
Cc: briannorris@chromium.org, linux-wireless@vger.kernel.org,
dianders@chromium.org, ath10k@lists.infradead.org,
johannes@sipsolutions.net
Subject: Re: [RFC 1/2] nl80211: add common API to configure SAR power limitations.
Date: Tue, 03 Nov 2020 10:34:47 +0800 [thread overview]
Message-ID: <e5302eb0b20339d3f6544652e4034993@codeaurora.org> (raw)
In-Reply-To: <20201031024631.1528113-1-kuabhs@chromium.org>
On 2020-10-31 10:46, Abhishek Kumar wrote:
> From: kuabhs@chromium.org
>
> There are few more additional comments here.
>> + * @NL80211_CMD_SET_SAR_SPECS: SAR power limitation configuration is
>> + * passed using %NL80211_ATTR_SAR_SPEC.
>> + *
>
> This command requires NL80211_ATTR_IFINDEX, probably should be better
> to add
> this in the comment ?
>
Per Johannes's comments, this explicit index is not required. Are you
fine
with it?
Instead, user-space application records the array index when querying
the SAR
capability. When set, the nested array index will be used to set the
power.
This requires user-space has a strict mapping of index. and
NL80211_ATTR_IFINDEX
is to be removed.
>> +static int
>> +nl80211_put_sar_specs(struct cfg80211_registered_device *rdev,
>> + struct sk_buff *msg)
>> +{
>> + struct nlattr *sar_capa, *specs, *sub_freq_range;
>> + u8 num_freq_ranges;
>> + int i;
>> +
>> + if (!rdev->wiphy.sar_capa)
>> + return 0;
>> +
>> + num_freq_ranges = rdev->wiphy.sar_capa->num_freq_ranges;
>> +
>> + sar_capa = nla_nest_start(msg, NL80211_ATTR_SAR_SPEC);
>> + if (!sar_capa)
>> + return -ENOSPC;
>
> I see some places nla_nest_start_noflag being used and here
> nla_nest_start.
> Whats the specific reason to do that ? In the newer Kernel versions, I
> believe
> nla_nest_start is preferred.
>
This will be addressed in next version.
>> + power =
>> nla_get_u8(spec[NL80211_SAR_ATTR_SPECS_POWER]);
>> + sar_spec->sub_specs[specs].power = power;
>> +
>> + /* if NL80211_SAR_ATTR_SPECS_FREQ_RANGE_INDEX isn't
>> present,
>> + * then the power applies to all bands. But it's only
>> valid
>> + * for the first entry.
>> + */
>> + if (!spec[NL80211_SAR_ATTR_SPECS_FREQ_RANGE_INDEX]) {
>> + if (specs) {
>> + err = -EINVAL;
>> + goto error;
>> + } else {
>> +
>> sar_spec->sub_specs[specs].freq_range_index =
>> + NL80211_SAR_ALL_FREQ_RNAGES;
>> + specs++;
>> + break;
>> + }
>> + }
>
> Here I see you are assigning same power to all freq band if for the
> first band
> the freq index is not provided. Is there any specific reason to only
> check the first
> here ? Probably this logic should move into specific drivers. Thoughts
> ?
>
This logic will be removed per Johannes's comments.
Please read Johannes's comments. If you agree with him and has no other
advices,
then I will post the second version of it.
> -Abhishek
>
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2020-11-03 13:13 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-22 5:49 [RFC 1/2] nl80211: add common API to configure SAR power limitations Carl Huang
2020-09-22 5:49 ` [RFC 2/2] ath10k: allow dynamic SAR power limits via common API Carl Huang
2020-11-04 23:11 ` Brian Norris
2020-11-05 11:27 ` Carl Huang
2020-11-05 17:49 ` Brian Norris
2020-09-28 12:36 ` [RFC 1/2] nl80211: add common API to configure SAR power limitations Johannes Berg
2020-10-30 20:56 ` Abhishek Kumar
2020-10-31 2:46 ` Abhishek Kumar
2020-11-03 2:34 ` Carl Huang [this message]
2020-11-03 13:15 ` Johannes Berg
2020-11-04 1:17 ` Abhishek Kumar
2020-11-04 6:18 ` Carl Huang
2020-11-04 8:44 ` Carl Huang
2020-11-04 17:48 ` Brian Norris
2020-11-05 11:37 ` Carl Huang
2020-11-04 23:18 ` Brian Norris
2020-11-04 23:27 ` Brian Norris
2020-11-05 11:30 ` Carl Huang
-- strict thread matches above, loose matches on Subject: below --
2020-09-22 5:36 Carl Huang
2020-09-22 5:47 ` cjhuang
2020-09-22 8:09 ` Kalle Valo
2020-11-04 2:00 ` Brian Norris
2020-11-04 7:32 ` Carl Huang
2020-11-04 17:44 ` Brian Norris
2020-11-05 8:35 ` Kalle Valo
2020-11-05 11:10 ` Carl Huang
2020-11-05 18:25 ` Brian Norris
2020-11-06 10:11 ` Carl Huang
2020-11-05 11:17 ` 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=e5302eb0b20339d3f6544652e4034993@codeaurora.org \
--to=cjhuang@codeaurora.org \
--cc=ath10k@lists.infradead.org \
--cc=briannorris@chromium.org \
--cc=dianders@chromium.org \
--cc=johannes@sipsolutions.net \
--cc=kuabhs@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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).