[PATCH 7/8] ath10k-ct: Support qcom,ath10k-calibration-data-base64

[Brian Norris]

On Thu, Jan 5, 2023 at 11:02 AM Robert Marko <robimarko at gmail.com> wrote:
> On Thu, 5 Jan 2023 at 19:47, Brian Norris <computersforpeace at gmail.com> wrote:
> > On Wed, Jan 04, 2023 at 01:58:01PM +0100, Christian Marangi wrote:
> > > Also on top of that the besto solution for these special case is to
> > > parse the base64 data in userspace a produce a calibration bin to pass
> > > with sysfs. A patch and some code to decode base64 seems overkill to me.
> >
> > I'd love something that's more pleasant than in-kernel base64. Is there
> > some sysfs method for this that I'm not aware of? The closest I find is:
> >
> >     /sys/kernel/debug/ieee80211/*/ath10k/cal_data
> >
> > But that's read-only, not read-write. And it's not completely obvious to
> > me that this data can be (re)written to the target radio arbitrarily, so
> > I suppose the API would be a bit fiddly -- that one has to know to write
> > this file before ever bringing up the interface (but after loading the
> > driver/module).
> >
> > Without a user space API, this is the best I came up with.
>
> You can extract and provide the caldata from userspace by acting on the hotplug
> event that kernel files after request_firmware() fails, look at what
> Fritzbox devices are doing in:
> https://github.com/openwrt/openwrt/blob/master/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata

Awesome, I had an inkling that other devices would probably have some
similar problems, but I didn't find exactly how they're handling it.

And wow, I didn't realize there was a uevent/sysfs method for filling
in the gaps on missing /lib/firmware files. TIL.

> Basically, you trigger on the requested file and device and then you
> can just use a userspace
> script or binary to actually provide that file.

Yep, this totally looks like it'll work for me. I'll just need to
force a 'base64' utility into these images, but otherwise, looks
pretty easy.

> That would probably work best here as I dont know if upstream will
> accept adding a base64
> method just for one or 2 devices.

Yeah, I figured this is arcane enough (and not really a typical job
for DT bindings) that we'd need to patch up something ourselves. I'm
glad to not have to approach the "convince upstream" question on this
ugly patch, and even more glad to find a way do this without modifying
the kernel/driver.

Thanks a lot,
Brian