<f00b4r0>
schmars[m]: out of curiosity did you get a chance to test nbd's mt7915 workaround?
Borromini has quit [Quit: leaving]
<schmars[m]>
fighting with quilt right now :) got back on friday and took it easy yesterday hehe
n3ph_ has quit [Ping timeout: 480 seconds]
skynet2 has joined #openwrt-devel
<schmars[m]>
btw why/when did we change to building all kernels for all devices into the imagebuilder?
<schmars[m]>
it's a little impractical for the bigger targets
<colo>
how/why/by what is /etc/hotplug.d/firmware/11-ath10k-caldata executed on platforms that require and execute it?
<robimarko>
Its triggered by hotplug events when kernel request firmware loading
<robimarko>
schmars[m]: Its been some time since Ansuel added support for building initramfs per device
<robimarko>
So it actually respects DEVICE_PACKAGES
<schmars[m]>
ah the per device stuff, i remember
<schmars[m]>
right that makes sense. i wonder if we could generate that stuff on the fly within the imagebuilder. some tarballs got really really really big :)
<colo>
robimarko: great, that means I should be able to re-use that existing mechanism to implement intel GFX firmware loading (which is required for enabling powersaving on recent-ish Intel iGPUs), I think
<schmars[m]>
but on the other hand it's just simply big targets
<schmars[m]>
anyway, flashing that mt7915 pcie hack now
<colo>
robimarko: do you happen to know which userspace component in OpenWrt is responsible for actually transacting that (sysfs-based, I take it) firmware loading fallback mechanism?
<colo>
(I'd love to read its source to see what specific interface I need to implement in the script I am going to cook up)
<robimarko>
colo: Yes, you can use the same mechanim to load whatever
<robimarko>
I am not sure where the helper is that will spawn the hotplug event
<colo>
robimarko: do you happen to know if this can also work if/when the firmware request is triggered very early during bootup? (before / is mounted/available)
<robimarko>
colo: no, you cannot load FW from rootfs if its not yet mounted
<\x>
whats this new wpa3 akm 00-0F-AC:24
<robimarko>
This is usually dealt with by moving whatever kernel driver that is built-in requires FW
<robimarko>
To a kernel module, so once its loaded rootfs is already there as well
<colo>
robimarko: I know :) that's what i915 tries, and fails to do. but the interface/spec that /etc/hotplug.d/firmware/11-ath10k-caldata uses would also work for i915
<robimarko>
Yes, its universal
<colo>
yeah, I am aware of that workaround, but I am not sure if it is applicable to i915
<robimarko>
If its tristate and can be built as a module instead then its possible
<colo>
(I think to remember having read that you need to make i915 built-in to have all its console-enhancing features enabled)
<colo>
I will see ifthat is indeed true
<colo>
thanks for noticing my plea for help, robimarko :)
<schmars[m]>
f00b4r0: patch applied to my crashy devices, also checked that /proc/bus/pci/devices looks good
<schmars[m]>
oh but i should remove the daily reboot
minimal has joined #openwrt-devel
<aparcar[m]>
efahl: hello
<aparcar[m]>
do you plan to write docs on how to run a sysupgrade server?
<aparcar[m]>
if not, I'll try to work on it
<efahl>
Sure, I've been collecting my notes and was going to work through that recent issue.
<efahl>
Does the actual production server have any hacks to the podman-compose.yml or .env? Because it seems like the mounts for the shared volumes in the github stuff can't work as-is.
<Stat_headcrabbed>
Hello, we might need someone else to take over odhcp6c's maintenance. The original maintainer haven't done anything on it for over 1 year and there are some issue/prs that have been existed for a long time
<f00b4r0>
schmars[m]: let's see if it holds out. My test location has been up for a week now, but it can last a while before crashing so I'm not calling victory yet