[PATCH v2] ath10k: fetch (pre-)calibration data via nvmem subsystem

[Christian Lamparter]

On 28/10/2021 10:58, Kalle Valo wrote:
> Christian Lamparter <chunkeey at gmail.com> writes:
> 
>> ATH10K chips are used it wide range of routers,
>> accesspoints, range extenders, network appliances.
>> On these embedded devices, calibration data is often
>> stored on the main system's flash and was out of reach
>> for the driver.
>>
>> To bridge this gap, ath10k is getting extended to pull
>> the (pre-)calibration data through nvmem subsystem.
>> To do this, a nvmem-cell containing the information can
>> either be specified in the platform data or via device-tree.
>>
>> Tested with:
>>          Netgear EX6150v2 (IPQ4018 - pre-calibration method)
>>          TP-Link Archer C7 v2 (QCA9880v2 - old calibration method)
>>
>> Cc: Robert Marko <robimarko at gmail.com>
>> Cc: Thibaut VARÈNE <hacks at slashdirt.org>
>> Signed-off-by: Christian Lamparter <chunkeey at gmail.com>
>> ---
>>
>> v1 -> v2:
>> 	- use %zu and %u in the format string for size_t
>>            and u32 types (catched by the "kernel test robot").
>> 	- reworded commit message + successfully tested on QCA9880v2
>>
>> I placed the nvmem code in front of the current "file" method
>> (firmware_request). Reason is that this makes it easier for me
>> to test it. If needed it can be moved to a different place.
> 
> Looks good to me. Before I apply this, I want to mention to that I have
> had a long in my deferred queue related two patchsets:


> https://patchwork.kernel.org/project/linux-wireless/patch/20200927192515.86-1-ansuelsmth@gmail.com/
> https://patchwork.kernel.org/project/linux-wireless/patch/20200927192515.86-2-ansuelsmth@gmail.com/
Oh ok, serves me right for not looking thoroughly googling this first.
Alban Bedel and Ansuel's work made this nvmem all possible. And indeed,
the second patch here looks eerie similar.

Do you want to go with his two patches instead? I'll change mine, so it
just consists of the cal_mode for the older QCA9880v2,QCA9887 and
add the -EPROBE_DEFER handling. This -EPROBE_DEFER only ever comes up
with the Meraki gear. This is because Meraki likes putting the MACs-Values
into SoC-connected AT24 eeproms-chips. Everyone else just have them in a
proper FLASH partition. Though, this's usually nothing more than adding
the following line:

if (ret == -EPROBER_DEFER)
	return ret;

> https://patchwork.kernel.org/project/linux-wireless/patch/20200918181104.98-1-ansuelsmth@gmail.com/
> https://patchwork.kernel.org/project/linux-wireless/patch/20200918181104.98-2-ansuelsmth@gmail.com/

Ansuel's post: https://patchwork.kernel.org/project/linux-wireless/patch/20200918181104.98-2-ansuelsmth@gmail.com/#23639361
 > You are right about nvmem... Problem is that nvmem for mtd is still not
 > supported. I already sent a patch to fix this in the mtd mailing list but
 > I'm waiting for review...
 > If that will be accepted, I can convert this patch to use nvmem api.

The nvmem api is there (which makes these two patches obsolete I think).
Granted: The nvmem can't do all the same cases (From what I know, mtd
partitions splitters and mtdparts through commandline is being worked on.
But we always have userspace + firmware_request as a fallback).

Cheers,
Christian