> > 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'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; > The 2 patch has to change to use the nvmem api. The mtd one is present in ath10k-ct and looks to work well on my devices. At times I also tested one implementation that used nvmem api to fetch cal data from nvmem using a specific nvmem cell name passed in the dts and it did work just right. Also with recent changes to nvmem api the of_platform_device_create and the pdev check are not needed anymore are the nvmem can find cell also if the platform is not registered > > https://patchwork.kernel.org/project/linux-wireless/patch/20200918181104.98-1-ansuelsmth@xxxxxxxxx/ > > https://patchwork.kernel.org/project/linux-wireless/patch/20200918181104.98-2-ansuelsmth@xxxxxxxxx/ > > Ansuel's post: https://patchwork.kernel.org/project/linux-wireless/patch/20200918181104.98-2-ansuelsmth@xxxxxxxxx/#23639361 > > You are right about nvmem... Problem is that nvmem for mtd is still not > > supported. I already sent a patch to fix this in the mtd mailing list but > > I'm waiting for review... > > If that will be accepted, I can convert this patch to use nvmem api. > > The nvmem api is there (which makes these two patches obsolete I think). > Granted: The nvmem can't do all the same cases (From what I know, mtd > partitions splitters and mtdparts through commandline is being worked on. > But we always have userspace + firmware_request as a fallback). > > Cheers, > Christian
