> > 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@xxxxxxxxx/ > >>> https://patchwork.kernel.org/project/linux-wireless/patch/20200927192515.86-2-ansuelsmth@xxxxxxxxx/ > >> > >> 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?
