Revert r330897:

This was intended to be a non-functional change. It wasn't. The commit
message was thus wrong. In addition it broke arm, and merged crypto
related code.

Revert with prejudice.

This revert skips files touched in r316370 since that commit was since
MFCed. This revert also skips files that require $FreeBSD$ property
changes.

Thank you to those who helped me get out of this mess including but not
limited to gonzo, kevans, rgrimes.

Requested by: gjb (re)

MFC r329598:

Add PCI methods to iterate over the PCI capabilities

VirtIO V1 provides configuration in multiple VENDOR capabilities so this
allows all of the configuration to be discovered.

Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D14325

Partial merge of the SPDX changes

These changes are incomplete but are making it difficult
to determine what other changes can/should be merged.

No objections from: pfg

Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle.
Prune svn:mergeinfo from the new branch, as nothing has been merged
here.

Additional commits post-branch will follow.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

sys/dev: minor spelling fixes.

Most affect comments, very few have user-visible effects.

Convert rman to use rman_res_t instead of u_long

Summary:
Migrate to using the semi-opaque type rman_res_t to specify rman resources. For
now, this is still compatible with u_long.

This is step one in migrating rman to use uintmax_t for resources instead of
u_long.

Going forward, this could feasibly be used to specify architecture-specific
definitions of resource ranges, rather than baking a specific integer type into
the API.

This change has been broken out to facilitate MFC'ing drivers back to 10 without
breaking ABI.

Reviewed By: jhb
Sponsored by: Alex Perez/Inertial Computing
Differential Revision: https://reviews.freebsd.org/D5075

Revert previous change. The magical constants can't be changed
(easily) without having to go to other drivers to change the
magical return values. This wouldn't be so bad if there were
proper defines for these constants.

In particular dev/acpica/acpi_pcib_pci.c returns -1000 as the
probe priority and it's expected that this driver gets to
attach over the common PCI bus drivers.

Don't return -10000 as the probe priority. That's lower than what
BUS_PROBE_HOOVER is. Drivers like proto(4), when compiled into the
kernel or preloaded, will render your system useless by virtue of
attaching to your PCI busses.

Return BUS_PROBE_GENERIC instead. It's just the next priority up
from BUS_PROBE_HOOVER. No other meaning has been give to its use.
While BUS_PROBE_DEFAULT seems like a better candidate, it's hard
not to think that there must be some reason why these drivers
return -10000 in the first place.

Differential Revision: D2705

Expand the set of APIs available for locating PCI capabilities:
- pci_find_extcap() is repurposed to be used for fetching PCI-express
extended capabilities (PCIZ_* constants in <dev/pci/pcireg.h>).
- pci_find_htcap() can be used to locate a specific HyperTransport
capability (PCIM_HTCAP_* constants in <dev/pci/pcireg.h>).
- Cache the starting location of the PCI-express capability for PCI-express
devices in PCI device ivars.

Do a sweep of the tree replacing calls to pci_find_extcap() with calls to
pci_find_cap() instead.

Move the hostb driver out of the i386 and amd64 PCI code (where it was
duplicated anyways) and into a single MI driver. Extend the driver a bit
to implement the bus and PCI kobj interfaces such that other drivers can
attach to it and transparently act as if their parent device is the PCI
bus (for the most part).