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)

I've pushed an update and fiddled with the diff stack a bunch. This works fine on -HEAD from this week on a RPI4 (yes I verified by playing Miley Cyrus for a good couple of hours.)

Updates after refactoring work and testing it on a recent -HEAD on a RPI4.

In D53104#1217970, @zlei wrote:

So typically a queue is bound to one core, then we have better cache localization for the same flow ? That sounds a good idea.

ok, so this looks fine, but I'm trying to remember where I used to assign the flowid/flowtype for a connection back in the day. On the mbuf side it used to be done in the driver side and then overriden by the network stack input path if it didn't match what was required (eg the magic required in ip reassembly, which is still there, but also to support completely software flow hashing.)

rebase

• don't attach unless it's the devices I'm working on
• explicitly name things as clause 22 calls
• only allow clause 22 calls on clause 22 supported chipsets

Yup, most multiqueue NICs now just "do" RSS natively whether we want it or not, and the main difference here with RSS defined was whether the configured key or a random key was used, etc.

In D36431#844206, @andrew wrote:

[ref:dsb]: https://github.com/raspberrypi/linux/commit/35b7ebda57affcfd3616d39d5a727a4495b31123
[ref:sems]: https://github.com/raspberrypi/linux/commit/24a4262afb10907fce3cdbc3ae336fcf4cdaece5
[ref:sizes]: https://github.com/raspberrypi/linux/commit/e64568b8ea6c04e747e432c17ce2452652075216
[ref:sizes2]: https://github.com/raspberrypi/linux/commit/f9bee6dd24addfa00c2c8d50c25b73efbfbb28ba
[ref:deadcode]: https://github.com/raspberrypi/linux/commit/14f4d72fb799a9b3170a45ab80d4a3ddad541960
[ref:sync]: https://github.com/raspberrypi/linux/commit/51c071265079319583e4c6e8c61e09660300d0bf
[ref:longbulk]: https://github.com/raspberrypi/linux/commit/37f6f19a83722c9b866cecb5e455b2e16e5bbc6b

Did you just apply these changes, or reimplement them? The license on at least some of the files has changed there so we can't just use the changes directly.

yo, any reason why we can't land this now in -HEAD?

i hit this on the latest rpi4 snapshot build, which has this bug and it prevents rc.d/growfs from working.

ok, I'd like to land this and then follow it up with some more iwx cleanups. Thanks for pointing them out though, I'm not shocked that the original upstream code was messy with key management too. ;-)

update from bz