• address manpage nits, from ziaee

I mean look it's 2025 and the machines that we're going to run these devices on have a huge amount of ram compared to the 90s. linux has always had the notion of low, high, very high, etc pools for allocators and their device drivers in various malloc/etc incantations end up using those behaviours implicitly. They have slowly churned on malloc flags, dev based allocations, etc to make this less error-prone but it's still not guaranteed.

• copyright updates (adrian, bz)

• manpage fixes (ziaee)

• remove opt_platform.h (bz)
• update locking (adrian)
• clean up busdma stuff (adrian)

add missing bit

I'm ok with for now just enabling all symbol exports to unblock things and then figure out how to clean things up in post.

all good plz land tyvm

looks good. manpage? :)

.. and since this is just effectively a table of { id, string } and you want to use it in other places, we can later just turn it into a table.

i'm ok with this; i would be putting it in a separate .c file instead because I dislike lots of code use like this in header files, bt that's just me. :-)

looks good to me but the lack of mutexes anywhere is suspicious. ;-)

more cleanups, inspired by bz's poking at this whole rssi/nf/signal strength cleanup.

In D53813#1229884, @michaelo wrote:

Isn't it better not to have a driver at all rather than having one which is six years old, a preview and heck knows working at all reasonably?

I think it's fine to land and clean up. It's a linux sourced driver with a HAL, debug and trace layer that we need to clean up and then they've written the iflib bits. So like, if it works for people, let's land it and clean it up in post.

absolutely amazing use of macros and included source files i love it

looks good, maybe get a review from @ziaee too for manpage stuff and then land?

nono i mean the places in the diff where #ifdef IWX_DEBUG instead of using IWX_DPRINTF(), and an IWX_DPRINTF_CHECK() macro ...

I don't mind either; in fact the above diffs just remind me i need to finish cleaning up the iwx debug printing so this stuff doesn't require #ifdef IWX_DEBUG everywhere. :-)

If you're worried about the ioctl change then let's do everything except the ioctl changes to begin with, and go fix all the divers and churn net80211's stuff a whole bunch first.

In D50929#1228066, @bz wrote:

In D50929#1228064, @adrian wrote:

hm, i wonder why iwx used -107 as its "nothing present" value. I wonder what iwlwifi is doing too.

like, -107dBm is a very low thermal noise floor; that's like for a 5MHz wide channel. (The noise floor gets higher as the channel width increases.)
But it's a damn sight better than -127dBm. :-)

There is none. You get a signal value. All the values we ever used in iwm/... are arbitrary. I think normally we used to us -96.

also in my poking I found that I'm not seeing any empty airtime RSSI (it's always 0) so it was setting sc->sc_noise to -127. so we still need to clamp that too to a default noise floor.

hm, i wonder why iwx used -107 as its "nothing present" value. I wonder what iwlwifi is doing too.

@bz here's another great example of "almost but not quite what net80211 "expects" " ;-) sigh.. :)

comments from bz

more "correct" fixes, i hope!

Hi @gallatin would you mind helping me eyeball what the cacheline size / offset implications would be for extending the per-CPU ACPI stuff like this? Thanks!

rebase; reindent some stuff

rebase

rebase

rename macros, cleanup

• update now that some of the work has been moved into D53372
• some style(9) cleanup

Break out some more of the debug changes into this file

(sigh how'd I convince it that /i/ approved it)