[PATCH 7/8] ath10k-ct: Support qcom,ath10k-calibration-data-base64
robimarko at gmail.com
Thu Jan 5 11:02:40 PST 2023
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:
> 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.
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:
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.
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
More information about the openwrt-devel