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

Brian Norris computersforpeace at gmail.com
Wed Jan 4 18:54:00 PST 2023

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:

And unfortunately, systems I'm looking at were only programmed with the
base64 VPD:

    # ls -1 /sys/firmware/vpd/ro/wifi*

> 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:


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

Without a user space API, this is the best I came up with.


More information about the openwrt-devel mailing list