FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=master 2020-03-20T16:50:19Z 2020-03-20T16:50:19Z Ed Maste emaste@FreeBSD.org 2020-03-20T16:50:19Z urn:sha1:2733d8c96c6fa72beac42174db9f810de5769781 The devices supported by these drivers are obsolete ISA cards, and the sync serial protocols they supported are essentially obsolete too. Sponsored by: The FreeBSD Foundation 2020-03-02T20:14:27Z Ed Maste emaste@FreeBSD.org 2020-03-02T20:14:27Z urn:sha1:2495ef28e9ae2468e4382189b288c850467743c9 These support outdated or obsolete ISA WAN (T1/E1) sync serial cards, and these drivers haven't really been touched (other than in tree-wide sweeps to keep them building) for 15+ years. Related PCI devices ce and cp are still in the tree, with deprecation proposed in D23928. MFC after: 1 week Relnotes: Yes Sponsored by: The FreeBSD Foundation 2019-12-03T16:52:03Z Ed Maste emaste@FreeBSD.org 2019-12-03T16:52:03Z urn:sha1:39883ef6aec78444a2e7cda83ce2a61050fba4ff AFAICT this is the last source file (excluding contrib) that was not ASCII or UTF-8. 2019-05-26T12:41:03Z Alexey Dokuchaev danfe@FreeBSD.org 2019-05-26T12:41:03Z urn:sha1:0a16ee754498efd348e7f46f68b8c89896924463 application's logic. It's possible that 'else' keyword is missing. Reviewed by: gallatin, np, pfg Approved by: pfg Differential Revision: https://reviews.freebsd.org/D20396 2017-02-20T03:43:12Z Pedro F. Giffuni pfg@FreeBSD.org 2017-02-20T03:43:12Z urn:sha1:4d24901ac9131267fd188c5e1ee19a219847238a Makes things easier to read, plus architectures may set NULL to something different than zero. Found with: devel/coccinelle MFC after: 3 weeks 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-01-27T02:23:54Z Justin Hibbits jhibbits@FreeBSD.org 2016-01-27T02:23:54Z urn:sha1:2dd1bdf1834c53d048d3d9a7079b45afea5cecd7 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 2015-05-22T17:05:21Z Jung-uk Kim jkim@FreeBSD.org 2015-05-22T17:05:21Z urn:sha1:fd90e2ed54a69bb07d14dcd4e805431ccb7d6cb6 years for head. However, it is continuously misused as the mpsafe argument for callout_init(9). Deprecate the flag and clean up callout_init() calls to make them more consistent. Differential Revision: https://reviews.freebsd.org/D2613 Reviewed by: jhb MFC after: 2 weeks 2015-01-06T12:59:37Z Robert Watson rwatson@FreeBSD.org 2015-01-06T12:59:37Z urn:sha1:2a8c860fe3f3bcfc6ba9206f34d067d998d89c7e socket-buffer implementations, introduce a return value for MCLGET() (and m_cljget() that underlies it) to allow the caller to avoid testing M_EXT itself. Update all callers to use the return value. With this change, very few network device drivers remain aware of M_EXT; the primary exceptions lie in mbuf-chain pretty printers for debugging, and in a few cases, custom mbuf and cluster allocation implementations. NB: This is a difficult-to-test change as it touches many drivers for which I don't have physical devices. Instead we've gone for intensive review, but further post-commit review would definitely be appreciated to spot errors where changes could not easily be made mechanically, but were largely mechanical in nature. Differential Revision: https://reviews.freebsd.org/D1440 Reviewed by: adrian, bz, gnn Sponsored by: EMC / Isilon Storage Division 2014-10-10T19:12:04Z John Baldwin jhb@FreeBSD.org 2014-10-10T19:12:04Z urn:sha1:97dc3d98cbeb598bd49dd3603cde75e0dc8d128b