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> <875yth5pt3.fsf@codeaurora.org>
 <3aebb711-dc45-3cbf-43cb-12f59909baf0@gmail.com>
In-Reply-To: <3aebb711-dc45-3cbf-43cb-12f59909baf0@gmail.com>
From:   Ansuel Smith <ansuelsmth@gmail.com>
Date:   Thu, 28 Oct 2021 20:57:45 +0200
Message-ID: <CA+_ehUxFDUE6BU3TbngKOA-VKCBkTnpOv7ibTjtpur37KrQ4Jw@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"
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.
>

A refreshed patch is applied to atk10k-ct repo so it would be good to
have the same patch on normal ath10k. Many router would benefit
from that.

> (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

About this I never manage to understand the priority... Should ACPI
variant have priority and fallback to the OF api or the OF api should
overwrite any mac if a nvmem cell is found?