Thanks a lot for all the patience and improvements. I like the changes of the last iteration!

(also dropped you an email which I had sent to re@) I think but firmware/fwget you covered the FreeBSD Foundation bits.

Likely fine but should make sure that all the different devices/firmware really can do that.

Likely fine. But likely also needs testing with a large variety of devices/firmware.

Staying tuned; please indicate when done.

In D47751#1088951, @adrian wrote:

looking at these, i'm wondering whether the better move is to be doing the channel check inside the helper functions as well. i remember the node channel being .. weirdly sketchy thought. i'll go do some more deep diving on this before it lands.

Seems 656d0e8fa92ad72626808479d0935814425ee78d fixed what is reported back back on channel.

In D35978#1088298, @adrian wrote:

it's not entirely required because net80211 actually does the HT and VHT upgrade for us. I'll go check it first though to make sure it doesn't cause drama!

Adding wireless given @adrian is also working on VHT currently and will need this soon.

How should this proceed?

In D47682#1087921, @wulf wrote:

In D47682#1087414, @bz wrote:

I would love that but @manu or @wulf or someone would have to fix the gpu-firmware bits for this. I noticed yesterday that it's still shipping .ko files.

13-STABLE still sticks to *.ko. We have to wait for 13-EOL

In D47682#1087412, @emaste wrote:

LGTM

Can we simplify this eventually and standardize on only the first case?

Thanks for the review; this was based on an earlier attempt to look at release (April this year?) for firmware and trying to figure out how things are put together.
I'll let it sit until at least RC1 is out in case other changes need to be done to avoid conflicts.

Update comment as pointed out by @emaste.

"cleanup" the PKGCMD bits as requested by @jrtc27 .
I have not tested NO_ROOT again.

Implement --pause with a 5 second delay as suggested by @jrtc27.

Remove the bits about the broken NO_ROOT bit.

In D47666#1086828, @dsl wrote:

I can build a kernel with ACPI_DEBUG without any troubles, but my Honeycomb has to be revived. Could you give it a try @phk @bz ?

The wlanconfig change got committed as 5399052c63a7a3d2f54615d31bfd092ab887a600
and the description was locally removed from the commit message.

Unless releng has any objections I'll commit this around Tue 19.11. afternoon UTC.
I would still hope releng to comment on it before if not at least by accepting or requesting changes.

Unless there'll be any comments I'll commit this around Tue 19.11. afternoon UTC

In D47500#1086528, @adrian wrote:

landed

I don't know what your nice 8 core laptop is but again I am also not sure why it matters. Please write a proper commit message.

Can you please write a normal descriptive commit message.

Do we still want this (and the accompanying bsdinstall change) in 14.2-R or not? As otherwise I'll have to add rtw89 firmware at least there.

In case you know anyone else who could review this please add them!

Can this be simplified to simply check if uc_delay_us is > 0? Otherwise from scrolling through uc_write_delay would be a bool or are we expecting more values?