On Mon, Sep 21, 2020 at 10:37 PM Carl Huang <cjhuang@xxxxxxxxxxxxxx> 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
