Brian Norris <briannorris@xxxxxxxxxxxx> writes: > + ath10k > > [ I realize I replied to the "wrong" RFC v1; I fell trap to Kalle's note: > > "When you submit a new version mark it as "v2". Otherwise people don't > know what's the latest version." ] > > On Tue, Nov 3, 2020 at 11:32 PM Carl Huang <cjhuang@xxxxxxxxxxxxxx> wrote: >> On 2020-11-04 10:00, Brian Norris wrote: >> > 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? > ... >> For a given chip(at least a QCOM chip), we don't see that the >> range will grow or change. > > That's good to know. But that's not quite the same as an ABI guarantee. I'm not sure if I understood Brian's question correctly, but I have concerns on the assumption that frequency ranges never change. For example, in ath10k we have a patch[1] under discussion which adds more channels and in ath11k we added 6 GHz band after initial ath11k support landed. And I would not be surprised if in some boards/platforms a certain band is disabled due to cotting costs (no antenna etc). My preference is to have a robust interface which would be designed to handle these kind of changes. [1] [PATCH] ath10k: enable advertising support for channels 32, 68 and 98 -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
