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;
MIME-Version: 1.0
References: <20211016234609.1568317-1-chunkeey@gmail.com> <87ee855xwa.fsf@codeaurora.org>
 <3a8840ea-1499-950b-fb44-7546a32c586f@gmail.com>
In-Reply-To: <3a8840ea-1499-950b-fb44-7546a32c586f@gmail.com>
From:   Ansuel Smith <ansuelsmth@gmail.com>
Date:   Thu, 28 Oct 2021 13:39:59 +0200
Message-ID: <CA+_ehUwi45irFZCadx-XRnW_+jJac7wWcPJ2756K8xjFsDx4Ow@mail.gmail.com>
Subject: Re: [PATCH v2] ath10k: fetch (pre-)calibration data via nvmem subsystem
To:     Christian Lamparter <chunkeey@gmail.com>
Cc:     Kalle Valo <kvalo@codeaurora.org>, linux-wireless@vger.kernel.org,
        ath10k@lists.infradead.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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=C3=88NE <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/2020092719251=
5.86-1-ansuelsmth@gmail.com/
> > https://patchwork.kernel.org/project/linux-wireless/patch/2020092719251=
5.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-Value=
s
> 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 =3D=3D -EPROBER_DEFER)
>         return ret;
>

The 2 patch has to change to use the nvmem api.
The mtd one is present in ath10k-ct and looks to work well on my devices.
At times I also tested one implementation that used nvmem api to fetch cal
data from nvmem using a specific nvmem cell name passed in the dts and it
did work just right.
Also with recent changes to nvmem api the of_platform_device_create and the
pdev check are not needed anymore are the nvmem can find cell also if the
platform is not registered

> > https://patchwork.kernel.org/project/linux-wireless/patch/2020091818110=
4.98-1-ansuelsmth@gmail.com/
> > https://patchwork.kernel.org/project/linux-wireless/patch/2020091818110=
4.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 no=
t
>  > 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