src/sys/dev/ctau, branch releng/12.2FreeBSD source treehttps://cgit-dev.freebsd.org/src/atom?h=releng%2F12.22020-03-09T13:04:47ZMFC r358554: Add deprecation notices to ctau and cx drivers2020-03-09T13:04:47ZEd Masteemaste@FreeBSD.org2020-03-09T13:04:47Zurn:sha1:600a4a04cb897bc0645b11eaf79a36746227cd19
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.
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
sys/dev: Replace zero with NULL for pointers.2017-02-20T03:43:12ZPedro F. Giffunipfg@FreeBSD.org2017-02-20T03:43:12Zurn: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
Use uintmax_t (typedef'd to rman_res_t type) for rman ranges.2016-03-18T01:28:41ZJustin Hibbitsjhibbits@FreeBSD.org2016-03-18T01:28:41Zurn: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
Convert rman to use rman_res_t instead of u_long2016-01-27T02:23:54ZJustin Hibbitsjhibbits@FreeBSD.org2016-01-27T02:23:54Zurn: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
CALLOUT_MPSAFE has lost its meaning since r141428, i.e., for more than ten2015-05-22T17:05:21ZJung-uk Kimjkim@FreeBSD.org2015-05-22T17:05:21Zurn: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
In order to reduce use of M_EXT outside of the mbuf allocator and2015-01-06T12:59:37ZRobert Watsonrwatson@FreeBSD.org2015-01-06T12:59:37Zurn: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
Don't pass RF_ALLOCATED to bus_alloc_resource().2014-10-10T19:12:04ZJohn Baldwinjhb@FreeBSD.org2014-10-10T19:12:04Zurn:sha1:97dc3d98cbeb598bd49dd3603cde75e0dc8d128bConvert most BPF_TAP users to BPF_MTAP.2014-09-28T19:05:22ZAlexander V. Chernikovmelifaro@FreeBSD.org2014-09-28T19:05:22Zurn:sha1:c6682d59068eb7d59c06f82468655cd4bbeb9133
MFC after: 2 weeks
Remove ifq_drops from struct ifqueue. Now queue drops are accounted in2014-09-19T09:01:19ZGleb Smirnoffglebius@FreeBSD.org2014-09-19T09:01:19Zurn:sha1:56b61ca27ace61b1f30aaeb54138d8114df56d00
struct ifnet if_oqdrops.
Some netgraph modules used ifqueue w/o ifnet. Accounting of queue drops
is simply removed from them. There were no API to read this statistic.
Sponsored by: Netflix
Sponsored by: Nginx, Inc.
Mechanically convert to if_inc_counter().2014-09-19T03:51:26ZGleb Smirnoffglebius@FreeBSD.org2014-09-19T03:51:26Zurn:sha1:c8dfaf382fa6df9dc6fd1e1c3356e0c8bf607e6a