On Thu, Jan 5, 2023 at 11:02 AM Robert Marko <robima...@gmail.com> wrote: > On Thu, 5 Jan 2023 at 19:47, Brian Norris <computersforpe...@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 _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
