and yes I did test it locally, on shurd's insistance. Thanks!

good catch! @jsm what do you think?

oops, missed a bit

gaivn reported iwm being broken and .. well, now i know why.

In D48317#1113021, @jrtc27 wrote:

Your unwillingness to try and actually understand the problem is your own choice, not mine. Adding a platform-specific quirk to ignore the inability to set something that the specification does not give implementations license to restrict is one thing, but doing it unilaterally for every platform is quite another thing and I wholeheartedly object to just disabling checks that get in the way with our current implementation on your hardware. We could quite easily have a real bug in our driver here, and in doing so we're just ignoring that. I also have absolutely no desire to encounter cache coherency bugs in future because of a change like this which just decides that cache coherency is something that can be ignored and everything will be fine, don't worry about it. I do not know what the implications of picking up a different firmware-chosen value here is and whether FreeBSD can in fact cope with it. Do you?

What you could have instead done is try something like the following patch, as I hinted at on IRC two weeks ago:

diff --git a/sys/arm64/arm64/gic_v3_reg.h b/sys/arm64/arm64/gic_v3_reg.h
index 792b532196a9..bba97fca914e 100644
--- a/sys/arm64/arm64/gic_v3_reg.h
+++ b/sys/arm64/arm64/gic_v3_reg.h
@@ -286,7 +286,8 @@
 #define	GITS_PIDR2_ARCH_GICv4	GICR_PIDR2_ARCH_GICv4
 
 #define	GITS_CTLR		(0x0000)
-#define		GITS_CTLR_EN	(1 << 0)
+#define		GITS_CTLR_EN		(1 << 0)
+#define		GITS_CTLR_QUIESCENT	(1U << 31)
 
 #define	GITS_IIDR		(0x0004)
 #define	 GITS_IIDR_PRODUCT_SHIFT	24
diff --git a/sys/arm64/arm64/gicv3_its.c b/sys/arm64/arm64/gicv3_its.c
index 4b554f2dc30a..f11e97a68a20 100644
--- a/sys/arm64/arm64/gicv3_its.c
+++ b/sys/arm64/arm64/gicv3_its.c
@@ -66,6 +66,7 @@
 #include <arm/arm/gic_common.h>
 #include <arm64/arm64/gic_v3_reg.h>
 #include <arm64/arm64/gic_v3_var.h>
+#include "gic_v3_reg.h"
 
 #ifdef FDT
 #include <dev/ofw/openfirm.h>
@@ -1061,6 +1062,8 @@ gicv3_its_attach(device_t dev)
 		ctlr &= ~GITS_CTLR_EN;
 		gic_its_write_4(sc, GITS_CTLR, ctlr);
 	}
+	while (((ctlr = gic_its_read_4(sc, GITS_CTLR)) & GITS_CTLR_QUIESCENT) == 0)
+		;
 
 	/* Allocate the private tables */
 	err = gicv3_its_table_init(dev, sc);

That may not be the problem, but it is *a* flaw in the driver I found by reading the spec. We would be in a much better place had less time been spent by trying to railroad hacky workarounds into the tree and more time spent on actually investigating the problem to understand what exactly is going on. There is a good chance it is more complicated than "this field cannot be changed to this value". I'm not saying it's not that, but there is nowhere near enough evidence to conclusively state that.

I also note, once again, that Linux does *not* ignore failure to set the cache coherency, and they, like us, probably have good reason for that.

In D48604#1112635, @bz wrote:

In D48604#1111570, @adrian wrote:

updated; now it actually does do _HT and _VHT as separate rates, although both LEGACY and HT set dot11rate. That simplifies everything else.

Thanks a lot for that.

Still being called TXRATE and not just RATE. You do not envision to need the same information to track RX?

updated; now it actually does do _HT and _VHT as separate rates, although both LEGACY and HT set dot11rate. That simplifies everything else.

update, add TXRATE_HT

update, add TXRATE_HT

update, add TXRATE_HT

update, add TXRATE_HT

update, add TXRATE_HT

update, add TXRATE_HT

update, add TXRATE_HT

update, add TXRATE_HT

update, add TXRATE_HT

update, add TXRATE_HT

update, add TXRATE_HT

update, add TXRATE_HT

update, add TXRATE_HT

update, add TXRATE_HT

update, add TXRATE_HT

update, add TXRATE_HT

update, add TXRATE_HT

update, add TXRATE_HT

update, add TXRATE_HT

update, add TXRATE_HT

update, add TXRATE_HT

update, add TXRATE_HT

update, add TXRATE_HT

update, add TXRATE_HT

update, add TXRATE_HT

update, add TXRATE_HT

update, add TXRATE_HT

update, add TXRATE_HT

update, add TXRATE_HT

update, add TXRATE_HT

update, add TXRATE_HT

update, add TXRATE_HT

update, add TXRATE_HT

updated, please re-review!

address comments

fixed, please re-review!

update, fix things from gavin/bz

oops fix typo, thanks tom!

thanks for doing this!

ok, addressed everything but mbit/half mbit variable naming, please re-review!

rebase, address changes

rebase, address changes

rebase, address changes

rebase, address changes

rebase, address changes

rebase, address changes

rebase, address changes

rebase, address changes

rebase, address changes

rebase, address changes

rebase, address changes

rebase, address changes

rebase, address changes

rebase, address changes

rebase, address changes

rebase, address changes

rebase, address changes

rebase, address changes

rebase

rebase

rebase

rebase

rebase

rebase

rebase

rebase

rebase

rebase

rebase

rebase

rebase

rebase

rebase

rebase

rebase

rebase

I know you have some issues, but I reckon we can fix this during the -15 timeframe. I'd rather just have the driver in the tree, get people using it, and then fix whatever weird stuff pops up.

rebase

rebase