On Thu, 5 Jan 2023 at 19:47, Brian Norris <[email protected]> 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 > [email protected] > https://lists.openwrt.org/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
