Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <3a8840ea-1499-950b-fb44-7546a32c586f@gmail.com>
Date:   Thu, 28 Oct 2021 13:31:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.2.1
Subject: Re: [PATCH v2] ath10k: fetch (pre-)calibration data via nvmem
 subsystem
Content-Language: en-US
To:     Kalle Valo <kvalo@codeaurora.org>
Cc:     linux-wireless@vger.kernel.org, ath10k@lists.infradead.org,
        Ansuel Smith <ansuelsmth@gmail.com>
References: <20211016234609.1568317-1-chunkeey@gmail.com>
 <87ee855xwa.fsf@codeaurora.org>
From:   Christian Lamparter <chunkeey@gmail.com>
In-Reply-To: <87ee855xwa.fsf@codeaurora.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 28/10/2021 10:58, Kalle Valo wrote:
> Christian Lamparter <chunkeey@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@gmail.com>
>> Cc: Thibaut VARÈNE <hacks@slashdirt.org>
>> Signed-off-by: Christian Lamparter <chunkeey@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