In D43879#1001132, @emaste wrote:

How chatty is LINUXKPI_DEBUG_80211 in general? I currently do not have it enabled in my WIP tree but will turn it on for this change.

Can we please NOT do this. I explained it in my other review (D43658) twice by now.

Please fix the title and the commit message. Also if you bring in those then what about all the others? All this should be loadable. The question which may arise is whether ATH_ENABLE_11N should be in ATH_CFLAGS these days?

If I understand correctly, these defines are from the Table 8-130—HT Operation element fields and subfields (continued) on page 615. I quoted them below. I think it's better to use cleaner names for these defines in sys/net80211/ieee80211.h and use an indent similar to the Linux version.

There's a lot to be said about the "native" net80211 version. But that's not part of this review request. I tend to not change the old stuff there if it is used (VHT is not used yet, so that's why there is cleanup going on there still). Simply MFCing it could be a pain without leaving compat defines. In this case it seems only iwn(4) would be affected so we could argue we can but I haven't checked all the other related fields and that's where the real pain comes in.

I think a separate patch "just rename these defines in sys/net80211/ieee80211.h" shall be OK, and can MFC, because their corresponding values are correct. If you agree, I can submit a patch for review.

In D43658#996222, @cc wrote:

This patch also fixes the wrong/old values used in sys/compat/linuxkpi/common/include/linux/ieee80211.h. thanks

(Sorry if some comments are confusing; I lost track of the state of the latest implementation)

Also, can we please have a man page?

The remainder I'll leave to @manu and @wulf . I don't know enough of the implications.

Ok, Probably too tired last night. I'll keep updating this... Watch this space.

cmd was gone, replace with defined values.

I cannot actually request changes on my own review. Sad.

In D43647#995353, @cc wrote:

I see two "MFC after" in the summary section, and the summary section seems to contain two parts that it looks you are going to split this patch into two when you MFC it. Am I understanding correctly? Are you going to manually MFC the two parts?

Fix CFLAGS spelling

Maybe it's plain files?

I cannot get this stable even with mmc(4) GENERIC (no MMCCAM).
Starts to make me wonder if the clocks are right ... but I cross-checked those again to the LS1088ARM.pdf (still not updated).

As another note:

• removing the last quirk seems to make not change at hs200
• With either I still cannot get it stable on a 2nd board; create a GPT scheme; reboot and have MBR; sometimes I/O errors, sometime CORRUPT GPT on the disk-XXXXX but not on the sdda0. Not sure as to how-much this is sdhci_fsl or MMCCAM at this point but I'll keep looking.

In D43461#991392, @manu wrote:

What does it do if you don't use SDHCI_FSL_TUNING_ERRATUM_TYPE2 ?

In D43389#989053, @cc wrote:

I think this patch as a fix is targeting 271979#c28. If I am right, I will use the reproduce method to test this patch. thanks

Also referencing this 274382#c3 for the "panic: lkpi_sta_auth_to_scan", although I initially mis-placed the report in this PR.

I've head a slightly more elaborate version of this from @jhb since 2019.
I'l add @jhb to Cc:
Also I'll try to upload the diff as an attachment so you can have a look.

LGTM

Given the bucket is locked this should be fine.

I believe all suggested changes went in with diff from @olce and the last update

Insert "them" as submitted by @olce

In D42345#983608, @olce wrote:

In D42345#983201, @bz wrote:

@olce congrats on the commit bit. Is this version (mostly yours now) okay?

Thanks! I'm still struggling from the amount of received mail, so your question was lost for a while (I need to better organize myself for the new situation).

Yes, re-reading it, I think this version's OK, barring some minor nit in a comment (which I introduced, sorry).

@cc any further thoughts on this one?

@olce congrats on the commit bit. Is this version (mostly yours now) okay?

How did usbdump() solve this?

Apply the diff as submitted by Olivier Certner.

Check length in ifoccnfig for the Element information and print error/return
if not matching. With that initialize variables later and add the requested
comment from cc@ to explain the +2.

Any comments?

Can we at some point simply get this in (if it is in a state to attach to the build) and make further enhancements in git and have history for these changes rather than trying to polish the rather large review to perfection? I know there is a tradeoff at some point of how much stuff is outstanding...