FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=release%2F11.4.0 2019-05-18T20:43:13Z 2019-05-18T20:43:13Z Brooks Davis brooks@FreeBSD.org 2019-05-18T20:43:13Z urn:sha1:5c4ff96e26644055c7d46066b6e87be347706fab r339703: Deprecate a number of less used 10 and 10/100 Ethernet devices. The current deprecated list is: ae, bm, cs, de, dme, ed, ep, ex, fe, pcn, sf, sn, tl, tx, txp, vx, wb, xe The list as refined as part of FCP-0101. Per the FCP, devices may be removed from the deprecation list if enough users are found or they are converted to iflib. FCP: https://github.com/freebsd/fcp/blob/master/fcp-0101.md r347365: Update dme(4) to reflect that it will not be removed due to FCP-101. dme(4) is the built-in NIC on a couple non-expandable mips platforms and thus should remain. The FCP has been updated to reflect this fact. Discussed with: imp r347703: FCP-101: ae(4) is sufficently popular to be moved to the keep list. r347940: Remove the notice that ae(4) will be removed in FreeBSD 13. MFC requested by: rgrimes Approved by: re (kib) 2018-03-29T02:50:57Z Eitan Adler eadler@FreeBSD.org 2018-03-29T02:50:57Z urn:sha1:4ab2e064d7950be84256d671a7ae93f87cc6aa36 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) 2018-03-14T03:19:51Z Eitan Adler eadler@FreeBSD.org 2018-03-14T03:19:51Z urn:sha1:be5d0b9566b13fdf8cabebb63334cbec12bfc409 These changes are incomplete but are making it difficult to determine what other changes can/should be merged. No objections from: pfg 2017-03-14T02:06:03Z Pedro F. Giffuni pfg@FreeBSD.org 2017-03-14T02:06:03Z urn:sha1:bd0faecc931277934a72772a410ede5663969cdb sys: Replace zero with NULL for pointers. Found with: devel/coccinelle 2016-05-03T03:41:25Z Pedro F. Giffuni pfg@FreeBSD.org 2016-05-03T03:41:25Z urn:sha1:453130d9bfc1c6d68b366dfcb041689d69f81295 Most affect comments, very few have user-visible effects. 2016-04-21T20:30:38Z Pedro F. Giffuni pfg@FreeBSD.org 2016-04-21T20:30:38Z urn:sha1:a380994fff81ff425769164b7422beb260c60f14 Mea culpa. 2016-04-19T23:37:24Z Pedro F. Giffuni pfg@FreeBSD.org 2016-04-19T23:37:24Z urn:sha1:73a1170a8c41cb848f17cc0a8839e9dcee3d126e No functional change, only trivial cases are done in this sweep, Drivers that can get further enhancements will be done independently. Discussed in: freebsd-current 2016-03-18T01:28:41Z Justin Hibbits jhibbits@FreeBSD.org 2016-03-18T01:28:41Z urn:sha1:da1b038af9f9551a0b2f33d312b4eede00aa1542 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 2016-02-27T03:38:01Z Justin Hibbits jhibbits@FreeBSD.org 2016-02-27T03:38:01Z urn:sha1:c47476d7e6801deffc8b3c057d0fbf7d2335a0c2 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 2016-02-19T03:37:56Z Justin Hibbits jhibbits@FreeBSD.org 2016-02-19T03:37:56Z urn:sha1:43cd61606b6bfae52bb09856277751103bfa28fd Since these calls only use default arguments, bus_alloc_resource_any() is the right call. Differential Revision: https://reviews.freebsd.org/D5306