[RFC 1/2] nl80211: add common API to configure SAR power limitations.
Carl Huang
cjhuang at codeaurora.org
Wed Nov 4 02:32:21 EST 2020
On 2020-11-04 10:00, Brian Norris wrote:
> On Mon, Sep 21, 2020 at 10:37 PM Carl Huang <cjhuang at 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
More information about the ath11k
mailing list