On 2020-11-04 10:00, Brian Norris wrote:
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.
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
