src-test2/sys/dev/ppc, branch release/11.3.0

Revert r330897:

2018-03-29T02:50:57Z

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 r314568 (by emaste):

2018-03-27T18:52:27Z

kern_sig.c: ANSIfy and remove archaic register keyword Sponsored by: The FreeBSD Foundation MFC r318389 (by emaste): Remove register keyword from sys/ and ANSIfy prototypes A long long time ago the register keyword told the compiler to store the corresponding variable in a CPU register, but it is not relevant for any compiler used in the FreeBSD world today. ANSIfy related prototypes while here. Reviewed by: cem, jhb Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D10193

Partial merge of the SPDX changes

2018-03-14T03:19:51Z

These changes are incomplete but are making it difficult to determine what other changes can/should be merged. No objections from: pfg

MFC r322947:

2017-09-03T09:03:29Z

Add PCI Id for MosChip MCS9900.

MFC r313982, r314068:

2017-03-14T02:06:03Z

sys: Replace zero with NULL for pointers. Found with: devel/coccinelle

Use uintmax_t (typedef'd to rman_res_t type) for rman ranges.

2016-03-18T01:28:41Z

On some architectures, u_long isn't large enough for resource definitions. Particularly, powerpc and arm allow 36-bit (or larger) physical addresses, but type `long' is only 32-bit. This extends rman's resources to uintmax_t. With this change, any resource can feasibly be placed anywhere in physical memory (within the constraints of the driver). Why uintmax_t and not something machine dependent, or uint64_t? Though it's possible for uintmax_t to grow, it's highly unlikely it will become 128-bit on 32-bit architectures. 64-bit architectures should have plenty of RAM to absorb the increase on resource sizes if and when this occurs, and the number of resources on memory-constrained systems should be sufficiently small as to not pose a drastic overhead. That being said, uintmax_t was chosen for source clarity. If it's specified as uint64_t, all printf()-like calls would either need casts to uintmax_t, or be littered with PRI*64 macros. Casts to uintmax_t aren't horrible, but it would also bake into the API for resource_list_print_type() either a hidden assumption that entries get cast to uintmax_t for printing, or these calls would need the PRI*64 macros. Since source code is meant to be read more often than written, I chose the clearest path of simply using uintmax_t. Tested on a PowerPC p5020-based board, which places all device resources in 0xfxxxxxxxx, and has 8GB RAM. Regression tested on qemu-system-i386 Regression tested on qemu-system-mips (malta profile) Tested PAE and devinfo on virtualbox (live CD) Special thanks to bz for his testing on ARM. Reviewed By: bz, jhb (previous) Relnotes: Yes Sponsored by: Alex Perez/Inertial Computing Differential Revision: https://reviews.freebsd.org/D4544

Migrate many bus_alloc_resource() calls to bus_alloc_resource_anywhere().

2016-02-27T03:38:01Z

Most calls to bus_alloc_resource() use "anywhere" as the range, with a given count. Migrate these to use the new bus_alloc_resource_anywhere() API. Reviewed by: jhb Differential Revision: https://reviews.freebsd.org/D5370

Convert rman to use rman_res_t instead of u_long

2016-01-27T02:23:54Z

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

Add support for SIIG x1 pci-e single parallel port card (JJ-E01211-S1)

2013-11-09T08:27:55Z

PR: kern/182217 Submitted by: Craig Leres MFC After: 1 week

Fix build.

2013-02-21T12:40:52Z