[RFC 1/2] nl80211: add common API to configure SAR power limitations.

[Brian Norris]

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.

Brian