Applied more changes

Address more review comments

Address review comments.

Update to mark the requested changes done.

Address review comments using markup for man pages.

Thank you!
Can we also adjust the comment above MPASS() in the header file?

In D44328#1011038, @adrian wrote:

oh, you have a jupiter card with eeprom, rather than just OTP? ooer. Good catch! I likely only have OTP AR9462s :(

In D44219#1008810, @kib wrote:

Otherwise looks good to me.

In D44020#1009470, @pldrouin_gmail.com wrote:

In D44020#1009469, @bz wrote:

This may not be based on your latest version but the general idea is: call i2c_update_div_val() before taking the lock, get the div_reg value back (maybe you can avoid passing it as pointer and checking for error by simply checking for sc->freq == UINT32_MAX in the caller (reset function) afterwards to see if you should change anything or not (just came to my mind, haven't checked all code paths). Then do the register writes all together under lock.

My assumption here is that it is the reset function is not called twice at the same time in parallel from the bus.

What you describe is what I do in the latest version, but it does not work, since without the lock, i2c_get_div_val gets executed before the attach function has the chance to set the variables that are used by i2c_get_div_val. So I need to delay the call to i2c_get_div_val until the attach function completes. Without that I end up with the wrong divider value. Note that this problem seems to only occur at boot time and not if I load the driver as a module after booting.

This may not be based on your latest version but the general idea is: call i2c_update_div_val() before taking the lock, get the div_reg value back (maybe you can avoid passing it as pointer and checking for error by simply checking for sc->freq == UINT32_MAX in the caller (reset function) afterwards to see if you should change anything or not (just came to my mind, haven't checked all code paths). Then do the register writes all together under lock.

In D44020#1009368, @pldrouin_gmail.com wrote:

Ok I think I know how this could be fixed. I should create a sc->initialized_freq flag which is set by the attach function once sc->freq has been set. The reset function should check the status of this flag after locking sc->mutex, and if it is not the case, it should cv_wait for a condition from attach. The attach function should cv_signal this condition after setting the flag. Does it look like the best strategy to you?

We'll need to adjust that slightly in a different direction ...
@manu can you lend a hand? Probably a lot easier for you than for me.

In D43634#1008394, @adrian wrote:

Aha i remember now. Ok, so.

ath10k does HW decrypt AND strips the MIC/IV on successful decrypts. So I wasn't seeing that ccmp_decrypt() path being called.

Checking for IEEE80211_RX_F_DECRYPTED too is likely fine.

Thing is, why's IEEE80211_KEY_SWDECRYPT set if the HW is doing decrypt? You shouldn't have that set if the HW is doing decrypt and you've programmed keys into the HW at this point?

Initially I thought we should name some better but the original structs have the same names so all good.
I have not checked if you got all the places but it looks good.

Great catch! I wonder what else that will help for the other (unconnected) drivers. Thanks!

Here's a second one showing the NONEXIST problem with older firmware https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277432
I think it would be good to sort that before moving people from iwm to iwlwifi by default -- or at least being prepared to handle the fallout.

In D43634#1007529, @adrian wrote:

err, lemme double check this first. SWDECRYPT is not related to hardware encryption offload; it's an earlier thing where you could have RX STA keys in the hardware (to accelerate knowing which STA it belongs to) but it still passes it through untouched requiring one to do encrypt/decrypt in software.

For the ath NICs, the keycache served both as a encryption/decryption key cache and also as a way of marking known STAs in hardware for doing things like auto-ACK, block-ACK tracking, hardware antenna diversity in the older NICs, etc. It doesn't /have/ to contain encryption keys - that's why SWDECRYPT is a thing.

Is IEEE80211_KEY_SWDECRYPT being set somewhere in the linux kpi layer?

Another thing (apart from man pages) we should probably make sure works out of the box is suspend/resume as that's the other missing bit (and ideally without workarounds). I need to go back and see if @hrs has some USB-DEBUG serial console code (I think he gave a presentation about it a while ago at Euro? but I lost track) and assume he doesn't have any time currently.

Thank you for all the changes. I think we are getting pretty close to getting this in.

WOW. Having looked at that logic probably a year ago this is good work; also good catches on the missing unlock and NOACK for the 1 byte!

Sorry this looks a lot but is mostly just white space.

I just skimmed them:

One comment: I tested this on a LS1088 in FDT mode and it makes me super happy as I can scan bits (and flawlessly read) now I had problems with on another board (which I should test as well once I can again).

In D44009#1004004, @imp wrote:

The change itself looks great.

There's other pca954x parts:

..

Seems like it would be easy to add them while you're in the neighborhood? Again, not a request, per se, but if you had a minute...

In D43994#1003687, @emaste wrote:

I'm now running with this change on my daily driver, which has:

Feb 20 15:53:33 nazar kernel: iwlwifi0: Detected Intel(R) Wireless-AC 9560 160MHz, REV=0x312

In D43746#999338, @pldrouin_gmail.com wrote:

Merging the code with the existing driver in D43811. This differential is now obsolete.

Have you tested on a pre-22000 card 8xxx/9xxx recently?
I know we have to 2 PRs (well one now, two people) on those and given they use different interfaces within iwlwifi it's possible they do behave different.

Really looking forward to this. Also a step towards getting SFP+ support going..

@lwhsu I'll just pick the first review given they all live in a window here; last time I checked and asked if they were ready for review I was told to hold off for further changes? Have they been addressed, as in, is the stack of wtap changes ready for review?

In D43968#1003463, @cc wrote:

Initial test shows this error when I changed the channel number in AP. Looks like a reproduce of PR 277100 without LKPI_80211_HW_CRYPTO enabled, or a separate issue?