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;
Sender: kvalo=codeaurora.org@mg.codeaurora.org
DMARC-Filter: OpenDMARC Filter v1.4.1 smtp.codeaurora.org 0AED0C4338F
From:   Kalle Valo <kvalo@codeaurora.org>
To:     Christian Lamparter <chunkeey@gmail.com>
Cc:     linux-wireless@vger.kernel.org, devicetree@vger.kernel.org,
        ath9k-devel@qca.qualcomm.com, Rob Herring <robh+dt@kernel.org>
Subject: Re: [RFC PATCH v1 1/3] dt-bindings:net:wireless:qca,ath9k: add nvmem-cells for calibration data
References: <91e68ca7f65bee7197ed5829ef91bc526df16e8a.1629508039.git.chunkeey@gmail.com>
        <87ilzz9wzf.fsf@tynnyri.adurom.net>
        <cf25eb4a-197d-161a-5902-64830c383746@gmail.com>
Date:   Sun, 22 Aug 2021 08:09:22 +0300
In-Reply-To: <cf25eb4a-197d-161a-5902-64830c383746@gmail.com> (Christian
        Lamparter's message of "Sat, 21 Aug 2021 22:02:57 +0200")
Message-ID: <8735r2rrp9.fsf@codeaurora.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

Christian Lamparter <chunkeey@gmail.com> writes:

> On 21/08/2021 07:40, Kalle Valo wrote:
>> Christian Lamparter <chunkeey@gmail.com> writes:
>>
>>> On most embedded ath9k devices (like range extenders,
>>> routers, accesspoints, ...) the calibration data for
>>> the RF/PHY is simply stored in a MTD partition named
>>> "ART", "caldata"/"calibration", etc.
>>>
>>> Any mtd partition is automatically registered in the
>>> nvmem subsystem. This makes is possible to fetch the
>>> necessary calibration directly from there at the low
>>> cost of adding nvmem cell information via the
>>> device-tree or via similar means.
>>>
>>> This speeds up the driver's initialization a lot,
>>> because the driver doesn't have to wait for userspace
>>> to provide the data via helpers.
>>>
>>> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
>>
>> The series looks good to me. But I'm curious, why you marked this as
>> RFC? Is there something controversial I missed?
>
> yeah. Last night (it was already really late) I was tunnel-visioning
> at the thought that device-tree binding update was a must there.
> ... And ath9k's qca,ath9k.txt is still in that .txt and not .yaml
> format. So, I'm not sure if that file has to be converted first.
> (I couldn't get Rob's tools to work. And without them, I've no idea
> what error messages a converted .yaml of it will pop up)
>
> However... since then, I had the change to re-read:
> <https://www.kernel.org/doc/Documentation/nvmem/nvmem.txt>
>
> And found that nvmem cells and lookups can be specified in
> the old platform data way as well... So that binding patch
> 1/3 is optional.
>
> So, yeah. If nobody has an comment until next week, I'll post this
> series with only patches 2/3 and 3/3.

Sounds good, thanks for the background.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches