In D31955#721084, @ehem_freebsd_m5p.com wrote:

In D31955#720853, @andrew wrote:

This is confusing two mostly independent concepts. One is the firmware type. On arm64 it is almost always UEFI, however it could also boot via the same ABI as a Linux kernel. The other is the hardware description method.

Yes, they are somewhat independent, but they are interrelated and strongly correlate.

Of the spots touched by this they all appear to ask one of two questions:

1. Use OpenFirmware device-tree or ACPI table?
2. Are UEFI runtime services available?

I'm under the impression using device-trees pretty well excludes full UEFI runtime services. The only case where these mix at all is U-Boot's UEFI support, which mostly appears to be good enough for bootloader use and only minimally implement the UEFI spec.
As such this seems to be a spectrum with device-trees on one end and full UEFI the other.

Seems correct.

Rename functions to have a dumpsys_ prefix.

It is possible that this check would be better placed in the sdhci driver itself, where SDHCI_PLATFORM_WILL_HANDLE() is actually called. This is the only driver that implements this method, however.

Drop include of vm_phys.h from vm_dumpset.h. Include it where it is needed instead.

In D31884#719396, @markj wrote:

This is a good cleanup. I don't really like the header pollution. We are already assuming that consumers have included vm_page.h (to check m->flags & PG_NODUMP), so why not vm_phys.h as well? Alternately we could have the implementation live in vm_phys.c and call it vm_phys_is_dumpable() or so.

In D31387#713971, @luporl wrote:

Worked fine on POWER9.
For PowerPC, without these changes the allocation of more programmable counters than available already failed, because of the check for the counter number in allocate. But, as you said, it is always a good idea to validate the PMC class too.

In D31283#714889, @wma wrote:

Any further comments?

Weird, this didn't get auto-closed.

Ping.

Switch to just removing the existing redundant capability checks.

Also give pidhashtbl a specific initial value of NULL. NFC, but semantically correct.

Update with markj's feedback. Keep the allproc initialization bit, as it may be checked early by db_ps().

In D31033#708666, @jrtc27 wrote:

In D31033#708664, @mhorne wrote:

While I did not go over every line in detail, I don't see anything objectionable. The PCIe chapter in the FU740 manual is particularly lacking.

I've lightly tested this series on my board, root on USB and NVMe both appear to be working. My remaining concern is that I see messages about failed PCI resource allocation in the boot log, see P514. Is this expected? The kernel I've tested here is based on your unmatched branch (b96c50e2fad) + one unrelated commit of mine.

Yes, those are harmless, when resetting the controller all the windows change to 4K open windows at a low address (either 0 or 4K, I forget) that FreeBSD initially interprets as being configured by firmware and thus tries to preserve them, but fails to (since they're not within the controller's static address ranges). I'd like to find a way to silence those somehow (clear_pcib exists but for some reason doesn't seem to quite work, enumeration stops after the first bridge), but that'd be a future patch as it's not causing any functional issues.

While I did not go over every line in detail, I don't see anything objectionable. The PCIe chapter in the FU740 manual is particularly lacking.

Forgot to hit accept :)

There is a list of gpio drivers in the gpiobus(4) man page. It is not up to date, but you should add an entry for this driver.

In D31388#707800, @emaste wrote:

Some existing cases returned EPERM for the != caps cases?

Unfortunately, I ran out of steam for this ahead of the release, and the moment has passed.