Christian Lamparter <chunkeey@xxxxxxxxx> writes: > On 28/10/2021 10:58, Kalle Valo wrote: >> Christian Lamparter <chunkeey@xxxxxxxxx> 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@xxxxxxxxx> >>> Cc: Thibaut VARÈNE <hacks@xxxxxxxxxxxxx> >>> Signed-off-by: Christian Lamparter <chunkeey@xxxxxxxxx> >>> --- >>> >>> 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. > 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? -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
