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

[Robert Marko]

On Thu, 5 Jan 2023 at 19:47, Brian Norris <computersforpeace at gmail.com> wrote:
>
> Hi Christian,
>
> On Wed, Jan 04, 2023 at 01:58:01PM +0100, Christian Marangi wrote:
> > On Mon, Jan 02, 2023 at 03:25:33PM -0800, Brian Norris wrote:
> > > See the patch notes about the stock firmware for TP-Link Onhub and
> > > https://chromium-review.googlesource.com/243115.
> > >
> > > As noted there, the production firmware for Google OnHub devices only
> > > provide the *-base64 Device Tree property, and so either the kernel or
> > > some user space mechanism needs to know how to parse/convert this
> > > property.
> ...
> >
> > Aside from this, I notice this is actually NOT used in the 2 device you
> > are proposing. I'm totally missing something or this is not needed at
> > all?
>
> It's provided by the production firmware, which patches it into the
> device tree on its own. So you're not going to find it in the kernel or
> DTS sources.
>
> If you want to look at its source though, it's here:
> https://chromium.googlesource.com/chromiumos/platform/depthcharge/+/refs/heads/firmware-storm-6315.B/src/board/storm/wifi_calibration.c
>
> And unfortunately, systems I'm looking at were only programmed with the
> base64 VPD:
>
>     # ls -1 /sys/firmware/vpd/ro/wifi*
>     /sys/firmware/vpd/ro/wifi_base64_calibration0
>     /sys/firmware/vpd/ro/wifi_base64_calibration1
>     /sys/firmware/vpd/ro/wifi_base64_calibration2
>
> > 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

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.
That would probably work best here as I dont know if upstream will
accept adding a base64
method just for one or 2 devices.

Regards,
Robert
>
> Brian
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel