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

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

Replace splhigh() with critical_enter()/leave() to ensure we write the

2013-02-21T00:27:51Z

config mode unlock sequence quickly enough. This likely isn't too critical, since splhigh() has been a noop for a decade...

No longer need splhigh() since locking was done, delete it and

2013-02-21T00:26:31Z

comments about it.

Rename device_delete_all_children() into device_delete_children().

2011-11-22T21:56:55Z

Suggested by: jhb @ and marius @ MFC after: 1 week

Move the device_delete_all_children() function from usb_util.c

2011-11-19T10:11:50Z

to kern/subr_bus.c. Simplify this function so that it no longer depends on malloc() to execute. Identify a few other places where it makes sense to use device_delete_all_children(). MFC after: 1 week

- Add support for MosChip 9865 Single 1284 Printer port

2011-02-19T17:38:51Z

PR: kern/152663 Submitted by: Jonathan Chen Approved by: rwatson (mentor)