PS Upstream doesn't have any Cold work pending that I can see. There's no issue with D3 cold and no pull request for it I could find.

Also, we'll likely want to split this up since it looks like several different changes combined. Though we can split once we're happy with the changes if you have them all combined at the moment.

Also, we'll likely want to split this up since it looks like several different changes combined. Though we can split once we're happy with the changes if you have them all combined at the moment.

Ah n/m on cull question

When to cull gcc-12?

Looks good to me, and matches the other riscv64 targets

This looks good. Mark is right about tests, but that's largely orthogonal now that you added a test for this issue.

Ok. Those are good reasons.

I'd like to urge a little caution with the formatting changes. If they are from the porting, do it. If they are leftovers from run, but still in OpenBSD, I'd suggest fixing those with a round trip through upstream. If upstream is unresponsive, I'd be tempted to do them as a followup commit so future imports would be easier. We have some good docs in the git history about why there appear to be gratuitous diffs with upstream. These would be hard to capture in the initial commit message.

So I like this in general. And the few places that I checked the old/new code does the right thing as far as I Can tell by looking at it statically. I didn't audit everything though.
But that's likely OK if this passes whatever test-suite we have, imho.

There's two sources for what's in the manual. One is the actual man pages, the other is the index. Here they disagree. The index says:

Seems legit and sane.

Same a Kyle. Don't want to get in the way, but i have ideas on path driven default type

In D48067#1099602, @adrian wrote:

In D48067#1098399, @bz wrote:

Honestly though, I think having the wifi firmware version and some basic NIC information available even without bootverbose would be good.

Right but then DPRINTF seems to be the wrong thing to use for printing the extra information.

*nod* I don't mind turning this into "just print the firmware info always" with the filename too, what do you think?

We need to enhance firmware(9) to allow drivers to request a load yhen get a callback later in boot.

Where would it be reused?

In D48067#1098384, @adrian wrote:

In D48067#1097443, @bz wrote:

Given this is a RTWN_DPRINTF I don't see how that will help any reports.
But if you boot -v (bootverbose) you'll get reports like:

firmware: 'rtwn-rtl8821aufw' version 111: 27804 bytes loaded at 0xffffffff83878000

Is that helpful? Maybe we should add a if (bootverbose) to print this information like other drivers do?

Ah, yes. So, the firmware gets loaded when the NIC is brought up, so you CAN set a debug flag before you start wifi.

Honestly though, I think having the wifi firmware version and some basic NIC information available even without bootverbose would be good. bootverbose gets VERY verbose for the whole boot, and stuff like the PCI enumeration, audio mux setup, etc quickly swamps everything else.

I wonder if other SDHCI front ends need this?
Regardless, it certainly can't hurt.

IEEE Std 1003.1TM-2024 (aka POSIX.1-2024) says:

The close ( ) and posix_close ( ) functions shall fail if:
[EBADF] The fildes argument is not a open file descriptor.
[EINPROGRESS] The function was interrupted by a signal and fildes was closed but the close operation is continuing asynchronously.
The close ( ) and posix_close ( ) functions may fail if:
[EINTR] The function was interrupted by a signal, POSIX_CLOSE_RESTART is defined as non-zero, and (in the case of posix_close()) the flag argument included POSIX_CLOSE_RESTART, in which case fildes is still open.
[EIO] An I/O error occurred while reading from or writing to the file system.

That's all the standard requires.

My suggestions likely are out of scope, though...

I'll add, though, that there's no shar format. In the early days of net-news/usenet, there
were a dozen or so shar producing things that produced a crazy variety of encodings to
survive the slings and arrows of 1980s dialup internet that wasn't 8-bit or even 7-bit
friendly at times (though UUCP used for news transport coped well, many mailing lists
and mailers were more picky).

Do we need to update arch(7)?

This seems like a rare time we ahould also put 8t in UPDATING.

Yes. Good change. I've shot my foot off this way