Christian Lamparter <chunkeey@xxxxxxxxx> writes: > 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. Ok, I took the v2 now. Thanks for helping out, I appreciate it! -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
