[PATCH v2] ath10k: fetch (pre-)calibration data via nvmem subsystem

[Ansuel Smith]

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