From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from m42-4.mailgun.net ([69.72.42.4]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kaakV-0003jc-JX for ath10k@lists.infradead.org; Thu, 05 Nov 2020 08:36:08 +0000 From: Kalle Valo Subject: Re: [RFC 1/2] nl80211: add common API to configure SAR power limitations. References: <1600753017-4614-1-git-send-email-cjhuang@codeaurora.org> Date: Thu, 05 Nov 2020 10:35:56 +0200 In-Reply-To: (Brian Norris's message of "Wed, 4 Nov 2020 09:44:55 -0800") Message-ID: <877dr0nqtv.fsf@codeaurora.org> MIME-Version: 1.0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "ath10k" Errors-To: ath10k-bounces+kvalo=adurom.com@lists.infradead.org To: Brian Norris Cc: Carl Huang , linux-wireless , Doug Anderson , ath10k , ath11k@lists.infradead.org, Abhishek Kumar Brian Norris 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 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 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k