<nbd>
neocturne: i think in general an even better solution would be if you don't have to interact with the phy at all and instead are able to pull all the required information from board.json
<neocturne>
Seems like it would require a lot of information in board.json, for example we need each radio's supported channel list
<nbd>
if you make a list of information that you need, i can extend board.json
<neocturne>
Hmm okay, I can look into that, thanks
<nbd>
it would also make it easier for you to deal with mt7996 and other wifi7 devices
<nbd>
since those show up as a single phy with multiple radios
<nbd>
which end up being configured by separate wifi-device sections
<neocturne>
Interesting
<neocturne>
Optimally, we'd have all information libiwinfo supports available in some form. Currently we're using hwmodelist, htmodelist, freqlist, txpwrlist and txpower_offset... as well as looking for the flag MFP_CAPABLE directly in debugfs hwflags
<nbd>
do you still care about devices that don't have MFP support?
<nbd>
board.json already has htmodes and bands
<nbd>
i'd have to add the list of channels
<nbd>
per band
n3ph has quit [Quit: WeeChat 4.5.2]
<neocturne>
I don't have any numbers, but there are a lot of older devices running Gluon (basically everything that OpenWrt can still fit on), so I assume there's going to be a few devices without MFP in our support list
n3ph has joined #openwrt-devel
<nbd>
i have another idea that is conceptually simpler and solves other issues at the same time
<nbd>
netifd should keep track of an available state for wifi-devices (default to false). when the system boots, the hotplug script (and a loop after kmodloader) handles the rename, then sets the available flag in netifd
<nbd>
so even during hotplug after the boot script, netifd setup is guaranteed to be run after the rename
<nbd>
that way you can keep your script logic as-is
<nbd>
and netifd wireless setup doesn't race aaginst hotplug rename
<neocturne>
Oh, that sounds nice. I think udev works similarly, with new devices only being reported to users after the rules have completed?
<nbd>
netifd does the same for network devices/interfaces
rua has quit [Quit: Leaving.]
<nbd>
just not for wireless phys yet
<nbd>
hm, that's also a bit tricky, because it would have to be file based
<nbd>
since netifd isn't up yet at the time the boot scripts run
rua has joined #openwrt-devel
<nbd>
another idea would be to move the rename logic to a separate script
<nbd>
and call that script from the boot script after kmodloader
<nbd>
so you get a rename for all devices that were probed immediately
<nbd>
if you have some gluon specific logic to wait for a bit longer during uci-defaults, you could simply call that script again
<nbd>
as long as you don't do it from hotplug
<nbd>
that way it wouldn't race against netifd setup
<neocturne>
Hmm okay, probably good enough. Although moving more of Gluon's wireless setup to hotplug eventually is also something I have been thinking about, to get rid of the additional delay (or depending on timing there at all) - I think the default UCI sections are also generated in hotplug?