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: <3aebb711-dc45-3cbf-43cb-12f59909baf0@gmail.com>
Date:   Thu, 28 Oct 2021 20:50:13 +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>
 <3a8840ea-1499-950b-fb44-7546a32c586f@gmail.com>
 <875yth5pt3.fsf@codeaurora.org>
From:   Christian Lamparter <chunkeey@gmail.com>
In-Reply-To: <875yth5pt3.fsf@codeaurora.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 28/10/2021 13:52, Kalle Valo wrote:

>>>>
>>>> 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 would prefer to take your patch.

Ok.

>> 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;
> 
> So I'll drop this version and wait for v3?

I guess that "waiting for v3" won't be necessary in this case.
If @Ansuel doesn't voice any concerns, you might as well just
apply v2.

The "[1/2] ath10k: Try to get mac-address from dts" patch
will need a respin, so it can apply cleanly.

Is Anyone interested? If not, I can take a shot at it on Saturday.

(There's the tiny question of that device_get_mac_address() which
ath10k currently uses. It looks a lot like of_get_mac_address() too!
but with extra ACPI (through FWNODE-which also includes OF), but
without NVMEM.)

Cheers,
Christian