The hardware delivers ns16550-compatible status bits, which is what the
usb_serial code expects, so no need for translation, no need for a local
variable to hold a temporary lsr result.
- Support for the AC3165 and AC8260 chipsets was added by r303322 and r303327.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D7322
POSIX requires that these functions have an unsigned int for their first
argument; not an unsigned long.
My reasoning is that we can safely change these functions without
breaking the ABI. As far as I know, our supported architectures either
use registers for passing function arguments that are at least as big as
long (e.g., amd64), or int and long are of the same size (e.g., i386).
Reviewed by: ache
Differential Revision: https://reviews.freebsd.org/D6644
It looks like our "struct shmid_ds::shm_nattch" deviates from the
standard in the sense that it is a signed integer, whereas POSIX
requires that it is unsigned, having a special type shmatt_t.
Patch up our native and 32-bit copies to use a new shmatt_t that is an
unsigned integer. As it's unsigned, we can relax the comparisons that
are performed on it. Leave the Linux, iBCS2, etc. copies of the
structure alone.
Reviewed by: ngie
Differential Revision: https://reviews.freebsd.org/D6655
Note that keyboards are stored in an array and are not freed (just
"unregistered" by clearing some fields) so a race would be limited to
obtaining stale information about an unregistered keyboard.
Reported by: CTurt
MFC after: 3 days
f/w for the other devices supported by this driver.
Patch linked in https://reviews.freebsd.org/D6967 but not actually
a part of the review.
Obtained from DragonflyBSD.
Submitted by: Kevin Bowling <kev009@kev009.com>
MFC after: 2 weeks
Relnotes: yes
Devfs' file layer ioctl is now just a thin shim around the vnode layer.
Reviewed by: kib
Sponsored by: EMC / Isilon Storage Division
Differential Revision: https://reviews.freebsd.org/D7286
which is more efficient.
Note that for now we do not create a separate library for libdivsufsort
because it's not used anywhere else.
Obtained from: Chromium
MFC after: 2 months
It only contains bufring related bits for a while.
MFC after: 1 week
Sponsored by: Microsoft OSTC
Differential Revision: https://reviews.freebsd.org/D7281
This was a regression from r300349.
Setting MK_CROSS_COMPILER=no forces the compiler bootstraping *and* the
binutils/elftoolchain bootstrapping to be disabled in share/mk/src.opts.mk.
The only intent with using an external compiler is to disable bootstrapping of
the compiler. The binutils/elftoolchain bootstrapping must still occur unless
XAS is set. This did not affect WITH_SYSTEM_COMPILER.
Now that setting an external compiler sets both MK_CLANG_BOOTSTRAP and
MK_GCC_BOOTSTRAP to no, and MK_CROSS_COMPILER does the same via
share/mk/src/opts.mk, remove redundant logic that checks for
MK_CROSS_COMPILER. It will not always be true now that MK_CROSS_COMPILER==no
when an external compiler is used and --sysroot/-target is needed.
Reported by: sbruno
Pointyhat to: bdrewery
MFC after: 3 days
Sponsored by: EMC / Isilon Storage Division
1. Always calculate what the expected values are.
2. Add 'make test-system-compiler' to show all of the computed values
vs the wanted values.
3. Extend the .info line to buildkernel/kernel-toolchain/toolchain/_cross-tools.
4. Consolidate all of the logic to one condition.
MFC after: 3 days
Sponsored by: EMC / Isilon Storage Division
Calling it earlier increases the window when MSIX info may change.
This change does not solve the problem completely, but seems logical.
Complete solution should probably include link reset in case of MSIX
remap to trigger new negotiation, but we have no way to get notified
about that now.
Split implementation of nvram2env to generic (MI) & MIPS-based code:
- removed includes like "*siba*", because they are unused
- added nvram2env_mips.c file with MIPS-specific code, code moved from nvram2env.c
- added header file to shared defines/structures/function prototypes between MI and MIPS code
Also this fix allows to implement own nvram2env drivers.
Reviewed by: ray, adrian (mentor)
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D6513
